- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 27 May 2014 12:42:23 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "www-style@w3.org" <www-style@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
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