[HN Gopher] CSS Nesting Module (First Public Working Draft)
___________________________________________________________________
CSS Nesting Module (First Public Working Draft)
Author : bpierre
Score : 131 points
Date : 2021-09-01 01:32 UTC (8 hours ago)
(HTM) web link (www.w3.org)
(TXT) w3m dump (www.w3.org)
| [deleted]
| schube wrote:
| While as part of SASS nesting is a marvelous feature I am an
| absolute fan of, I can't help but see this as yet another step in
| the direction of making new and varied browsers even more
| impossible to implement. I rather like the "unixy" route of
| having SASS handle the complexity of understanding nesting and
| having a simpler browser consume plain flat CSS.
| gherkinnn wrote:
| That ship has long sailed. Nesting is inconsequential at this
| point.
| sharmin123 wrote:
| How Does A Hacker Hack A Phone? How To Avoid Phone Hacking?:
| https://www.hackerslist.co/how-does-a-hacker-hack-a-phone-ho...
| gedy wrote:
| Nice, nesting seems to be so much more understandable for typical
| developers, will be nice to not need SASS or LESS preprocessors
| just for this.
| 22c wrote:
| I used SASS in a recent project essentially just for this
| feature, so it seems like the CSS WG is slowly chipping away at
| convenience features that some people have been using for quite
| some time.
| cosmotic wrote:
| This seems nice but we'll still likely need preprocessors to
| aggregate multiple files. The import feature of CSS results in
| additional, serial requests, which are very not good.
| eyelidlessness wrote:
| This is where standards and bundlers are converging. Move as
| much syntax to standards as possible to relieve compilers of
| the duty, use bundlers to do static analysis of dependencies
| and build optimal packages for the network waterfall.
| inopinatus wrote:
| sometimes your preprocessor is cat
| spankalee wrote:
| We rally need Web Bundles so we don't have to merge files, but
| can create a bundle with all the individual files in it that
| populate the network cache correctly.
| simlevesque wrote:
| > The import feature of CSS results in additional, serial
| requests, which are very not good.
|
| I'm not sure about that. HTTP2 server push seems to fix this:
| https://en.wikipedia.org/wiki/HTTP/2_Server_Push
| abdusco wrote:
| Server push is deprecated.
|
| - https://groups.google.com/a/chromium.org/g/blink-
| dev/c/K3rYL...
|
| - https://evertpot.com/http-2-push-is-dead/
| la_fayette wrote:
| The networking overhead of serial requests would be reduced
| by multiplexing in Http2, i.e., multiple http
| requests/responses can reuse the same tcp connection in
| parallel...
| bawolff wrote:
| I dont think that helps much in this case (or not any more
| than http/1.1 keep-alive did).
| la_fayette wrote:
| Multiplexing is completely different from keep-alive.
| With http2 a web browser requires one tcp connection per
| website as communication is in parallel, approaches like
| conncatenating several css files into one have no use
| with http2 anymore! Http1 keep-alive allows reusing the
| same tcp connection for sequential requests/responses
| only.
| bawolff wrote:
| I dont think server push is a thing anymore, but preload
| hints (<link rel=preload) might work just as well for this
| usecase.
| TheRealPomax wrote:
| unless you send _different_ files each request, pretty sure
| browser caching is still a thing and imports with `preload`
| links are just fine?
| ihuman wrote:
| I read the page's reasoning for why everything can't be directly
| nested, but I still don't get it. Why is an "unbounded lookahead"
| an issue?
| klodolph wrote:
| The amount of lookahead necessary dictates what algorithms you
| can use for parsing. If you go from 1-token lookahead to
| unbounded lookahead, you might force a lot of people to rewrite
| their parsers or make major changes (because they would have to
| use different algorithms). This would mean that a lot of CSS
| parser would simply _not adopt_ the new syntax, at least not in
| a timely fashion.
|
| If you keep 1-token lookahead, existing CSS parsers can just
| drop this in.
| eyelidlessness wrote:
| It's the same reason backtracking is a performance hit in any
| scenario. CSS is blocking, and if a selector needs to wait for
| every network resolution and JS parse/execution to resolve it's
| essentially as expensive as your worst case scenario.
| zeroimpl wrote:
| The term "unbounded" seems a bit strange to me too. At worst
| you only need to lookahead until the next ; or { to figure out
| if it's a property or a nested selector.
|
| I guess that's unbounded because the parser can't know how much
| data it will have to buffer, but in practice we're talking like
| a few dozen bytes most of the time.
| dmitriid wrote:
| IIRC there are easily reproducible pathological cases. The
| author of Sass said it was one of mistakes he made when
| creating Sass: he didn't require & for nesting everywhere.
|
| Unfortunately, on mobile I can't quickly find the relevant
| links.
| eyelidlessness wrote:
| The lookahead isn't to the next bit of CSS syntax, it's
| looking ahead to the next potential selector match in the
| DOM. If that can't be resolved, you can't unblock the CSS
| resolution to un-suspend the next blocked portion of the
| initial render
| eurasiantiger wrote:
| You could be parsing invalid syntax (forgot a } somewhere),
| and now your parser tries to nest EVERYTHING until it finds
| that matching curly brace or errors out at EOF.
| wlib wrote:
| Keeping a tiny bounded lookahead is essential for the extremely
| fast and memory-efficient parsing that browsers want for CSS.
| Sass, less, &c. don't really have to care about that, and they
| have the benefit of also being able to completely trust that
| the user won't give pathological inputs - unlike browsers on
| the web. Also, I think the standards bodies want to minimize
| their changes in general, to keep the door open for unexpected
| changes later.
| adamrezich wrote:
| I'm no expert in parsing but my gut tells me there's no way
| this can actually be a performance concern as much as a
| implementation complexity concern
| klodolph wrote:
| Right... you don't want to force everyone to make
| significant changes to their parsers. If you are writing a
| C or C++ parser, you know up-front that there is lots of
| funny business in the language syntax and can plan your
| parser accordingly. If you are writing parser for something
| a bit more sane, like Java or CSS, then you can choose a
| much simpler architecture for your parser.
|
| Part of this means that if, say, your language is LL(1) or
| something like that, you will want to keep future versions
| of the language LL(1). This can put you in a bit of a tight
| spot sometimes, when you're making backwards-compatible
| changes.
| paulclinger wrote:
| The very last example in 2.1 ("__bar.foo { color: red; }") should
| instead be "foo.__bar { color: red; }" if I understand it
| correctly.
| tantanel wrote:
| No, I think the example is correct. __bar in this case is
| interpreted as an element name (custom html element), not a
| class.
| gherkinnn wrote:
| I fail to understand people's infatuation with CSS nesting.
|
| It is nice not to write too much to get some pseudo elements or
| selectors working, but that's the extent of it.
|
| Tying your CSS to the markup is a recipe for misery and pain.
| Over all these years, I've never seen it not turn out to be a
| nightmare.
| roman-holovin wrote:
| I feel that problem is that some CSS _has_ to be tied to markup
| and some of it - doesn 't.
|
| There is bunch of CSS features and techniques that work only
| when you enforce certain parent-child relationships of the CSS
| rules.
|
| Simplest example of it is 'position:absolute' that requires
| some parent node to have 'position: relative' to be useful. But
| there is more to that, both flexbox and grid require certain
| properties to applied to both parent and children nodes at the
| same time.
|
| Nesting is one way to enforce those relationships and make sure
| that they are co-located in the stylesheet code.
|
| Something like that is, in my view, good usage of the nesting:
| .parent { display: flex; & > .child
| { flex: 1 1 auto; } }
| .child { color: red }
|
| I specifically added an example that changes color for class
| `child` and I think this should not be included in the nested
| rule because this part of the styling is not affected by a
| parent in any meaningful way.
| akersten wrote:
| This looks _awesome_. I 'm so glad they re-used the & syntax
| popular in many compile-to-CSS languages. Between this and CSS
| variables, I might not even need SASS in my toolchain anymore,
| which would be amazing.
|
| @nest looks extremely cool too. An easy way to keep rules
| affecting one selector logically grouped with it, even if the
| selector relies on a small thing about its parent elements.
| Ciantic wrote:
| Was thinking about SCSS/LESS too, but notice that this is not
| valid: .foo { color: blue;
| .bar { color: red; } }
|
| The ampersand is required, unlike in LESS and SASS. I don't yet
| understand why, because requiring ampersand makes copy pasting
| things difficult, as you need to add or remove seemingly
| redundant ampersands to move in out of nesting.
| asddubs wrote:
| it says it on the page, it's required because otherwise
| parsing will need unbounded lookahead, since any rule could
| also be a selector
|
| >Nesting style rules naively inside of other style rules is,
| unfortunately, ambiguous--the syntax of a selector overlaps
| with the syntax of a declaration, so an implementation
| requires unbounded lookahead to tell whether a given bit of
| text is a declaration or the start of a style rule.
|
| >For example, if a parser starts by seeing color:hover ...,
| it can't tell whether that's the color property (being set to
| an invalid value...) or a selector for a <color> element. It
| can't even rely on looking for valid properties to tell the
| difference; this would cause parsing to depend on which
| properties the implementation supported, and could change
| over time.
|
| >Requiring directly-nested style rules to use nest-prefixed
| selectors works around this problem--an & can never be part
| of a declaration, so the parser can immediately tell it's
| going to be parsing a selector, and thus a nested style rule.
|
| >Some non-browser implementations of nested rules do not
| impose this requirement. It is, in most cases, eventually
| possible to tell properties and selectors apart, but doing so
| requires unbounded lookahead in the parser; that is, the
| parser might have to hold onto an unknown amount of content
| before it can tell which way it's supposed to be interpreting
| it. CSS to date requires only a small, known amount of
| lookahead in its parsing, which allows for more efficient
| parsing algorithms, so unbounded lookahead is generally
| considered unacceptable among browser implementations of CSS.
| honie wrote:
| Those were my reactions, too! The one thing that I want the
| most whenever I have to jump out of the CSS per-processor world
| and write regular CSS.
|
| It is worth noting that in SASS you can already refer to parent
| elements as they have shown with the `@nest` rule (apologies if
| I misunderstood what you said and you already know this). I do
| prefer the more verbose `@nest` syntax though, as the intention
| is clearer.
| JonathonW wrote:
| I'm sure there's a reason here that I'm not seeing, but it
| feels like it's being different for the sake of being
| different to me-- requiring `&` even in the simple case where
| you're combining them with the descendant combinator (plain
| space), but then also requiring `@nest` in any situation
| where `&` is not at the start of each selector.
|
| SASS takes the opposite approach-- there's an implicit `&` at
| the beginning if you don't specify it elsewhere, and it can
| appear anywhere (i.e. the example `:not(&)` does not have to
| have anything like the `@nest` syntax in SASS).
| ihuman wrote:
| There's an explanation in section 2, in the green box that
| says "Why can't everything be directly nested?"
| [deleted]
| leemcd56 wrote:
| I agree! I may use Sass if I were to write functions to
| generate grids, or element permutations based on a color
| palette, but at this point I don't feel it's all that needed.
| the_other wrote:
| Nesting is useful, but not as useful as you think.
|
| It's great for keeping your pseudo-selectors close to your
| selectors. It's great for faking scoping, by wrapping a whole
| file in the whole file in a single classname labelling your
| component.
|
| But nesting also increases specificity and can distribute the
| name of a selector token across multiple places within the source
| file making debugging much harder.
|
| If you use nesting as an aid to writing more CSS faster, you're
| using it wrong. If you use it as an aid to constructing what
| would be a neat CSS file without nesting, then you're doing it
| right.
| [deleted]
| stupidcar wrote:
| Good. But nesting could and should have been added to CSS a
| decade ago or more, and it is an abject failure of the working
| group that it wasn't, despite the obvious, overwhelming demand
| from authors.
| dbbk wrote:
| Considering it works just fine with a build step it's not that
| urgent.
|
| CSS Custom Properties, on the other hand, I'd argue were much
| more important to drive through quickly as a build step can't
| modify them at runtime.
| emadabdulrahim wrote:
| It's definitely way overdue. I hope this gets in soon and full
| modern browsers support.
| klodolph wrote:
| "Abject failure" is more than harsh. Not many people have the
| expertise to sit on these committees and the passion to drive
| through new changes. It takes a while.
| stupidcar wrote:
| In 2012, the www-style mailing list (where the CSS WG
| organised and discussed before moving to GitHub) was
| receiving up to 1400 messages _a month_ :
| https://lists.w3.org/Archives/Public/www-style/ . There was
| active participation from professional, full-time standards
| experts employed by Google, Apple, Mozilla, Opera, Microsoft
| and more organisations. The author of this nesting spec first
| proposed it in 2011:
| https://lists.w3.org/Archives/Public/www-
| style/2011Jun/0022....
|
| And this was hardly the first such discussion. You can find
| requests going back for _years_ before even that point, with
| people requesting nesting /hierarchical rules and being shot
| down.
|
| So no, there was no lack of expertise or passion. So why has
| it taken this long? A failure of leadership? A failure of
| process? Perhaps the few, pigheaded opponents of an obviously
| desired and useful feature were able to sabotage progress by
| making it impossible to achieve consensus. I don't know. But
| I refuse to let them off the hook because they finally got
| around to delivering something in 2021 that the web should
| have had in 2001.
| klodolph wrote:
| > So no, there was no lack of expertise or passion.
|
| Passion to make proposals != passion to drive through
| changes. Making the proposal is the first step. If you're
| in it for the long haul, you make revisions and get
| consensus.
|
| Software engineers, largely speaking, love to design
| things, build them, and move on to the next project instead
| of dealing with maintenance. Standards committees, largely
| speaking, are designed to get consensus first and figure
| out what the issues are with a proposal _before_
| implementing it. This kind of "eat your vegetables" way of
| working drives off a lot of people. And of the remaining
| engineers who are patient enough to drive something through
| committee, most of them are off busy doing other things.
|
| You might have a taste of what this is like if you have
| ever worked at a company that did design docs before
| implementation. Like, if you're proposing a change to the
| system, and you write up a short document and get a couple
| other engineers assigned to review it. Have you ever had
| more than a couple engineers assigned, like five or ten?
| All looking at it with critical eyes? Now imagine that they
| work at different companies.
|
| > Perhaps the few, pigheaded opponents of an obviously
| desired and useful feature were able to sabotage progress
| by making it impossible to achieve consensus.
|
| Jeezus, that's a great example of the kind of attitude that
| makes this so painful in the first place. I want to print
| this comment out on paper and mail it to the next person
| who complains about slow standards committees.
|
| You're speculating about how people's personality flaws are
| sabotaging the process. Well, guess what? You're not the
| only one doing making shitty comments like that. People who
| make committees work get a lot of disrespect from random
| strangers on the internet.
|
| Maybe someday you'll sit on a committee, but you shouldn't
| have to do that in order to have an ounce of empathy for
| how standards committees work.
| dmitriid wrote:
| The various working groups are plagued by various problems.
|
| SVG is carried forward by a few determined people against
| all odds (see e.g. this tale by Amelia Bellamy-Royds
| https://codepen.io/AmeliaBR/post/me-and-svg)
|
| IIRC the CSS working group is just slow for various reasons
| (from disinterest to lack of people to drive things
| forward).
|
| Some parts of working groups and standards committees have
| been completely taken over by Google that just pushes its
| own agenda.
|
| And so on.
| JimDabell wrote:
| It's not apparent from the document posted, but this is actually
| almost six years old [0] and already implemented as a PostCSS
| plugin for just as long [1]. It was adopted by the CSS Working
| Group a couple of years ago [2]. So this is very well-established
| and you've been able to use this syntax for many years. But it's
| good to see it moving forward and hopefully browsers will
| implement it soon now.
|
| [0] https://tabatkins.github.io/specs/css-nesting/
|
| [1] https://github.com/csstools/postcss-nesting
|
| [2] https://github.com/w3c/csswg-drafts/pull/2878
| eyelidlessness wrote:
| This is good historical context but missing one bit and another
| deserves clarification.
|
| The nesting semantics has been a part of SASS/SCSS for the
| better part of a decade before the proposal, which is now
| pretty much standard in CSS pre-/post-processing.
|
| It's been available to use all that time, but AFAIK still
| requires a build tool. It's only now becoming a tentative
| possibility in userland.
| JimDabell wrote:
| Yes, sorry, I was assuming knowledge of Sass etc.
|
| When I first saw this link I thought _"Hang on a sec., this
| says 'First Public Working Draft', but hasn't this spec. been
| around for ages?"_
|
| I figured people might make the mistake that this was
| something new that the W3C were only just getting around to
| rather than something that has been cooking for a long time.
|
| Didn't mean to imply that the spec. itself sprang up out of
| nowhere - it was definitely based on the Sass work that came
| before it, and you have been able to use this syntax with
| Sass for a very long time!
| TheRealPomax wrote:
| And proposed a decade ago
| (https://lists.w3.org/Archives/Public/www-
| style/2011Jun/0022....)
| throw_m239339 wrote:
| Good!
|
| Now, CSS scopes back in the menu when?
| extra88 wrote:
| There's work CSS scoping going on as well.
|
| https://drafts.csswg.org/css-scoping-2/
|
| Yet another thing Miriam Suzanne has been working on is a
| proposal for CSS Layers. I think it's a way of declaring what
| styles should "win" when specificity is equal instead of "last
| one loaded wins" or using the very crude `!important` tool.
| This could be particularly helpful if stylesheets for 3rd party
| components are loaded dynamically or on platforms where the
| style author doesn't have absolute control over stylesheet
| order.
|
| https://drafts.csswg.org/css-cascade-5/
|
| All of these will take some time to get right and then some
| patience for older browsers to die off (or decent fallback
| strategies, I think all these would be hard to polyfill).
| southerntofu wrote:
| WTF. Why is w3.org blocking tor exit nodes? That's a recent and
| worrying development!
___________________________________________________________________
(page generated 2021-09-01 10:00 UTC)