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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 8 Dec 2015 14:29:51 -0800
Message-ID: <CAAWBYDDgQ8+GVsXTZbv4+Jp2b_sbGEQC3t7b_oQin9H=9YGWQg@mail.gmail.com>
To: Zack Weinberg <zackw@panix.com>
Cc: www-style list <www-style@w3.org>
On Fri, Nov 13, 2015 at 10:01 AM, Zack Weinberg <zackw@panix.com> wrote:
> On Fri, Nov 13, 2015 at 12:26 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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.
>
> This is effectively a macro hygiene problem, isn't it?  There are good
> off-the-shelf algorithms for that...

Yes, basically, and I'm familiar with such algorithms - I've written
my share of hygienic Common Lisp macros.  The question is how to apply
that to CSS in a reasonable way.  It might be okay to simply gensym
the font-family name as it crosses a shadow boundary, and not expose
the mapping to the page's code directly.

~TJ
Received on Tuesday, 8 December 2015 22:30:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:31 UTC