CSS WG Blog

This is a page from the Cascading Style Sheets Working Group Blog. Some other places to find information are the “current work” page, the www-style mailing list, the Future of CSS syndicator, and the issue list on Github.

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.

Minutes Telecon 2016-08-03

By Dael Jackson August 4, 2016 (Permalink)
Categories: resolutions

In order to support TPAC planning, please add items to the wiki, including those that would require joint meetings. gregwhitworth was actioned to find out exactly what the plan is for Houdini at TPAC.
Resolved: Accept text as proposed for the ideographic character unit.
Resolved: Add lh and rlh to Values & Units 4 with a note on use cases it doesn’t solve and a link to max-lines.
gsnedders is going to confirm that the Variables test suite provides adequate coverage. If he finds that it does, the group will vote on PR next week.
Resolved: Take Grid to CR

Full Minutes

Color Function Syntax Update

By fantasai July 29, 2016 (Permalink)
Categories: general

From Tab’s blog post on the recent changes to the Color module:

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 <string> vs <number> vs <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 background property, or font names in the font-family property), 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 font shorthand, transition-delay vs transition-duration in the transition shorthand, or the multiple pieces of syntax in a border-image layer).

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”.)

Color

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 hwb(), gray(), lab() and lch(), and 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.

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

Minutes Telecon 2016-07-27

By Dael Jackson July 28, 2016 (Permalink)
Categories: resolutions

