Re: [css-font-loading] feedback

On Tue, May 27, 2014 at 12:35 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, May 27, 2014 at 1:58 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Mon, May 26, 2014 at 6:51 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> Should FontFaceSource be on the CSS global instead? CSS.fonts rather
>>> than document.fonts in a document environment and self.fonts in a
>>> worker environment.
>>
>> Maybe?  It's not strictly a CSS thing, but I dunno what's most
>> appropriate here.  I don't think there's really a "correct" place, so
>> it's more a matter of what patterns we generally want to develop in
>> the placement of things like this.
>
> It seems like the scope is at least wider than document. E.g.
> presumably you can use these fonts on a <canvas> element located in a
> document returned by XMLHttpRequest. And we might not want such
> documents to contain a FontFaceSet attribute.

Decent argument.  I'll think on this.

>>> In the FontFace constructor you set status to "loading" at some point,
>>> but it's not clear from which task or microtask this is done. How can
>>> this be observed?
>>
>> I'm not sure what you mean by this.  The algorithm from step 2 onward
>> is done asynchronously.  Do I need further detail?  If so, what?  (And
>> also, is there written guidance on how to do it, if I'm doing it
>> wrong?)
>
> Well, you're changing the status but can that actually be observed
> somehow? If not, why are you changing the status? Changing the status
> of something and making that observable typically requires queuing a
> task, unless you use a promise, but in that case you can only change
> the status once, by resolving the promise.

I'm not sure what you're talking about here, so I've pinged you on
IRC.  Hopefully we can resolve it better there.

>>> You say "reject with a NetworkError" but you don't define
>>> NetworkError. Maybe you mean a DOMException whose name is
>>> "NetworkError"? Same for exception/error names mentioned elsewhere.
>>
>> Yes, that is what I mean.  Is there written guidance on how to
>> properly invoke errors in a spec document?
>
> Well, you could look at how http://dom.spec.whatwg.org/#concept-throw
> does it...

I was specifically looking for something other than "remember to check
this specific spec to see how it does it".  ^_^  Like, CSS puts some
spec-authoring guidance on its wiki
<http://wiki.csswg.org/spec#coordination-between-specifications>.
Something similar (even in our wiki - if you don't have an account,
just send me some guidance and I can add it myself) would be great.

> In due course this should be integrated into IDL at which
> point it hopefully provides the proper wording for both normal members
> and promise returning members.

Not sure how IDL would help, since this is prose text throwing the exception.

~TJ

Received on Tuesday, 27 May 2014 19:43:10 UTC