@font-face and @property constructs in Shadow Roots

[Westbrook]

Description

Whether it is @font-face or @property, an intersection of confusing spec'ing and partial implementation leaves a number of nice capabilities out of reach of shadow root users. Placing @font-face or @property within shadow roots is ignored in some browsers degrading the experience of pre-packaged web components cross browser. This is an area where WPT could also be leveraged to support not falling into this same trap with other and future @ sigil based CSS APIs.

@font-face

• FF bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1077396
• Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=336876

@Property

• Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1231135

Rationale

The code needed to packages a custom element for reuse should be usage within the custom element package.

Specification

w3c/csswg-drafts#1995

Tests

No response

[gsnedders]

Whether is @font-face or @Property an intersection of confusing spec'ing and partial implementation leaves a number of nice capabilities out of reach of shadow root users.

I can't understand what this means?

[Westbrook]

@gsnedders here's a demo to, hopefully, clarify: https://codepen.io/nolanlawson-the-selector/pen/MWVeLVV As you see, while the component is attempting to fully encapsulate everything about delivering it, including the fonts to use, this process only works in Safari at current. Other browsers ignore the @font-face rule within the shadow root and fail to deliver bolded text:

Fail state:

Pass state:

Other APIs managed with the @ sigil seem to experience the same issue, e.g. @property (at least in Chrome where it is currently implemented), and it while it's not something that could be part of "Interop 2023" the idea that there was some test driven process whereby we could ensure that what is an exciting crop of future @ sigil based APIs (e.g. @position-fallback) do not suffer this same situation.

[gsnedders]

Specification

https://drafts.csswg.org/css-scoping/#shadow-names

I think?

[gsnedders]

And while not one of the at-rules mentioned, these tests cover @keyframes.

One could probably make some largely derivative tests of those for @font-face, which I believe is the only other at-rule which defines a global name supported cross-browser.

[gsnedders]

And to be explicit: I think we should consider this proposal to cover "at-rules that define global names", rather than specifically @font-face and @property. There's value in fixing the rest of this even without #158 (@property).

[foolip]

@gsnedders can you work with @Westbrook to update the issue description if you want to expand the focus?

[gsnedders]

To be clear, I think we should just test the at-rules that define global names which are supported; I don't think we should require every browser to implement @property (or @color-profile, etc.) as part of this.

[emilio]

Did everyone agree in a consistent model for this? @keyframe sorta-kinda-works in a sorta-kinda-interoperable way, but it's a mess, and definitely not something we can do for @font-face.

[emilio]

Ah current spec text is https://drafts.csswg.org/css-scoping/#shadow-names which is mentioned above indeed. In general, fixing this up is sensible, and the spec seems reasonable.

[foolip]

Grepping WPT for "shadow-names" I found these tests:
https://github.com/web-platform-tests/wpt/blob/master/css/css-scoping/keyframes-003.html
https://github.com/web-platform-tests/wpt/blob/master/css/css-scoping/keyframes-004.html
https://github.com/web-platform-tests/wpt/blob/master/css/css-scoping/keyframes-005.html
https://github.com/web-platform-tests/wpt/blob/master/css/css-scoping/keyframes-006.html

There aren't any tests including "font-face" in css/css-scoping/ in WPT, so I guess that's untested.

[foolip]

https://drafts.csswg.org/css-scoping/#shadow-names doesn't mention @property so I went to look for the spec for this. I found https://drafts.css-houdini.org/css-properties-values-api/#at-property-rule which says:

A @property is invalid if it occurs in a stylesheet inside of a shadow tree, and must be ignored.

I suspect that makes https://bugs.chromium.org/p/chromium/issues/detail?id=1231135 invalid, but I've asked to confirm.

[nairnandu]

Thank you for proposing @font-face and @property in shadow trees for inclusion in Interop 2023.

We wanted to let you know that this proposal was not selected to be part of Interop this year. We had many strong proposals, and could not accept them all. As discussed in the issue comments, we could not find any tests for @font-face or @property in shadow trees. We would welcome this proposal being resubmitted for a future round of Interop once there are tests covering the behavior.

For an overview of our process, see the proposal selection summary. Thank you again for contributing to Interop 2023!

Posted on behalf of the Interop team.