prioritize_critical_css doesn't properly treat <style scoped> as a barrier to
moving CSS around the document. Indeed, scoped style blocks combined with
cascade order throw a wrench into the whole model of deferring non-essential
style loading until the end of the document. This requires re-thinking how
this stuff works:
* The base class will need to be able to inject styles above the first style
block in the document.
* Is it possible to use JS to uncomment style blocks earlier in the document
than bottom of document? If so we could patch things up as follows:
- Move original <style> and <link> blocks into a <noscript> at the same point in the document where they occur.
- Place the inline critical style immediately before the corresponding <noscript>
- Have the end of page script iterate over the injected noscript and move the <style> or <link> tags out into the document, between the inline <style> and the <noscript>.
For now the filter documentation is being updated to reflect the fact that
these don't play well together.
Original issue reported on code.google.com by jmaes...@google.com on 7 Aug 2014 at 3:34
The text was updated successfully, but these errors were encountered:
Note: only Firefox seems to support <style scoped>, so something simple and
conservative may be the practical solution.
Looks like an attempt to implement it in Blink didn't go well:
I think the order situation isn't quite as bad as you think, though:
"The cascade prioritizes scoped rules over unscoped ones, regardless of
specificity. See Cascading by Scope in [CSS3CASCADE]."
... so just leaving any scoped styles in place without changing anything should
Original comment by morlov...@google.com on 11 Aug 2014 at 2:44