Some items being discussed on github have mentioned that they would be good F2F topics. Please add these items (and any other topics) to the wiki. Everyone planning on attending TPAC was also reminded to make bookings and pay for registration before prices go up.
Myles will be handling the font editing for Ahem.
Pretty much everyone agreed that user-select should be used value. gregwhitworth needed to check with his development team so the formal resolution will be recorded on next week’s call.
Resolved: Accept the changes in this commit to allow percentages as a resolved type.
Resolved: Hoist opacity from table box to its wrapper box>
Resolved: Defer the issue of calc for table layout to Values and Units 4
Resolved: A calc with only percentage or only length is required to be resolved in Values and Units 4
There was no decision on addressing a combined length and percentage. More thought on it was needed.
Resolved: Publish updated Values & Units 3 CR
Resolved: Use this color syntax: color( [ colorspace? [ number+ | string ] [ / alpha ]? ]# [ , color ]? )
Resolved: Backport slash to the short functions like: rgb( [r, g, b] | [ r g b [ / alpha ] )

Full Minutes

Minutes Telecon 2016-07-20

By Dael Jackson July 21, 2016 (Permalink)
Categories: resolutions

Resolved: Add AbobeRGB and ProPhotoRGB as predefined spaces. Allow either the table of numbers or an ICC v.4 profile with relative colorimetric intent
Resolved: Add a single CMYK profile, with relative colorimetric intent, mainly to use as a fallback
TabAtkins explained the work being done on web components which will solve for many of the problems authors are facing around namespaces. The group agreed that this approach did seem like it would help and more experimentation in this direction would lead to more progress. The group also actioned TabAtkins to create a wiki to gather the history of work and experimentation and allow authors to comment and contribute to further progress.
Resolved: Outside bullets are outside the box (See testcase).
Resolved: Accept the proposed change for Grid (implied min takes on the constraint defined on the track).
Everyone has a week to review the proposal for block-axis baseline. Next week the group will resolve on block-axis and then vote to publish Grid.
Resolved: Start a level 4 draft of Values & Units, move calc serialization to it, and then publish the remainder of Values & Units 3 as CR.

Full Minutes

Minutes Telecon 2016-07-13

By Dael Jackson July 14, 2016 (Permalink)
Categories: resolutions

Anyone who has not done so should book for TPAC soon as hotels are filling up.
The dates for the January 2017 F2F are tentatively set as the 11th, 12th, and 13th. Anyone with problems for these dates should raise their concern in the next two weeks on a call or on the mailing list.
The spring meeting will be in Japan. On the call late April was suggested, but afterwards in IRC it was brought up that Golden Week (April 29-May 6) needs to be avoided and that there are US school holidays in that time period that may also need to be avoided.
There was a strong desire to ensure that CSS-AAM is done as a joint effort between the APAWG and CSSWG. Rossen indicated the coordination on this was a part of the new CSSWG charter.
Resolved: Accept changes proposed here to have fit-content apply on every step of the algorithm instead of at the end.
Resolved: Change MQ4 to p3 from dci-p3
Resolved: All alpha for color functions can be number and percentage
Resolved: Opacity also takes number or percentage
Resolved: rgb should be extended to allow an optional alpha. Likewise hsl. Pending compat analysis by TabAtkins.
There was not a decision reached on if commas should be, should not be, or should optionally be present in color nor in other color functions like rgb and hsl. There were four options on the table for the group to discuss on github and revisit for voting next week. They are:
1. always require commas
2. commas are optional everywhere in color functions
3. commas are optional in old functions such as rbg() and drop the ones from new ones
4. commas are required in old functions such as rbg() and drop the ones from new ones

Full Minutes

Minutes Telecon 2016-06-29

By Dael Jackson June 30, 2016 (Permalink)
Categories: resolutions

Resolved: Accept option C: keep the tracks in the track listing, but force them to be zero-sized and suppress any gutters between adjacent collapsed tracks.
No one has had time to fully think through the best way to address the removing restrictions on baseline-aligning things that have block-axis baselines problem, but fantasai, TabAtkins, Rossen, rachelandrew, and Mats are interested in investigating. The first step is for fantasai to add more diagrams to the spec and everyone else to review the baseline-aligning sections of the spec.
Resolved: Link to the compat spec to reference prefixed properties in the Snapshot and specs with relevant entires and monitor for problems in the future.
There were five possible solutions to the potential combinatorial explosion with first and last baseline:
1. Explode alignment-baseline.
2. Use last and baseline as separated keywords in align/justify-self/content as well as alignment-baseline.
3. Use last-baseline in align/justify-self/content and last baseline in alignment-baseline.
4. Introduce a new property to choose first vs last for vertical-align, and have last-baseline decompose to last in that property plus baseline for alignment-baseline.
5. Introduce first-baseline and last-baseline to alignment-baseline(to match Align), but also allow first and last space-separated prefixes for all values of alignment-baseline(to avoid explosion). (This means that both first-baseline and first baseline would be valid)
- The group rejected options 1 & 3 and fantasai will add some examples to clarify the difference between the remaining options.

Full Minutes

CSS Scroll Snap Module Level 1 Merges Change Proposal

By fantasai June 24, 2016 (Permalink)
Categories: publications

The CSS Working Group has published an updated Working Draft of CSS Scroll Snap Module Level 1. This module contains features to control panning and scrolling behavior with “snap positions”, to which the UA is biased to land after a scroll operation.

This publication represents the completed merge of Tab and Fantasai’s Change Proposal that incorporates www-style feedback into Microsoft’s CSS Snap Points Module proposal championed by Matt Rakow. At this point all three editors will be working together to resolve the remaining open issues and address any further feedback on the module.

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list www-style@w3.org with the spec code ([css-scroll-snap]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

CSS Generated Content Initial Rewrite

By fantasai June 24, 2016 (Permalink)
Categories: publications

The CSS Working Group has published a Working Draft CSS Generated and Replaced Content Level 3. This module specifies the generated content features (content property and related functionality) in CSS.

This is the first draft of a complete rewrite of this module, and is very rough. Large chunks (i.e. most) of the 2003 draft have been deleted, and major new functionality over CSS2.1 consists mainly of imports from the GCPM module. New features include:

plus a handy new syntax for alternate text: content: url(sparkle.png) / "New!";

We expect future work on this module to be pinning down the actual syntax and behavior of all the exciting new features imported from GCPM. For those who want to toy with implementations, most CSS->PDF renderers already support a significant subset. Significant changes since 2003 are listed in the Changes section.

Please send feedback by either filing an issue in GitHub (preferable) or sending mail to the (archived) public mailing list www-style@w3.org with the spec code ([css-content]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)

Minutes Telecon 2016-06-22

By Dael Jackson June 23, 2016 (Permalink)
Categories: resolutions

astearns will input the dates he proposed on the private mailing list (available here)
Resolved: Publish CSS Scroll Snap
Resolved: Line break opportunities should be controlled by the parent.
The ‘auto’ value of offset-position will be written to mean do nothing to the position of the element.
‘contain’ will be moved into offset-path as it’s only relevant when there’s an angle.
Resolved: Change the initial value of offset-rotation to 0deg.
jihye will move the offset-* properties into the Motion Path.
Resolved: Rename update-frequency to update (Media Queries issue #1).
Resolved: Rename normal to fast (Media Queries issue #1).
Resolved: Move inverted colors to level 5 (Media Queries issue #8)
Resolved: Move custom MQ to level 5 (Media Queries issue #9).
Resolved: Publish a new WD of Media Queries 4.
A decision on what happens with grid line names when dropping tracks (issue here) was deferred until next week to give people time to review.
Resolved: vertical-align: baseline means first baseline except for inline-blocks (due to CSS2.1 legacy)

Full Minutes

Minutes San Francisco F2F 2016-05-11 Part II: Scroll Snapping, Color, Grid, Flexbox, Inline

By Dael Jackson June 18, 2016 (Permalink)
Categories: resolutions

Scroll Snapping

Archival Copy of the Change Proposal being discussed available here

Resolved: No ability to specify the strictness of snapping separately per axis.
Resolved: Allow the keyword to be dropped, default to proximity.
Resolved: Ordering of keywords is strict in scroll-snap-type (to allow for extensions)
Resolved: Values are x | y | block | inline | both | point , where point would be dropped after next publication.
Resolved: Require (for now) an explicit axis and will gather more info as we can (to decide between physical and logical direction as the default).
Resolved: Make snap-align behave like a subset of background position (from fantasai’s proposal).
Resolved: Add section 6.2.2 (Snapping Boxes that Overflow the Scrollport) and add issues.
Resolved: Add section 6.2.1 (Scoping Valid Snap Positions to Visible Boxes) as an open issue
Resolved: Add section 6.2.3 (Unreachable Snap Areas)
Resolved: Merge section 6.3 (scroll-snap-stop) with an issue about whether it applies to 2D and an issue to bikeshed “normal”
Resolved: Merge section 7.3 (Choosing Snap Positions) with A parenthetical of “corridor” point moved to start the paragraph and JS element-targetting scrolls added into the :target paragraph
Resolved: Add section 7.1 after removing “explicit” “inertial” and “directional” definitions, moving the first sentence and adding a more precise definition of when an active scrolling operation is done so we know when to start snapping.
Resolved: Merge 7.0 (introductory text) too
Resolved: Add fantasai and TabAtkins as editors to scroll snapping
Resolved: Shortname css-snappoints -> css-scroll-snap

Full Minutes || Spec Referenced

CSS Color

There were several actions recorded to make improvements to the spec. They were to:
- add note explaining a reasonable range for C in lch to the spec
- remove commas between in the color examples
- fix Rec.2020 and Rec2020 to be rec2020, and DCI-P3 P3 to either (consistently) dci-p3 or p3
- color fallback should be like font list fallback.
- add a working-color-space at-rule, which affects the entire document
The breakout session proposed resolving to publish WD for Color and MQ4.
Resolved: Do black point compensation when converting from profile to another.
Resolved: If you accurately describe the output device’s color profile in an @color-profile rule then a sane implementation will not alter your colors so this is sufficient as a replacement for device-cmyk in general and provides a good RGB fallback automatically.