

Quantity Queries for CSS - lars
http://alistapart.com/article/quantity-queries-for-css

======
jrapdx3
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.

------
iLoch
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.

~~~
thesz
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.

~~~
iLoch
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.

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

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

------
edwinvdgraaf
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](http://html5advent2011.digitpaint.nl/23/index.html)

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

------
teleclimber
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
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.

------
fredkelly
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.

------
rbosinger
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.

------
vbezhenar
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.

------
aembleton
This feels very hacky to me.

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

~~~
pyrocat
But that's readable. This isn't.

~~~
grumblestumble
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.

