Re: Last Call for "CSS Font Loading Module Level 3"
On Tue, May 27, 2014 at 3:47 PM, Jonas Sicking wrote: > On Tue, May 27, 2014 at 12:14 PM, Tab Atkins Jr. wrote: >> On Tue, May 27, 2014 at 11:44 AM, Jonas Sicking wrote: >>> On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr. >>> wrote: > Separately, FontFace.loaded seems to fulfill the same purpose as > FontFaceSet.ready(). I.e. both indicate that the object is done > loading/parsing/applying its data. It seems more consistent if they > had the same name, and if both were either an attribute or both were a > function. No, the two do completely different (but related) things. Why do you think they're identical? One fulfills when a *particular* FontFace object finishes loading, the other repeatedly fulfills whenever the set of loading fonts goes from non-zero to zero. >>> >>> Semantically they both indicate "the async processing that this object >>> was doing is done". Yes, in one instance it just signals that a given >>> FontFace instance is ready to be used, in the other that the full >>> FontFaceSet is ready. Putting the properties on different objects is >>> enough to indicate that, the difference in name doesn't seem >>> important? >> >> The loaded/ready distinction exists elsewhere, too. Using .loaded for >> FontFaceSet is incorrect, since in many cases not all of the fonts in >> the set will be loaded. > > Sure, but would using .ready() for FontFace be wrong? Depends on how we end up designing the loaded/ready duo. ~TJ
Re: Last Call for "CSS Font Loading Module Level 3"
On Tue, May 27, 2014 at 12:14 PM, Tab Atkins Jr. wrote: > On Tue, May 27, 2014 at 11:44 AM, Jonas Sicking wrote: >> On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr. >> wrote: Separately, FontFace.loaded seems to fulfill the same purpose as FontFaceSet.ready(). I.e. both indicate that the object is done loading/parsing/applying its data. It seems more consistent if they had the same name, and if both were either an attribute or both were a function. >>> >>> No, the two do completely different (but related) things. Why do you >>> think they're identical? One fulfills when a *particular* FontFace >>> object finishes loading, the other repeatedly fulfills whenever the >>> set of loading fonts goes from non-zero to zero. >> >> Semantically they both indicate "the async processing that this object >> was doing is done". Yes, in one instance it just signals that a given >> FontFace instance is ready to be used, in the other that the full >> FontFaceSet is ready. Putting the properties on different objects is >> enough to indicate that, the difference in name doesn't seem >> important? > > The loaded/ready distinction exists elsewhere, too. Using .loaded for > FontFaceSet is incorrect, since in many cases not all of the fonts in > the set will be loaded. Sure, but would using .ready() for FontFace be wrong? >> In general it would be nice if we started establishing a pattern of a >> .ready() method (or property) on various objects to indicate that they >> are ready to be used. Rather than authors knowing that they need to >> listen to "load" events on images, "success" events on >> IDBOpenRequests, .loaded promise on FontFace objects and .ready() >> promise on FontFaceSets. > > Yes, I'm actively working with Anne, Domenic, and others to help > figure out the right patterns for this that we can extend to the rest > of the platform. Great! / Jonas
Re: Last Call for "CSS Font Loading Module Level 3"
On Tue, May 27, 2014 at 11:44 AM, Jonas Sicking wrote: > On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr. wrote: >>> Separately, FontFace.loaded seems to fulfill the same purpose as >>> FontFaceSet.ready(). I.e. both indicate that the object is done >>> loading/parsing/applying its data. It seems more consistent if they >>> had the same name, and if both were either an attribute or both were a >>> function. >> >> No, the two do completely different (but related) things. Why do you >> think they're identical? One fulfills when a *particular* FontFace >> object finishes loading, the other repeatedly fulfills whenever the >> set of loading fonts goes from non-zero to zero. > > Semantically they both indicate "the async processing that this object > was doing is done". Yes, in one instance it just signals that a given > FontFace instance is ready to be used, in the other that the full > FontFaceSet is ready. Putting the properties on different objects is > enough to indicate that, the difference in name doesn't seem > important? The loaded/ready distinction exists elsewhere, too. Using .loaded for FontFaceSet is incorrect, since in many cases not all of the fonts in the set will be loaded. > In general it would be nice if we started establishing a pattern of a > .ready() method (or property) on various objects to indicate that they > are ready to be used. Rather than authors knowing that they need to > listen to "load" events on images, "success" events on > IDBOpenRequests, .loaded promise on FontFace objects and .ready() > promise on FontFaceSets. Yes, I'm actively working with Anne, Domenic, and others to help figure out the right patterns for this that we can extend to the rest of the platform. ~TJ
Re: Last Call for "CSS Font Loading Module Level 3"
On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr. wrote: >> Separately, FontFace.loaded seems to fulfill the same purpose as >> FontFaceSet.ready(). I.e. both indicate that the object is done >> loading/parsing/applying its data. It seems more consistent if they >> had the same name, and if both were either an attribute or both were a >> function. > > No, the two do completely different (but related) things. Why do you > think they're identical? One fulfills when a *particular* FontFace > object finishes loading, the other repeatedly fulfills whenever the > set of loading fonts goes from non-zero to zero. Semantically they both indicate "the async processing that this object was doing is done". Yes, in one instance it just signals that a given FontFace instance is ready to be used, in the other that the full FontFaceSet is ready. Putting the properties on different objects is enough to indicate that, the difference in name doesn't seem important? In general it would be nice if we started establishing a pattern of a .ready() method (or property) on various objects to indicate that they are ready to be used. Rather than authors knowing that they need to listen to "load" events on images, "success" events on IDBOpenRequests, .loaded promise on FontFace objects and .ready() promise on FontFaceSets. / Jonas
Re: Last Call for "CSS Font Loading Module Level 3"
On Tue, May 27, 2014 at 1:22 AM, Jonas Sicking wrote: > I've provided this input through a few channels already, but I don't > think the user of [SetClass] here is good (and in fact I've been > arguing that SetClass should be removed from WebIDL). Yes, there's an issue in the spec already saying that I need to move off of [SetClass] and do Set-fakery instead, until JS stops being a jerk and allows actual subclassing. I wanted to get the LC publication in before I had the time to make the change, but my intent is pretty clear. ^_^ > First off you likely don't want to key the list of fonts on the > FontFace object instance like the spec currently does. What it looks > like you want here is a simple enumerable list of FontFace objects > which are currently available to the document. > > Second, subclassing the ES6 Set class should mean that the following > two calls are equivalent: > > Set.prototype.add.call(myFontFaceSet, someFontFace); > myFontFaceSet.add(someFontFace); > > However I don't think the former would cause the rendering of the > document to change in, whereas the latter would. > > Hence I would strongly recommend coming up with a different solution > than using SetClass. Yes, all of these issues are related to the fact that Set and Map are currently broken in ES, and cannot be subclassed in any meaningful way. > Separately, FontFace.loaded seems to fulfill the same purpose as > FontFaceSet.ready(). I.e. both indicate that the object is done > loading/parsing/applying its data. It seems more consistent if they > had the same name, and if both were either an attribute or both were a > function. No, the two do completely different (but related) things. Why do you think they're identical? One fulfills when a *particular* FontFace object finishes loading, the other repeatedly fulfills whenever the set of loading fonts goes from non-zero to zero. ~TJ
RE: Last Call for "CSS Font Loading Module Level 3"
I strongly agree on the SetClass matter. A conventional set of method names is fine, but that should not necessitate a misleading subclass relationship. From: Jonas Sicking<mailto:jo...@sicking.cc> Sent: 2014-05-27 04:22 To: Daniel Glazman<mailto:daniel.glaz...@disruptive-innovations.com>; Domenic Denicola<mailto:dome...@domenicdenicola.com> Cc: cha...@w3.org<mailto:cha...@w3.org>; public-webapps<mailto:public-webapps@w3.org>; public-webfonts...@w3.org<mailto:public-webfonts...@w3.org> Subject: Re: Last Call for "CSS Font Loading Module Level 3" I've provided this input through a few channels already, but I don't think the user of [SetClass] here is good (and in fact I've been arguing that SetClass should be removed from WebIDL). First off you likely don't want to key the list of fonts on the FontFace object instance like the spec currently does. What it looks like you want here is a simple enumerable list of FontFace objects which are currently available to the document. Second, subclassing the ES6 Set class should mean that the following two calls are equivalent: Set.prototype.add.call(myFontFaceSet, someFontFace); myFontFaceSet.add(someFontFace); However I don't think the former would cause the rendering of the document to change in, whereas the latter would. Hence I would strongly recommend coming up with a different solution than using SetClass. Separately, FontFace.loaded seems to fulfill the same purpose as FontFaceSet.ready(). I.e. both indicate that the object is done loading/parsing/applying its data. It seems more consistent if they had the same name, and if both were either an attribute or both were a function. / Jonas
Re: Last Call for "CSS Font Loading Module Level 3"
I've provided this input through a few channels already, but I don't think the user of [SetClass] here is good (and in fact I've been arguing that SetClass should be removed from WebIDL). First off you likely don't want to key the list of fonts on the FontFace object instance like the spec currently does. What it looks like you want here is a simple enumerable list of FontFace objects which are currently available to the document. Second, subclassing the ES6 Set class should mean that the following two calls are equivalent: Set.prototype.add.call(myFontFaceSet, someFontFace); myFontFaceSet.add(someFontFace); However I don't think the former would cause the rendering of the document to change in, whereas the latter would. Hence I would strongly recommend coming up with a different solution than using SetClass. Separately, FontFace.loaded seems to fulfill the same purpose as FontFaceSet.ready(). I.e. both indicate that the object is done loading/parsing/applying its data. It seems more consistent if they had the same name, and if both were either an attribute or both were a function. / Jonas
Last Call for "CSS Font Loading Module Level 3"
Dear fellow chairs, The CSS WG decided to issue a last call for: Title: CSS Font Loading Module Level 3 URL: http://www.w3.org/TR/css-font-loading-3/ Editors' draft: http://dev.w3.org/csswg/css-font-loading/ Abstract: This CSS module describes events and interfaces used for dynamically loading font resources. CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. The document was published on the 22nd of may during our ftf meeting in Korea, with a deadline for comments of 30 june. Sorry I could not send the announcement before, I was traveling. The changes from last WD are listed at: http://www.w3.org/TR/2014/WD-css-font-loading-3-20140220/#changes We'd like to especially ask the following groups for a review: - WebApps - WebFonts If you plan to send in a review, but need more time, let us know.
