Henri Sivonen wrote:
> > Fonts are loaded when used so font loading won't start until the
> > contents using a particular font are laid out.
>
> That seems like a problem for JS-driven display. A big problem in
> the canvas case and at least an annoyance when a JS program drives
> the input to C
Jonathan Kew wrote:
On 11/12/12 10:51, Neil wrote:
Neil wrote:
Jonathan Kew wrote:
You shouldn't normally see a flash of fallback text unless the font
is particularly slow to load; the text should be invisible until
the font is available. We aim to hide the text until the font is
ready,
On 12/11/12 7:18 AM, Henri Sivonen wrote:
On Wed, Dec 5, 2012 at 5:37 AM, John Daggett
wrote:
Fonts are loaded when used so font loading won't start until the
contents using a particular font are laid out.
That seems like a problem for JS-driven display.
It's also the only way to avoid load
On 11/12/12 12:18, Henri Sivonen wrote:
On Wed, Dec 5, 2012 at 5:37 AM, John Daggett
wrote:
Fonts are loaded when used so font loading won't start until the
contents using a particular font are laid out.
That seems like a problem for JS-driven display. A big problem in the
canvas case and at
On Wed, Dec 5, 2012 at 5:37 AM, John Daggett
wrote:
> Fonts are loaded when used so font loading won't start until the
> contents using a particular font are laid out.
That seems like a problem for JS-driven display. A big problem in the
canvas case and at least an annoyance when a JS program dri
On 11/12/12 10:51, Neil wrote:
Neil wrote:
Jonathan Kew wrote:
You shouldn't normally see a flash of fallback text unless the font
is particularly slow to load; the text should be invisible until the
font is available. We aim to hide the text until the font is ready,
unless it takes more than
Neil wrote:
Jonathan Kew wrote:
You shouldn't normally see a flash of fallback text unless the font
is particularly slow to load; the text should be invisible until the
font is available. We aim to hide the text until the font is ready,
unless it takes more than a few seconds to load. (The t
Jonathan Kew wrote:
You shouldn't normally see a flash of fallback text unless the font is
particularly slow to load; the text should be invisible until the font
is available. We aim to hide the text until the font is ready, unless
it takes more than a few seconds to load. (The timeout is conf
Neil writes:
> Ah, so that explains the fallback flash I experience on a site I
> frequent that makes heavy use of a downloaded symbol font. It is
> irksome because the fallback content is ASCII text ;-)
Just in case others read and want to copy this behaviour, sites
should not be encoding symbo
On 5/12/12 10:54, Neil wrote:
John Daggett wrote:
Last time I looked, Webkit caches activated fonts, so the second time
the UA loads the same font (e.g. in a different document) it will be
shown immediately without fallback content first.
Ah, so that explains the fallback flash I experience o
John Daggett wrote:
Last time I looked, Webkit caches activated fonts, so the second time the UA
loads the same font (e.g. in a different document) it will be shown immediately
without fallback content first.
Ah, so that explains the fallback flash I experience on a site I
frequent that make
Fonts are loaded when used so font loading won't start until the
contents using a particular font are laid out. With an async cycle,
this means the first layout pass will use fallback fonts and the
second layout pass will use the loaded font resources.
Using generic loop:
Reflow ==> layout te
On 12/4/2012 2:42 AM, Henri Sivonen wrote:
Can we, please
1) Make the data: URL event pump always spin the event loop before
OnStopRequest to prevent anyone from relying on synchronicity
and
2) Stop promoting data: URL synchronicity as green / “success”
Agree with the synchronous in the tes
On Tue, Dec 4, 2012 at 12:22 PM, Jonathan Kew wrote:
> By way of background, the fact that web-fonts with data: URLs are loaded
> synchronously was a feature deliberately added in bug 512566.
I’m surprised that data: URLs were special-cased in Gecko
deliberately. Was this behavior discussed at th
On 4/12/12 08:42, Henri Sivonen wrote:
I saw a link to http://mozilla.github.com/pdf.js/features/ on Twitter.
This test suite considers it green / “success” for data: URL
@font-faces to load synchronously.
The test “passes” in Firefox and IE10 and “fails” in Chrome and Opera.
I didn’t test Safar
I saw a link to http://mozilla.github.com/pdf.js/features/ on Twitter.
This test suite considers it green / “success” for data: URL
@font-faces to load synchronously.
The test “passes” in Firefox and IE10 and “fails” in Chrome and Opera.
I didn’t test Safari.
To me, it seems like a bad idea to 1)
16 matches
Mail list logo
