Quantity Queries for CSS | Hacker News Reader

Quantity Queries for CSS

alistapart.com

82 pointslars25 comments

This is a good article. It presents a provocative idea, exploring the use of CSS in clever and not obvious ways.

It's sort of but not really "hackish" because he uses perfectly legitimate, if relatively obscure features of CSS, things we ought to know but haven't studied enough.

The result is an elegant approach to responsive design. Templates and other tools no doubt use such approaches under the hood. A few lines of CSS doing the job without having to drag along the bloat of a framework is a very good result.

Having the knowledge to directly apply CSS to achieve design goals is enormously powerful and worth learning about.

It drives me nuts how much work we put into making CSS something that it is not. Why are we trying to do scripting with CSS? I can really appreciate the approach taken by React to move style definitions into Javascript, and more specifically into the file of the module whose styles they define.

I'm really just repeating what was said by a Facebook developer (I've forgotten his name at this moment) - but I think it is worth being said: CSS is more a separation of technology, than a separation of concerns. It makes much more sense to have all your code (styles, scripts, markup) in one file for a specific module. Any repeated styles/scripts/markup can be imported as a module.

In hindsight, it makes me wonder what the hell I've been thinking all this time.

CSS is a different technology for a different complementary purpose to, say, markup or business logic. That's why we have the separation of concerns principle. If business logic is doing CSS's work, design changes MESS with the business logic, which is undesirable for obvious reasons.

By saying "CSS is more a separation of technology, than a separation of concerns" you are saying "CSS is more a separation of concerns, than a separation of concerns" or possibly "CSS is more a separation of technology, than a separation of technology".

As for the modularity concept, that doesn't have to flout or adhere to "separation of concerns". That's just a different thing.

So what's your thoughts on React?

I'm not familiar with React. I tried reading a primer on it and got really bored. Couldn't imagine how it would change my work. Then again, I'm mostly a UX designer who works with code rather than an "engineer" focused on abstraction and performance.

Maybe the amount of such css trickery hints us that css is becoming outdated and is actually not exactly what we would like it to be. I might argue in this case that the result that is obtained is very much in the visuals and styling scope and has less to do with functionality (scripts). Though, the method how it is obtained, I agree, goes against good readability and is a bit hacky in concept.

Actually CSS is a special purpose scripting language for manipulating stylesheets of structured documents such as HTML & XML.

It's also rumored to be Turing complete and the W3C's CSS working group is the one that's slowing down the progress of CSS into a full blown scripting language for performance reasons (Fast vs Full debate)

However, this doesn't mean that you can't reinterpret "Separation of Concerns" or subscribe to this notion of "Separation of Technologies" and that modules should be self-sufficient.

You can say and do whatever you want but I'm sticking with placing all my style info in CSS files and exploring exhaustively all the possibilities this quirky language provides to manipulate the layout/formatting/styling aspects of my web apps/pages.

It is not trickery, it is constraints declarations.

If you want to go with scripting you will end with your own ad-hoc incomplete bug-ridden slow implementation of half of CSS engine, to paraphrase famous law. Bugs will be prevasive, because your "solver script" will be good in most cases except some where it will be glitching or unstable.

You can take a look at QOCA layout constraint solving engine to get a feeling how much code you will write in the end.

I should have been more clear: I'm not suggesting replacing CSS. I do think however that CSS doesn't need to be siloed. We have a great scripting language (JS), why not just incorporate that with a way to modify styles (CSS) without the need to do all these fancy hacks for calculations. Even the calc function in CSS feels like a hack.

How much longer until we discover enough logic operations to write a full raytracer in css?

(Ab)using css3's :nth-child selector to invent new ones https://grack.com/blog/2015/01/09/abusing-css3-selectors/

A bit of a plug but we once made a CSS only tic-tac-toe using the same technique: http://html5advent2011.digitpaint.nl/23/index.html

Far from the same technique, imo. But very clever all the same!

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.

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.

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?

I'd feel more comfortable modelling this type of layout change with a conditional class added by the CMS itself, given that's presumed the source of such content variability.

Tricky! Now I bet someone will write a SASS mixin library to obscure these "hacks". I'm banking on seeing that on HN next week.

I think that CSS should include something like XSLT transformations allowing developer to output site markup with simple semantic elements and then designer can transform those elements into anything he need, count elements, add classes, whatever. And then style result of those transformations with traditional CSS rules.

This feels very hacky to me.

For certain connotations of "hacky", sure. But I don't think it's hacky in the sense of being unreliable.

Would probably be very simple to turn it into a clean SASS/LESS mixin. Performance I'm less sure about.

Not as hacky as using float:left; and overflow:auto; to place block elements in a row. I'd say it is below par.

But that's readable. This isn't.

How is it readable? It's a well understood convention, sure, but the semantics are completely incorrect. The example in the linked article, by contrast, does exactly what it says. The syntax might be a little odd, but the logic is hardly complicated.

Reply on news.ycombinator.com