Do you want to know how the CSS WG works? Fantasai has written about:csswg, An Inside View of the CSS Working Group at W3C.
.offsetParentis based on the nearest abspos containing block or table cell
user-select: noneand selectionchange event
urwas deferred to TPAC.
Element.offsetParentwas deferred to next week.
user-selectproperties, one of which is a shorthand for the other. If that seems to work he’ll also investigate if there’s a reason to expose the longhands to the author.
metaviewport text to normative and add two issues. One to test if the description matches reality. Second is while we spec with the same mechanism there may be differences as we tease out compat.
overflow-style: auto|auto-hide|overlayto allow authors more control over scrollbars while balancing out the desires of implementors to control their scrollbars.
Yesterday I committed a few changes to the CSS Color spec that are proving a little controversial to people without any background on the changes. Hopefully this will help!
Specifically, I made it so that the
rgb()function (and others) can now use the syntax
rgb(0 255 0 / 50%)for half-transparent green. Previously you’d write that as
rgba(0, 255, 0, 50%). Why’d I make this change?
This is part of a general overhaul to how CSS defines functions that fantasai and I are pushing. The overall strategy is written up on our wiki, but the general idea is that CSS has some informal rules about how to organize things and use certain punctuation characters. In particular, in CSS properties we normally just separate values with spaces, relying on distinguishable syntax (like
<length>) or just careful ordering to keep things unambiguously parseable. We use punctuation separators only for very specific purposes: commas are used to separate repetitions of a base value (like layers in the
backgroundproperty, or font names in the
font-familyproperty), and occasionally, when we can’t do anything better, a slash is used to separate two otherwise-ambiguous values (like font-size vs line-height in the
fontshorthand, transition-delay vs transition-duration in the
transitionshorthand, or the multiple pieces of syntax in a
However, functions violated those rules. They used commas extensively and somewhat inconsistently, just to separate values from each other. On the one hand, this makes CSS functions look slightly more like functions in a traditional programming language; on the other hand, it meant you had to learn a different mental model of how CSS’s syntax works, and type a bunch of comma characters that weren’t actually necessary. fantasai and I have gradually come to the position that it’s worthwhile to unify CSS’s syntaxes, making functions more property-like. (Our position can be summed up aptly as “functions are just named chunks of CSS syntax”.)
So that brings us to the Color spec. Color 3 was already a function-full spec, and Color 4 more than doubles that number, adding
color(). The first four of those look similar to the existing
rgb()/etc functions, just taking a couple of numbers, so they were originally designed with the same syntax, separating every number with commas.
color()was a bit more complex, more like a CSS property. It had to take a colorspace name, an arbitrary number of arguments to the colorspace, an alpha, then finally a fallback value in case the colorspace wasn’t loaded or was invalid. Putting commas between every value there just got ridiculous, not to mention made it difficult to read; in particular, it was hard to tell where the colorspace arguments ended and the alpha began.
So, I opened Issue 266 about it, and discussion eventually led us to making it use CSS property syntax pretty much exactly:
color()takes a comma-separated list of colors (each one serving as fallback for the previous), and within each color, everything is space-separated. Because colorspaces can take an arbitrary number of numeric parameters, the alpha value was ambiguous (hard to even tell whether or not there was an alpha at a casual glance), and so we employed the slash to separate it visually from the parameters.
At this point, tho, it was slightly weird to have this one color function use this particular syntax form, while none of the others used anything like it. Welp, all the color functions were on our wiki page’s list of things to overhaul anyway, so bombs away! We went ahead and changed all the new functions to use the same syntax (all values space-separated, with an optional slash-separated alpha), and then added a new syntax variant to the old functions with the same form.
(I stress, this is a new variant syntax, not a replacement. All your old
rgb(0, 255, 0)code is fine and will never be incorrect. We’re just classifying it as a legacy syntax; we’ve got a handful of those cluttering up CSS specs.)
So, now all the color functions use the same syntax form, and they all agree with our general push to make functions resemble properties more closely. It may feel a little weird at first, but I think you’ll appreciate it as you get used to it (a few characters less typing, at the very least). And we’ve been edging this way for quite a while – as far back as
linear-gradient()we were trying to use commas reasonably, with the complex sizing/positioning part up front completely space-separated and commas used only to separate the color-stop repetitions.
calcfor table layout to Values and Units 4
calcwith only percentage or only length is required to be resolved in Values and Units 4
color( [ colorspace? [ number+ | string ] [ / alpha ]? ]# [ , color ]? )
rgb( [r, g, b] | [ r g b [ / alpha ] )
calcserialization to it, and then publish the remainder of Values & Units 3 as CR.
Browse by date:
Browse by category: