5 ms·

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

by Kovah 6y ago

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 (onload="..."), the media property is set to "all" and does not stay at "print". When this happens, the browser now knows it should load it as soon as possible and does so. As you mentioned: if JS is disabled, the file will never load. The author states that his solution is not 100% perfect: "[Async webfonts] should always be considered an enhancement anyway, so we need to be able to cope without them; we can and should design decent fallbacks for use during their absence, and;"

chrismorgan 6y ago
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 idle priority, but they’re still fetching them) even though they’re used less than once per million page loads. This seems silly.
- vntok 6y ago
  This reminds me of the SEO industry, where people apply cheap tricks for years telling themselves they can outsmart Google, then suddenly there's a core update and all those sites get heavily penalized. This will probably backfire on frontend devs the same way. A browser prefetching files that aren't needed in 99.999% cases (probably higher, who prints a random webpage in 2020?) sure seems like a bug, so that will probably get fixed someday, and people who applied this trick will wonder why their websites are all breaking down at once. In general, do things that sound intuitive and coherent to you rather than things that are unintuitive and go against the platforms you are developing on. If someone advises you to go against the value proposition of Google Search (find interesting content) or against the value proposition of Google Chrome ("browse the web in a simple, secure, and faster way"), you might want to take a big step back and rethink this.
- csswizardry 6y ago
  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.
  - chrismorgan 6y ago
    “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 <img loading=lazy> doesn’t load once the image is needed, but a short time before it’s probably needed. Hmm, thinking about <img loading=lazy>, 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.
    - csswizardry 6y ago
      You can detect print very, very easily. I helped the NHS track print-users using this: https://csswizardry.com/2018/03/measuring-the-hard-to-measure/#print-stylesheets https://csswizardry.com/2018/03/measuring-the-hard-to-measur... Note that we can’t use `background-image: url();` here as browsers will not print background styles by default, so we’d likely miss the majority of cases.
      - chrismorgan 6y ago
        Good point, I completely forgot about that vector. Then there’s no privacy leak, and I go back to not being able to see why they do it the way they do! :)
    - 6y ago
csswizardry 6y ago
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.

by Kovah 6y ago

chrismorgan 6y ago

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 idle priority, but they’re still fetching them) even though they’re used less than once per million page loads. This seems silly.

vntok 6y ago
This reminds me of the SEO industry, where people apply cheap tricks for years telling themselves they can outsmart Google, then suddenly there's a core update and all those sites get heavily penalized. This will probably backfire on frontend devs the same way. A browser prefetching files that aren't needed in 99.999% cases (probably higher, who prints a random webpage in 2020?) sure seems like a bug, so that will probably get fixed someday, and people who applied this trick will wonder why their websites are all breaking down at once. In general, do things that sound intuitive and coherent to you rather than things that are unintuitive and go against the platforms you are developing on. If someone advises you to go against the value proposition of Google Search (find interesting content) or against the value proposition of Google Chrome ("browse the web in a simple, secure, and faster way"), you might want to take a big step back and rethink this.
csswizardry 6y ago
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.
- chrismorgan 6y ago
  “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 <img loading=lazy> doesn’t load once the image is needed, but a short time before it’s probably needed. Hmm, thinking about <img loading=lazy>, 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.
  - csswizardry 6y ago
    You can detect print very, very easily. I helped the NHS track print-users using this: https://csswizardry.com/2018/03/measuring-the-hard-to-measure/#print-stylesheets https://csswizardry.com/2018/03/measuring-the-hard-to-measur... Note that we can’t use `background-image: url();` here as browsers will not print background styles by default, so we’d likely miss the majority of cases.
    - chrismorgan 6y ago
      Good point, I completely forgot about that vector. Then there’s no privacy leak, and I go back to not being able to see why they do it the way they do! :)
  - 6y ago

csswizardry 6y ago

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.