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

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

From: Ryosuke Niwa <rniwa@apple.com>
Date: Fri, 13 Nov 2015 08:13:57 -0800
Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
Message-id: <893275BC-113B-4B5A-AB08-C772E95A213C@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

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

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

- R. Niwa
Received on Friday, 13 November 2015 16:14:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC