Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Fastest Google Fonts

csswizardry.com

Post reply on HN
Print view View original

121–130 of 152 posts

Re: The Fastest Google Fonts

#121

Post by csswizardry »

chrismorgan wrote: post #113
Kovah wrote: post #108

Earlier quoted context omitted.

It is explained in the article how it works: "This will implicitly tell the browser to load the CSS file in a non-blocking fashion, applying the styles only to the print context. However, the moment the file arrives, we tell the browser to apply it to all contexts, thus styling the rest of the page." The browser ignores the file because it's just for print and can be loaded later on. But when the page is fully loaded…

You missed my point, or I didn’t explain it well enough. I’m saying: why is the browser even starting to load the stylesheet? It should see media=print and decide that it doesn’t need it at all , and only fetch and load it when the media query starts to match, or perhaps by heuristics when there’s a reasonable chance that it will soon match. As it stands, browsers are fetching print stylesheets all the time (sure, at…

OP here: Simply because the only mechanism a browser needs is ‘a currently-matching media type’ or ‘not a currently-matching media type’. There is no need to add further checks for a specific media type; that would lead to added and potentially infinite complexity as new media types are added.

Re: The Fastest Google Fonts

#122

Post by csswizardry »

chrismorgan wrote: post #104

I don’t understand why the async stylesheet thing works: The media query doesn’t match. Why does the browser even load the stylesheet? Shouldn’t it only load it if it starts to match? Especially for things like print stylesheets, where the media query will only become true by deliberate user action (unlike viewport size media queries where actions like rotating a device could cause them to start matching). Print styl…

> The whole thing is a dubious technique anyway because it depends on JavaScript—if JavaScript is disabled…

I address this twice in the article, which presumably you didn’t read.

> P.S. Why the trailing slash on the tag? It’s completely useless…

Are you just looking for things to be unhappy about?

Re: The Fastest Google Fonts

#124

Post by csswizardry »

Kovah wrote: post #108
chrismorgan wrote: post #104

I don’t understand why the async stylesheet thing works: The media query doesn’t match. Why does the browser even load the stylesheet? Shouldn’t it only load it if it starts to match? Especially for things like print stylesheets, where the media query will only become true by deliberate user action (unlike viewport size media queries where actions like rotating a device could cause them to start matching). Print styl…

It is explained in the article how it works: "This will implicitly tell the browser to load the CSS file in a non-blocking fashion, applying the styles only to the print context. However, the moment the file arrives, we tell the browser to apply it to all contexts, thus styling the rest of the page." The browser ignores the file because it's just for print and can be loaded later on. But when the page is fully loaded…

OP here: Important point is that it’s the file’s onload event and not the window’s onload event that we’re listening for.

Re: The Fastest Google Fonts

#125

Post by csswizardry »

ezequiel-garzon wrote: post #50

Would it bloat Chrome significantly if Google included their web fonts in the browser? And, you know... the other browsers can actually download them? I know it doesn't seem like fair play, but... I'm surprised they haven't done it yet.

Fonts have versions, too; adding them all to the browser would be nigh on impossible.

Re: The Fastest Google Fonts

#126

Post by abjKT26nO8 »

inetknght wrote: post #100
MintelIE wrote: post #89

Does anybody else block fonts? Not only is it wasteful for my mobile data plan, but I just have this suspicion that sooner than later they will be used as a vector for some kind of security issue.

> I just have this suspicion that sooner than later they will be used as a vector for some kind of security issue. You mean like being rendered into a canvas to get a high-entropy fingerprint of your device?

TrueType implementations need to include an interpreter for a Turing-complete language (the hinting language). More about vulnerabilities:

1. https://security.stackexchange.com/questions/91347/how-can-a...

2. https://threatpost.com/of-truetype-font-vulnerabilities-and-...

3. https://googleprojectzero.blogspot.com/2015/07/one-font-vuln...

Re: The Fastest Google Fonts

#127

Post by chrismorgan »

csswizardry wrote: post #122
chrismorgan wrote: post #104

I don’t understand why the async stylesheet thing works: The media query doesn’t match. Why does the browser even load the stylesheet? Shouldn’t it only load it if it starts to match? Especially for things like print stylesheets, where the media query will only become true by deliberate user action (unlike viewport size media queries where actions like rotating a device could cause them to start matching). Print styl…

> The whole thing is a dubious technique anyway because it depends on JavaScript—if JavaScript is disabled… I address this twice in the article, which presumably you didn’t read. > P.S. Why the trailing slash on the tag? It’s completely useless… Are you just looking for things to be unhappy about?

As I said, in this case it’s deliberate and acceptable, but techniques like this have a pernicious way of being used in other more important places where they’re emphatically bad.

Concerning the trailing slash: it’s something I’ve long been puzzled about because it seems to me to be not merely pointless but slightly counterproductive. Here you’ve evidently deliberately inserted it, and I can’t for the life of me understand why people are doing this, so I’m asking.

Re: The Fastest Google Fonts

#128

Post by Angostura »

slashdev wrote: post #3

Just use the built-in fonts. Use a good fallback list so each platform gets a good option. Specifying custom fonts is largely a waste of bandwidth for a very marginal improvement in aesthetic. The people who care most are the ones making the decision to use that font. The solution, tritely, is they should stop caring about the little details that much. The bigger details are usually what move the needle. Don't get st…

Strongly disagree. You may not consciously notice font choice, but it will certainly effect the way you read the page, how you interpret the the heirarchy of information and tone.

Re: The Fastest Google Fonts

#129

Post by philliphaydon »

MintelIE wrote: post #89

Does anybody else block fonts? Not only is it wasteful for my mobile data plan, but I just have this suspicion that sooner than later they will be used as a vector for some kind of security issue.

I had a plug-in to do it but just discovered Firefox has a setting to disable custom fonts.

Re: The Fastest Google Fonts

#130

Post by chrismorgan »

csswizardry wrote: post #121
chrismorgan wrote: post #113

Earlier quoted context omitted.

You missed my point, or I didn’t explain it well enough. I’m saying: why is the browser even starting to load the stylesheet? It should see media=print and decide that it doesn’t need it at all , and only fetch and load it when the media query starts to match, or perhaps by heuristics when there’s a reasonable chance that it will soon match. As it stands, browsers are fetching print stylesheets all the time (sure, at…

OP here: Simply because the only mechanism a browser needs is ‘a currently-matching media type’ or ‘not a currently-matching media type’. There is no need to add further checks for a specific media type; that would lead to added and potentially infinite complexity as new media types are added.

“Does the media query match” is certainly the simplest way to defer loading, but I think some leeway could be useful; the user agent may have ways of predicting when there’s a reasonable probability that the media query will match soon. Kinda like how doesn’t load once the image is needed, but a short time before it’s probably needed.

Hmm, thinking about , I’ve thought of a reason they might not load such stylesheets lazily: privacy leak, you’re notifying the server that the document may have been printed. Lazy image loading has been careful to address this situation so that it’s no new surface (e.g. browsers shouldn’t lazy load if JS is disabled, but if it’s enabled you’re not leaking anything new). But printing specifically? I guess there hasn’t been any way of detecting that the document has been printed, so doing lazy loading on stylesheets for different media types would reveal something new.

Post reply on HN