3 ms·

Author says he is doing this because of "separation of concerns" and CSS should be strictly in charge of layout. Unfortunately I think this article shows that C

Author says he is doing this because of "separation of concerns" and CSS should be strictly in charge of layout. Unfortunately I think this article shows that CSS needs to be much more powerful than it currently is to achieve that goal. I'm not putting this in my CSS just to satisfy some noble goal of "layout versus presentation": li:nth-last-child(-n+6):first-child, li:nth-last-child(-n+6):first-child ~ li { /* properties here */ } It's too cryptic. I feel another more important noble goal is to keep your CSS readable and understandable.

mtrpcic 12y ago
I agree. A lot of times I see people touting the separation of concerns, or the "official spec" for things (like HTTP verbs and REST), and finding workarounds that still adhere to these specs. I've worked on projects like this, and what ends up happening is you have a solution nobody really likes, a codebase that nobody can really follow, and a whole pile of technical debt that could have been avoided if you just prioritized code quality, readability, and discoverability. Note that I'm not advocating blindly using "whatever has the nicest code", but in a lot of cases, a clean codebase is far better than 100% adherence to specs and guidelines. Write readable code first, optimize it later if you need to.
heydon 12y ago
Just to clarify, the "layout versus presentation" thing isn't just for its own sake. It's to avoid having to implement design changes in two places (the CSS and the template/backend). By using template logic and classes (CSS hooks) this would be inevitable. As for the ugliness of the CSS, well... that's what the CSS that works for the purpose looks like. Function over form. I'd recommend _adding a comment_ if you want developers to grok the code. I must say I find it odd that you think transparency for fellow developers is _more_ important than the actual purpose of the code. Your convenience in maintaining the product cannot be more important than the product itself, surely?

mtrpcic 12y ago

I agree. A lot of times I see people touting the separation of concerns, or the "official spec" for things (like HTTP verbs and REST), and finding workarounds that still adhere to these specs. I've worked on projects like this, and what ends up happening is you have a solution nobody really likes, a codebase that nobody can really follow, and a whole pile of technical debt that could have been avoided if you just prioritized code quality, readability, and discoverability. Note that I'm not advocating blindly using "whatever has the nicest code", but in a lot of cases, a clean codebase is far better than 100% adherence to specs and guidelines. Write readable code first, optimize it later if you need to.

heydon 12y ago

Just to clarify, the "layout versus presentation" thing isn't just for its own sake. It's to avoid having to implement design changes in two places (the CSS and the template/backend). By using template logic and classes (CSS hooks) this would be inevitable. As for the ugliness of the CSS, well... that's what the CSS that works for the purpose looks like. Function over form. I'd recommend _adding a comment_ if you want developers to grok the code. I must say I find it odd that you think transparency for fellow developers is _more_ important than the actual purpose of the code. Your convenience in maintaining the product cannot be more important than the product itself, surely?