- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 11 Nov 2015 18:41:51 -0600
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, www-style list <www-style@w3.org>
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