Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't relocate scoped style tags in prioritize_critical_css #967

Closed
GoogleCodeExporter opened this issue Apr 6, 2015 · 3 comments
Closed

Don't relocate scoped style tags in prioritize_critical_css #967

GoogleCodeExporter opened this issue Apr 6, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link

@GoogleCodeExporter GoogleCodeExporter commented Apr 6, 2015

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

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Apr 6, 2015

Note: only Firefox seems to support <style scoped>, so something simple and 
conservative may be the practical solution.
http://caniuse.com/style-scoped

Looks like an attempt to implement it in Blink didn't go well:
http://www.chromestatus.com/features/5374137958662144

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]."
http://dev.w3.org/csswg/css-scoping/#scope

... so just leaving any scoped styles in place without changing anything should 
work.


Original comment by morlov...@google.com on 11 Aug 2014 at 2:44

Loading

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Apr 6, 2015

Ah, that's reassuring.  Fixing things should be quite a bit easier in that 
case, barring JS adding / removing "scoped" from a style tag (which is just a 
weird and broken thing to do).

Original comment by jmaes...@google.com on 18 Aug 2014 at 2:13

Loading

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Apr 6, 2015

Fixed in r4171 (and docs reverted to their original state).

Original comment by jmaes...@google.com on 20 Aug 2014 at 3:16

  • Changed state: Fixed

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant