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

This is effectively a macro hygiene problem, isn't it?  There are good
off-the-shelf algorithms for that...

On Fri, Nov 13, 2015 at 12:26 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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
> @font-face.)
>
> 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.
>
> ~TJ
>

Received on Friday, 13 November 2015 18:01:45 UTC