CSS WG Blog front page
Updated Working Draft for Media Queries 5
The CSS WG has published an updated Working Draft of the Media Queries Level 5.
Media Queries allow authors to test and query values or features of the user agent or display device, independent of the document being rendered. They are used in the CSS @media rule to conditionally apply styles to a document, and in various other contexts and languages, such as HTML and JavaScript.
Media Queries Level 5 supersedes previous levels, and in introduces a broad range of new media features, both to better detect the characteristics of the environment as well as the preferences of the user.
This update leaves the fundamental media queries mechanism unchanged, but brings significant revisions, addition, and even deletions to the supported media features. Significant changes are detailed in the changes section.
The CSS-WG is likely to start stabilizing this feature-set soon, so while things may still change somewhat before we reach Candidate Recommendation, now is likely a good time for in-depth review for those that can tolerate a moderate amount of changes.
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 ([mediaqueries-5]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)
Updated CRD of Media Queries Level 4
The CSS WG has published a Candidate Recommendation Draft and invites implementations of the Media Queries Level 4.
Media Queries allow authors to test and query values or features of the user agent or display device, independent of the document being rendered. They are used in the CSS @media rule to conditionally apply styles to a document, and in various other contexts and languages, such as HTML and JavaScript.
Media Queries Level 4 describes the mechanism and syntax of media queries, media types, and media features. It extends and supersedes the features defined in Media Queries Level 3, and marks a shift from attempting to categorize different devices into distinct media types to describing them through media features.
This republication of MQ4 is a minor update to publish some editorial tweaks and to correct an issue in the syntax description.
Significant changes through various versions are listed in the changes section.
Implementors are encouraged to complete their support for the features described in this specification and to contribute to the test suite.
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 ([mediaqueries-4]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)
CSS Snapshot 2021 Published
The CSS Working Group has published the CSS Snapshot 2021. This Working Group Note indexes all the CSS specifications that are reasonably complete or stable as of 2021. (You can also find a complete list of all our specifications, including those unstable and in progress, on the current work page.) The latest snapshot is also always available at w3.org/TR/CSS/.
As usual, you can 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-2021]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)
CSS Values and Units Level 4 Update
The CSS Working Group has published an updated Working Draft of CSS Values and Units Level 4. This specification defines the CSS property definition grammar, and
the value types that are common across many specs, such as <length> or
<string>.
This update defers the toggle() and attr() functions to Level 5, and includes a first draft of integration with the Fetch specification. Other changes since the last WD are largely error corrections and refinement of existing features, see full changes list. We expect this to be the full feature set for Level 4, and will be working to resolve the remaining open issues in preparation for a transition to Candidate Recommendation.
Existing Level 4 additions since Level 3 include mix() notation, src() notation, a variety of new viepwort units, typographic units for ideographic characters and line-height-relative measurements, and a slew of math functions including comparisons, rounding, and trigonometry. Future additions will go into Level 5.
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-values-4]) and your comment topic in the subject line. (Alternatively, you can email one of the editors and ask them to forward your comment.)
Updated WD of CSS Overflow Level 3
The CSS Working Group has published an updated Working Draft of the CSS Overflow Module Level 3. This module contains the features of CSS relating to scrollable overflow handling in visual media, including the overflow property and its longhands; line-clamp, its longhands, and its legacy pre-standard syntax; and the text-overflow property. A few additional features introduced in support of the CSS Containment Module are also defined: overflow: clip and the overflow-clip-margin property.
Major changes since the previous Working Draft include:
See the Changes section for further details.
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-overflow-3]) 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 2021-11-17
- The meetings for next week and the last 2 weeks of December are cancelled due to holidays. There is interest in doing an extended call on 8 December to make it though more of the agenda+ topics. A decision will be made on the mailing list.
- In continuing to solve for issue #4497 (Limit local fonts to those selected by users in browser settings (or other browser chrome)), the group reviewed a proposed solution from Felipe. The proposal doesn’t specifically call out using a locally-installed font which does have use cases. This could also be a fingerprinting mechanism. There is concern on using a permission prompt to inform the user since fingerprinting is complex to explain and there is already user fatigue around permission prompts.
- Resolved: format() serializes with strings (Issue #6328: @font-face src: url() format() keywords vs. strings ambiguous in spec)
- Resolved: font/ MIME type registry manages valid values of format() (Issue #6328)
- Resolved: Accept proposal (Issue #6776: When an import rule fails to load or has an unsatisfied condition, does the layer still count?)
- Resolved: Republish css-cascade-5
- Resolved: Accept edits, expand to allow aliased functions (Issue #6193: define parse-time value aliasing)
- Resolved: Add this to the Value Definition Grammar (Issue #5728: Clarify that function component values need to be followed by parentheses)
- Resolved: Semi-replaced elements stretch in both directions in abspos (Issue #6789: Behaviour of semi-replaced elements)
- The group was leaning toward resolving that background on root elements are not affected by transforms for issue #6683 (Transforms and backgrounds on root element). dbaron will look into the effects of filters on root element before the group resolves on it.
Full Meeting Minutes
Minutes Telecon 2021-11-10
- There are several people coordinating to review pull request #6175 (Formalize fetching and resource timing reporting)
- Resolved: Accept proposal (Issue #6797: Algorithm for initial counter value in reversed list should repeat the last increment instead of the 1st one)
- There are several smaller questions that need to be resolved in order to address issue #6793 (Clarifications on [video-]dynamic-range MQs). There are editorial changes necessary to differentiate similar media queries. Additionally, there is clarification needed to state what the combo of UA and output device is intended to be a superset of the values. Last, there needs to be a better definition about what should be returned and when for video-dynamic-range. Discussion will continue on GitHub to develop proposed new text.
- The group will wait on Firefox to see if they can change their behavior before resolving on issue #6789 (Behaviour of semi-replaced elements)
- The group will revisit issue #6773 (Consider reversing the resolution of #3847) once there is more implementation experience to indicate the right direction.
- Resolved: Move @color-profile and device-cmyk() to L5 (Issue #6765: Defer @color-profile to L5)
- Resolved: Add srgb-linear color space (Issue #6087: Expose Linear-light sRGB as CSS syntax?)
- Resolved: WG leans towards weak proximity at this time, and recommends this direction for prototyping to get more feedback (Issue #6790: Strong vs weak scoping proximity)
Full Meeting Minutes
CSS Transforms Level 2 Updated
The CSS WG has published an updated Working Draft of the CSS Transforms Module Level 2.
CSS transforms allow elements styled with CSS to be transformed in two-dimensional or three-dimensional space. Level 2 (currently mostly a delta specification) adds new transform functions and properties for three-dimensional transforms, and convenience functions for simple transforms.
The full list of substantive changes in this working draft (relative to the First Public Working Draft, which is really what separated this material from Level 1 rather than the first publication of the material) is listed in the Changes section.
Please review the draft and file issues in the GitHub repository (or, if needed, send them by email to www-style@w3.org). Either way, please prefix the summary/subject with [css-transforms-2].
A few pieces that I’d like to highlight from the full changes section linked above are the following:
- The edits for w3c/csswg-drafts#3305 (to reflect that 3D-ness of transforms should not be stored or determined by the syntax used, that is, that using 3D syntax with something that is expressable as 2D should not be different from something expressed in 2D syntax) are only half-done. They’re done for individual transform properties, but they’re not done for the functions in the transform property. I was hoping to do this before publication, but I think it likely requires a good bit of new text rather than modification to existing text (since the currently implemented behavior isn’t defined in the spec), so I’d like to take the time to think about it more carefully. (Once it’s done, it will also need warnings that it might not be Web-compatible.)
- Another interesting set of edits is the following set:
These edits help make the spec’s model more consistent internally, and also a bit clearer, although they also align more clearly to the Chromium/Gecko behavior rather than the WebKit behavior. (I think some of the text that was there would have made sense if the spec had WebKit’s model for 3D rendering contexts, but I think it probably doesn’t make sense with the spec having the model that’s used in Chromium and Gecko.)
The background behind this is that my understanding of the difference between the model currently implemented in WebKit and the model currently implemented in Chromium and Gecko is that:
- In the absence of preserve-3d, WebKit performs 3D intersection between siblings, whereas Chromium and Gecko separately flatten each sibling after applying its transform and its parent’s perspective.
- preserve-3d allows elements to be connected into a single 3D scene (a “3D Rendering Context”) in which the elements are intersected in 3D and then the resulting scene is flattened together.
- In Chromium and Gecko, this flattening includes the root-most element with preserve-3d, its descendants that are connected by chains of elements that all have preserve-3d, and their children. It includes that root-most element’s transform and its parent’s perspective.
- Analogously to the situation in the absence of preserve-3d, in WebKit this scene also includes the siblings of that root-most element. (But I believe it does not consider the transform on that root-most element’s parent.)
- As a result of this difference, in the Chromium/Gecko model and in the spec, the element that is considered to “establish” the 3D scene is the root-most element with preserve-3d, whereas in WebKit the element that is considered to “establish” the 3D scene is its parent. (The establishing element is effectively the element responsible for the flattening.)
While the spec defined the construction of 3D scenes in the way that matches the Chromium/Gecko model, there were a few definitions that matched the WebKit model instead. These edits essentially fix those definitions to match the Chromium/Gecko model, and then do some further cleanup on the definitions.
Applying the spec definitions as previously written may not have been Web-compatible, since it would have implied results that did not match any browser. Essentially I’d think of this as that the Chromium/Gecko model and the WebKit model differ by “half” a step up the the tree, whereas applying these definitions as previously written would have caused the spec’s requirements to differ from WebKit by a “full” step up the tree and from Chromium/Gecko by “half” a step up the tree (since they were written in terms of the WebKit model’s concept of “establishing element”). In this description, a full step up the tree (meaning including one more ancestor and its children in the 3D scene) consists of two half-steps: the first half-step is that of merging the siblings of the current root into the scene (and thus making the new root be the old root’s parent), and the second half-step is applying the transform of the new root (along with the perspective of its parent). Chromium, Gecko, and WebKit currently all agree on the overall transform; the difference in behavior affects which elements are part of the 3D scene.
The spec still has a large number of open issues.
In the near future, I’m hoping to:
- continue to slowly make progress on the list of issues, and
- work specifically on defining backface-visibility better, and finding a way to move towards interoperability in a way that doesn’t break (too much) content on the Web. In particular, I’d like to provide clear definitions of:
- which descendants do and don’t get hidden when an element has ‘backface-visibility: hidden’, and
- what grouping effects ‘backface-visibility: hidden’ has. (Causing more grouping effects makes it easier to include more descendants, which is likely the desired behavior in most cases.)
Minutes Virtual TPAC 2021-11-03
- Resolved: Publish an updated CR draft of css-variables (Issue #6783: Publishing css-variables)
- heycam will create a list of all remaining env variables that need to be added to the environment variables spec so they can be resolved on and the FPWD can be published. (Issue #6729: Publish css environment variables fpwd)
- Resolved: Accept fantasai’s proposal, get it written into spec, have tests updated to match (Issue #6609: Directionality inheritance into Shadow DOM)
- Resolved: Change nesting draft to use open/close brackets, and add a note to show that syntax vs. what Tab would prefer (Issue #4748: Syntax suggestion)
- Resolved: Our preference is for a single syntax for nesting (Issue #4748)
- Resolved: Don’t have nesting om using its own interface; instead, just allow style rule to contain a list of style rule (Issue #4748)
- Resolved: SVG clip-path bounding box units refer to CSS border-box of element to which applied (Issue #5786: “object bounding box” needs to be better defined for CSS boxes)
- The Masking spec editors were given an action to audit the spec for other ambiguities similar to the object bounding box one.
- Resolved: clip-path and masking should follow same rules as backgrounds with regards to box-decoration-break (Issue #6383: Not clear how clip-path applies to fragmented elements)
- Resolved: Take all the “don’t implement this” notes out of Media Queries 5 (Issue #4834: Note/Issue on not shipping early proposals)
- A note will be added to the video-* media queries to state that what is in the spec is likely wrong, but the group hasn’t figured out the right approach yet (Issue #4834).
- Resolved: Skip 0 increments when determining the starting value of a reverse counter (Issue #6738: Automatic start value of reversed list is affected by ‘counter-increment: counter 0’ nodes)
- Resolved: Elements with ancestors of content-visibility:hidden will have no boxes while in top layer. If removed from top layer they get their box back (Issue #6728: Top layer interactions with content-visibility: hidden)
- Resolved: If the subtree of an element contains a top-layer element it is relevant to the user (Issue #6727: Consider top layer elements ‘relevant to the user’ for content-visibility: auto)
- There is agreement that issue #4598 (Static ranges and css-contain) is a problem that should be solved and the solution should be as limited in scope as possible. The result would need to be observable to the author so they can respond and the current proposal doesn’t have that observability. The discussion will continue on github to develop a solution.
- Resolved: Accept iank’s proposal to guarantee full layout algorithm is always forward moving (Issue #6426: Ancestor Layout Loops with Single-Axis Containment)
- Once the edits for issue #6426 are in the spec, a request will be made for FPWD of Contain 3.
- Resolved: Publish WD for Transforms L2
- Resolved: Add dbaron as co-editor of Transforms L1
- Resolved: Add the cssom rules as .name and .namelist (Issue #6576: Cascade Layers need CSSOM support)
- Resolved: It [revert-layer] would revert the style attribute and nothing else (Issue #6743: revert-layer keyword in style attribute)
- Resolved: revert-layer reverts animation origin and nothing else (Issue #6749: revert-layer keyword in keyframes)
- Resolved: Republish Highlight API
- Resolved: Punt attr() and toggle() to Values Level 5 (Issue #6753: Punt attr() and toggle() to Level 5)
Full Meeting Minutes Part I and Part II
Minutes Joint CSS-Internationalization Telecon 2021-10-27
- There were several points to cover in the proposal to make switching to logical keywords easy for issue #1282 (Flow-relative Shorthands) and the group didn’t have time to reach resolution on the issue.
- There was broad agreement that the group wants to encourage authors to use logical whenever available
- Of the outlined roadmap steps, they did agree to forgo the proposed @rule
- There was originally opposition to the !keyword syntax, but during discussion it became clear that it might be the best option
- Discussion will continue in future meetings to unblock development
- Issue #4910 (Criteria for generic font families) was raised as a meta issue around the criteria a generic font family must meet but it lead to discussion and requests to have user created generic font families. There’s interest in exploring user created generic font families so a separate issue will be raised.
Full Meeting Minutes
Archives
Browse by date:
Browse by category:
![[Photo: group photo of the CSS working group in San Francisco]](/Style/CSS/csswg-2016.jpg)
Contact: