W3C home > Mailing lists > Public > www-style@w3.org > November 2015

Re: [css-scoping] Scoping @font-face defined in shadow DOM

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 13 Nov 2015 11:26:50 -0600
Message-ID: <CAAWBYDDnZ4q3yfe7AiU5Wbf40d6TTuV+ST5JBfNpWEL2ZAadwg@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
On Fri, Nov 13, 2015 at 10:13 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> On Nov 11, 2015, at 4:41 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Wed, Nov 11, 2015 at 4:32 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>>> On Nov 11, 2015, at 1:51 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>> This doesn't address the other issue that I haven't been able to solve
>>>> yet, which is font names inheriting down into a shadow where the font
>>>> name is defined to be something else entirely.  That is:
>>>> <style>
>>>> @font-face { font-family: foo; src: local("helvetica"); }
>>>> body { font-family: foo; }
>>>> </style>
>>>> <custom-el>
>>>> <::shadow>
>>>>   <style>
>>>>   @font-face { font-family: foo; src: local("comic sans"); }
>>>>   h1 { font-family: foo; }
>>>>   </style>
>>>>   <h1>Comic sans heading, yay!</h1>
>>>>   <p>Whoops, Comic Sans body text.</p>
>>>> </::shadow>
>>>> </custom-el>
>>>> There's no way in the current system to make sure that the *inherited*
>>>> foo font refers to the outer face, but the specified one on the
>>>> heading refers to the inner face.
>>> Do you have any evidence indicating that this is a common scenario?
>> It will happen, and it's surprising and violates the composition
>> boundary we're trying to build.
> I don't think defining two font faces of the same name with different fonts is a common scenario, and is arguably a bad practice in the first place.  It's odd to favor such an edge case over a common scenario where a component wants to use a specific font.

You're missing the point - it's not an author defining two font faces
with the same name, it's a *component* author defining a font face
with a particular name, and a *page* author accidentally defining a
font face with the same name.  (Or one or the other context trying to
use a local font name that the other context defines as an explicit

Avoiding these kinds of clashes is the reason we go to the trouble of
making the host element show up in the shadow dom, but featureless,
etc.  We don't want hard-to-debug and confusing errors where the page
author and the component author happen to use the same class;
similarly we don't want to have confusing results when font-face names
happen to clash.

This is about making composability work well, not addressing an
intentional use-case.

>> Variables are substituted at
>> computed-value time, so as far as <body>'s descendants are concerned,
>> the inherited value of 'color' is "blue".  There's no variable
>> reference remaining to be confused later, so the <p> is blue
>> (expected, because the component was written to use the inherited
>> color value by default) and the <h1> is red (expected, because it's
>> using the variable declared inside the shadow).
>> Fonts (and several other things) are "substituted" or "resolved" at
>> used/actual-value time, which is why they run into the name-confusion
>> problem.
> Although my point was more that it's hard for authors to reason about which value will be used, you're right that th expectation of the author to use the inherited value (from the outside content) is preserved.

Yes, so fonts don't do that, and that's the problem. To make this work
well, we need some way to bind a font-name to a font-face at
declaration-time, and preferably make it happen automatically when
things cross shadow boundaries; perhaps this means screwing with
inheritance and rewriting font-names into some form that specifies
what tree the name comes from, or at least replaces it with a gensym
that uniquely attaches it to a particular font-face.

As I alluded, this problem isn't limited to @font-face.  You get the
same problems with, say, Regions - if the page and a component both
accidentally use the same flow name, they'll collide in confusing and
terrible ways.

Received on Friday, 13 November 2015 17:27:38 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:55 UTC