TabAtkins

Fwiw, while I deeply appreciate WebKit supporting the proposal as well, the editors of the Nesting spec are Googlers and the Chrome impl happened at the same time.

Depending on the exact parsing strategy it might be genuinely required (such as if the parser switches from "property mode" to "rule mode" at some point), but in this case it was just because it's kinda confusing to do so.

We removed the restriction, but still warn against it due to readability issues.

Notably, this is identical to the behavior you get from @scope's nesting, and from passing a complex selector to an `el.querySelector()`.

(We discussed adopting Sass's behavior in <https://github.com/w3c/csswg-drafts/issues/8310#issuecomment...> but ultimately dropped it.)

Or search engines, which are a special case of disabled users.

"Anne" is a male name in the Netherlands. (I don't know if it can also be a female name there, but this Anne is definitely male.)

The CSS 'contain' property helps ensure that local changes don't cause dirtiness to spread higher up the tree. <https://drafts.csswg.org/css-containment/>

I know Chrome has an implementation that I think is still moving thru the shipping cycle, and the other browsers are working on theirs iirc.

> drops all resolved CSS rules on element, its siblings, its parent and all children.

Browsers optimize this, too - they try hard to keep up metadata structures that tell them whether they need to invalidate styling or not. (This is why mutating the stylesheet is so expensive - browsers have to freshly rebuild the supporting data structures. They could optimize that too, but it's a lot of effort for a rare case.)

So if there's no rules mentioning an [a] attribute in the page, el.setAttribute("a", ...) will generally not do anything.

(One of the benefits of shadow DOM is that the shadow trees are scoped away from the main tree and each other, so you can have more expensive rules in them without making the rest of the page slow. Yay for componentization!)

Saying "People have different opinions" about nazi bullshit is kindergarten-level analysis.

Nazis are bad. Racists are bad. Claiming these "opinions" are equivalent to any other is childish and immature. Grow up and realize you live in a society with other people, and the positions you advocate for (and encourage others to advocate for) have real consequences.

I mean, okay, maybe, but that just means that they'd be hosting a conference about "nazis suck" and hey, I'm okay with that. That's a message I can get behind.

"Just add native support for jQuery and call it a day" "Just add native support for React and call it a day"

We can do lots of amazing things in the ecosystem, but often we're working around missing primitives in the platform. Just "adding native support" for today's hottest library doesn't fix things properly. It's better to figure out what problem they were solving, and then fix that problem more directly.

(jQuery is largely solving "DOM APIs suck". We've fixed that a little bit, with things like query() (née querySelector(), which was an awkward first attempt at it) and fetch(), but are still struggling to work through browser dev apathy at things like event registration or creating elements.)

(Figuring out what problem, precisely, React is solving is exciting and interesting. It's non-obvious - it's not just "some DOM things are slow", as there's lots of DOM things both fast and slow, and you don't need a fancy (read:slow) tree-diffing algo to fix those. There's something fundamental going on that we might be able to do better - maybe it's more fully separating the "display thread" that contains DOM from the rest of your JS, and letting you do a lot of DOM-ish manipulation in threads other than the display thread. Maybe that means actually using an even more lightweight display abstraction, so you can cheaply spam out updates without having to do expensive diffing first. There's a lot of possibilities here.)

That's exactly what you can do. var() is replaced at computed-value time, so calling gCS().color will return "red" or whatever.

If you use an API that gives you the value at an earlier time, like el.style.color (which is "specified value"), you'll see the var().

Yeah, CSSNext here is basically the intersection of CSS variables and Sass variables - you can only use them in property values (like CSS), and you can only declare them at top-level (like Sass).

It's nice if you really want to utilize the current syntax, but it's less powerful than either option it's derived from.

If I'd done what everyone keeps saying I should have done and just used $foo, then Sass would have gotten angry at me, because we'd be sharing syntax for different features. We already tweaked CSS a little to avoid that in another case (when specifying grid line names in Grid, you surround the names with []; it was originally (), but Sass asked us to change it because they use that for their list syntax).

We could only have used $foo if we hewed very close to Sass's functionality - global macros that operate at the stylesheet's lexical level. That wasn't what we wanted to do, though, either at the time (considering only the variables use-case) or looking forward (to the use of custom properties as the generic "inject info into your page via the CSS engine", a la data attributes for HTML).

By avoiding global macros, we also get context sensitivity - we can actually offer APIs for this stuff that are smarter than "here's the string you set". When we add custom pseudoclasses, custom media queries, etc they'll all get their own useful APIs. Sass is stuck with string manipulation, because you can use a Sass var anywhere, so it's impossible to infer anything about it.

> He's the guy who wasted a decade writing an ASCII-art based "template layout module"[1], which he was never able to persuade a single browser vendor to implement. It eventually got demoted from a working draft to a "note", which is the W3C's polite term for standards fanfiction.

This is because it was absorbed into the larger and more fleshed-out Grid specification, which is nearly release-ready in multiple browsers. The ASCII art is actually really useful!

Properly, the --foo stuff is a Custom Property. You can use its value as a variable, with var(), but it's not the only use custom properties have. That's why the spec's full name is "CSS Custom Properties for Cascading Variables". But that's a horrible mouthful, so "CSS Variables" is what it's usually called. (Plus that's the shortname in the url.)

(There's also a large focus, in v1 here, on the variables use-case, because that's what I needed to sell it to the group at the time. The CSS Houdini Task Force is now expanding Custom Properties properly, so they can actually be used for random JS things without a ton of hackery.)

lolololol obvious troll is obvious

"i disagree with you, thus you must be lying about your experience and actually unworthy of doing your job, unlike me, the superior being" go get your diaper changed

Yeah, setting an explicit aspect-ratio is on the roadmap. The relevant people (me and fantasai) have too many other layout-related things on our plate atm to deal with it, but it'll show up in the next year or two.

CSS selectors always select "down the tree". Or, read in reverse (from right to left), evaluating them only requires information from further up the tree. In HTML, "further up the tree" corresponds exactly to "earlier in the text stream". This means that as soon as an element finishes parsing, we can find all the selectors that apply to it immediately, enabling better incremental display.

Of course, that's no longer always true today. In particular, selectors like :nth-last-child() depend on information from later siblings. Defining a combinator or equivalent mechanism that allows direct selection based on later siblings is thus not out of the realm of possibility. And selecting a parent vs an earlier sibling is almost identical - the parent's start tag is immediately prior to the first sibling (or text), so the distance between "thing you're selecting" and "thing it needs to know about to evaluate the selector" is only incrementally larger. So a way of selecting a parent based on children is probably fine too.

There are a few issues that have prevented us from doing so today. For one, it's slow. Using a single one of the "backwards" sibling pseudo-classes can kick your entire page into slow-selector mode, because it breaks optimizations. The same would be true of parent selectors, probably. For two, we have to prevent nesting - siblings usually aren't too far from each other, but the root can be very far from a descendant. (Also, siblings are usually walkable by traversing an array, while parent/descendant relationships are typically pointer-based and slower to traverse.) This makes it a bit clumsy to specify.

That all said, it's on the roadmap. I plan for it show up in Selectors 5.

(Oh, and note, the "cascade" in "Cascading Style Sheets" isn't about what you're referring to. It's about a "cascade" of values for a given property colliding on a single element, and figuring out which one "wins". Thus the Cascade module <https://drafts.csswg.org/css-cascade/>. It's not the best name, but we're stuck with it. ^_^)

Yup, that's the problem with having a language that evolved slowly over 20 years, while its problem space changed enormously. CSS was originally intended as a simple way of styling text documents on the web.

We're trying to fix vertical centering, at least. The alignment properties from the Align spec <https://drafts.csswg.org/css-align/> do consistent centering (and other alignment) across layout modes. Currently they only work in Flex and Grid, but they're defined to work in Block and Abspos as well.

Both, either. ^_^ Having wrapping behavior split the way it is today is wrong - either all of it should be in white-space, or none of it should be. (Moving it all out into a separate property is probably best, so white-space can keep just being about white-space itself.)

Yes, that's the point. ^_^ IE's "'width' sizes the border box" behavior was the better behavior. This was very early in the CSSWG's life, tho, and the group as a whole was less mature, so it didn't value back-compat and supporting actual pages as much. I wasn't around at the time, so I can't be sure of exactly why people preferred the content-box sizing model, but regardless, it was a wrong choice for compat at the time, and in hindsight, it was the wrong choice for the sizing default.

There are still reasons to size the content-box, but that's what box-sizing is for (or some equivalent mechanism).

As a very busy CSSWG member... I agree. There are a number of benefits to the current structure, but I highly suspect that if the web were invented today, styling would a JS-mediated aspect of the DOM, not something fully separate like it is today.

CSS layout is about two things - the relationship between an element and its parent (and its siblings to a lesser extent).

It's specified in two halves: the parent lays down general dictates about how its children will be laid out (via 'display' and the layout-specific properties like 'flex-flow'), while the child responds with details about how it would like to be laid out (via width/height/etc and layout-specific properties like 'flex').

We never did end up creating a layout mode that deals in direct relationships between elements, for a number of reasons both good and bad, but that's why the CSSWG's Houdini Task Force exists - one of our deliverables is Custom Layout, so you can write JS-driven layouts that interact with the rest of CSS properly. (Today you can't without a lot of hacks, and those only get you partway there.) Custom Layout will be one of our last things to do tho, because it's the hardest, both to specify and to implement performantly (in particular, without slowing down pages that don't use Custom Layout at all, and ideally not kicking the whole page into a slow mode if one widget uses Custom Layout). So it's still a few years out - we've only got rough ideas for how the spec will work right now.

(Some of the reasons we haven't done direct "X is 10px to the left of Y" layouts: (1) CSS's syntax isn't built well for it. The rule/declaration dichotomy privileges one element, the one matched by the selector. There aren't good, reliable ways to select a unique element for the other end of the relationship. IDs aren't good, because they're page-global; everything else is too promiscuous. (2) Too easy for things to overlap in bad ways on unexpected screen sizes. Authors often develop for the computer they're on, and most don't pay much attention to screen sizes they don't own devices for. Existing CSS layout modes all degrade more-or-less gracefully, because the parent has ultimate control over where the children go and can avoid making them overlap. The exception is abspos/fixpos, which are the closest to the direct-relationship layout mode, and which can easily cause bad layout - see almost any page using position:fixed and designed for desktop, then viewed on a phone's screen. (3) It requires being extra-opinionated about how to handle cycles and such. Individual libraries do this fine (and often respond with a simple "don't write cycles"), but specifying it unambiguously and usefully is pretty hard.)

I assume you mean property names, because keywords are all over the place and don't have anything to do with colons.

It's just a separator between the two semantic halves of a declaration. It could just be a space, but it wouldn't be quite as obvious. Compare "display block;" to "display:block;"

It wouldn't save characters, either - you can omit spaces around the colon today and have the same number. That is, "display block" and "display:block" are both 13 chars.

There is indeed nothing requiring a colon vs a space, as the grammar is unambiguous either way.

We have variables now <https://drafts.csswg.org/css-variables/> so it's not a mistake that needs a time machine.

trolololol

The term "blend mode" is a term of art in the industry, yes. But "mode" is always redundant - lots of properties switch "modes", particularly the ones with keyword values. For example, we could have had "display-mode" rather than "display", but that would definitely have been redundant. The word "blend" isn't used for anything else reasonable in CSS's wheelhouse, so using it by itself would have been fine.

I'm not sure what difference you think you're alluding to between RGB and RGBA. All browsers store colors as RGBA 4-tuples. Are you perhaps under the impression that "RGB" and "RGBA" refer to particular color spaces or something? They don't - nearly all color spaces are alpha-agnostic and can have an alpha value appended to their color definition. (The few exceptions are things like pre-multiplied RGBA, where the RGB components depend on the alpha. But these are rare)

Given that the CSSWG's membership is largely browser implementors, I'm pretty sure we have a handle on what the fuck our graphics stack does.

It is, still. You want separation between your paragraphs and other elements; you don't want the first and last children of a box to be separated from the edges of that box. Margin-collapsing does that (sibling boxes collapse margins together, first/last collapse with parent and shift their margins "out"), but it's difficult to do otherwise.

That said, you could do one-sided margins better if we hadn't had naked text in the layout model. If everything was wrapped in elements, then text at the start of a container element wouldn't require a margin-top on the first child element, while text at the bottom wouldn't require margin-bottom on the last child element. Naked text is a mistake. (And I just added it to the list. ^_^)

The srcset attribute by itself can't do what you ask; it only lets you specify multiple resolutions of an image, all (intended to be) the same size.

But wait for implementation to finish, and you'll be able to use the sizes='' attribute on the <img>, or the full <picture> deal, and that'll give you more control, letting you load a smaller image if the image would take up less space.

You, um, know that Selectors is one of the few specs without naming problems, right? Its url is "selectors4".

As well (partially as a result of me writing this blog post), we're looking into changing our URL structure, which was originally settled on a decade ago, before we knew how we were going to do this "module" thing.

But hey, nice attempt at trolling.

If there are any problems, it's because you're using an old browser. (As far as I know.) The iPhone browser definitely counts as "old". ^_^

In particular, a bunch of browsers don't support specifying background-size in the background shorthand yet. It's in modern WebKit, but that hasn't trickled down to mobile versions yet.