CSS WG Blog – Minutes Seattle F2F Part I: 2014-01-27 AM – Variables, Masking, Syntax, Shapes & Serialization, Shadow DOM

Minutes Seattle F2F Part I: 2014-01-27 AM – Variables, Masking, Syntax, Shapes & Serialization, Shadow DOM

By Dael Jackson February 22, 2014 (Permalink)
Categories: resolutions

Resolved: Publish Variables as CR once Tab has completed edits on remaining issue and prepared at Disposition of Comments.

Discussed addition of reference-box arguments to shape arguments for clipping.
Resolved: Defer the bounding-box value from clip-path and mask-origin to next level.
Resolved: Clipping/masking properties respond to box-decoration-break same as background images.
Resolved: Keep mask-box. No opinion on whether or not to do a slice image function yet; use cases are needed (that wouldn’t be solved by multiple border images).
Discussed coordinate systems of when applied to HTML+CSS.
Plan to republish Masking as WD to work through issues filed since LC publication.

Discussed feedback from i18n, particularly request to change @charset parsing; failed to record a resolution, but there seemed to be consensus on not changing from 2.1.
Discussed limiting @charset handling to first 1024 bytes; nobody has a problem with this. Also discussed white space within labels, since that’s the only thing that could result in such a case.
Discussed shifting environment encoding definitions from Syntax to Cascade.

Discussed Google proposal for one-shadow-level and all-shadow-level combinators. Proposed syntax was ^ and ^^; WG prefers using pseudo-elements (e.g. ::shadow and ::darkside, or fill in your fav name here) because:
1. more mnemonic.
2. reflects the fact that we’re crossing a tree boundary.
3. allows us to use parallel syntax for region- and page-based styling, which is structurally the same problem.
4. avoids the need for :top — can just use child combinator as needed.

Discussed :ancestor() and :host() selectors. Concerns raised:
- “ancestor” is too general, implies any ancestor, including those still in the shadow.
- problem is structurally the same as @global in scoped style; they should share the same syntax (or at least the same syntactic structure).
Also discussed ::content, which allows crossing from shadowed selectors to light elements channeled through the shadow via content.

Briefly touched on ability of ShadowDOM to represent form controls for styling. Tab explained that form controls’ internal structure should not be exposed to web pages to avoid dependency on any structure. (This prevents platform differences e.g. between mobile/desktop, or innovation and improvements in UI over time.) Some form of “magic” will therefore be used. Parametrized shadow-element selectors with predefined arguments might end up as the solution, but no concrete proposals yet. Google and MSFT are collaborating on this, however.
Google has, however, concluded that parametrized shadow selectors are more trouble than they’re worth for general use, and component libraries should simply document their “interface”.