W3C home > Mailing lists > Public > www-style@w3.org > February 2016

Re: [Font Loading]

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 16 Feb 2016 11:08:10 -0800
Message-ID: <CAAWBYDDc5uq-=RnwN4Jmjta5BS=5YYFpGX2w5wVCeyAYRbtewg@mail.gmail.com>
To: "Myles C. Maxfield" <mmaxfield@apple.com>
Cc: www-style list <www-style@w3.org>
And I just saw the other thread where you resent this question with
correct subject, and heycam sent essentially the same response, so
ignore this. ^_^

On Tue, Feb 16, 2016 at 11:07 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, Feb 4, 2016 at 12:50 AM, Myles C. Maxfield <mmaxfield@apple.com> wrote:
>> Hello,
>> I'm implementing the CSS Font Loading spec in WebKit. During the implementation, I have come across this issue in the spec:
>> When FontFaces are added to the Document's FontFaceSet, a layout may occur at any time which triggers these FontFaces to be load()ed. This layout uses the FontFace's attributes (family, weight, etc.) to discover which FontFaces need to be load()ed. However, during the load, script may change attributes of these FontFaces so that they no longer match what the layout requires. Instead, modifying FontFace's DOMString attributes should be a no-op (possibly additionally throwing an exception) after the FontFace has been load()ed.
> You can change @font-face descriptors at any time, including in the
> middle of a load for the very face they represent, and possibly make
> the face no longer match what is requested by CSS.  What makes
> FontFace any different?  I'm loathe to add restrictions to FontFace
> that aren't reflected in @font-face.
> ~TJ
Received on Tuesday, 16 February 2016 19:08:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:00 UTC