Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
ideas:font-load-futures [2013/04/08 08:18]
tabatkins
ideas:font-load-futures [2014/12/09 15:48] (current)
Line 1: Line 1:
-====== ​Proposal ​======+====== ​Font Load Event with Futures ​======
  
-  partial interface document { +This is a proposal ​to rework the Font Load Events spec to use Futures instead.
-    readonly attribute FontList fonts; +
-  } +
-   +
-  interface FontList : EventTarget { +
-    /* whatever idl magic you need to make this an array-like filled with Font objects */ +
-    Future ready() +
-    boolean checkFont(DOMString font, optional DOMString text = " "); +
-    Future loadFont(DOMString font, optional DOMString text = " "); +
-    attribute EventHandler onloading;​ +
-    attribute EventHandler onloadingdone;​ +
-  } +
-   +
-  interface Font { +
-    Future ready() +
-    /* readonly versions of all the CSSFontFaceRule attributes, minus ones that point into the stylesheet */ +
-  }+
  
-First of all, I'm replacing document.fontLoader with document.fonts,​ +The proposal ​is now located here: http://www.xanthir.com/b4PV1
-an array-like of Font objects. ​ Each Font object is a readonly version +
-of a CSSFontFaceRule object, without any links into the CSSOM. ​ This +
-seems like a useful convenience API all by itself, but it's also +
-something that can be safely exposed to Workers, as there'​s no +
-DOM/CSSOM link to make it unsafe.  ​The FontList contains Font objects +
-for all the @font-face rules in all the stylesheets for the document, +
-in document order. +
- +
-The FontList.ready() function returns a Future. ​ This is initially +
-unresolved, and resolves when the browser has loaded all stylesheets +
-and has finished loading all the fonts it chooses to initially load. +
-It must return the same future across multiple calls. ​ If, after +
-resolving the future, the browser beings loading more fonts, it must +
-create a new future to return from .ready(), and again resolve it when +
-the browser stops loading fonts. ​ This addresses use-case #1, +
-replacing notifyWhenFontsReady(). +
- +
-The loadFont() function has its argument list reverted to be identical to +
-checkFont, and it just returns a future which is resolved as soon as +
-all the necessary requested fonts have loaded (which may be +
-immediately,​ if all necessary fonts are already loaded). ​ This +
-addresses use-case #2. +
- +
-checkFont() is unchanged. +
- +
-To address use-case #3, the API has two pieces. ​ If you care about the +
-loading status of individual fonts, look for the relevant Font object +
-and call its ready() function to obtain a Future which is resolved +
-when the font is done loading, or cancelled when the font load has an +
-error. ​ This replaces the loadstart/load/error events The +
-loading/loadingDone events are unchanged - they'​re useful for +
-providing UI indicating whether fonts are loading or not, rather than +
-a one-off "tell me when fonts are ready",​ which is what the .ready() +
-future is for.+
 
ideas/font-load-futures.txt · Last modified: 2014/12/09 15:48 (external edit)
Recent changes RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki