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

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.

> If this was an issue, then passing a CSS variable through a shadow boundary is similarly problematic.

No it's not - you have to explicitly write your code to declare and
request variables, and the only way to run afoul of inheritance is to
use a variable in a way that it will normally be invalid and ignored.
That's simply a mistake in one's code to start with - there's no valid
reason to do so.

> Consider:
>
> <style>
> body { --foo: blue; color: var(--foo); }
> </style>
> <custom-el>
>  <::shadow>
>    <style>
>    div { --foo: red; }
>    h1 { color: var(--foo); }
>    </style>
>    <div>
>      <h1>Comic sans heading, yay!</h1>
>      <p>Whoops, Comic Sans body text.</p>
>    </div>
>  </::shadow>
> </custom-el>

I'm not sure what this example is trying to show.  Are you assuming it
would color the <p> text red?  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.

~TJ

Received on Thursday, 12 November 2015 00:42:39 UTC