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.

Sign up for GitHub

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

Jump to bottom

Define more exactly when document.styleSheets is updated #696

Closed
zcorpan opened this issue Feb 15, 2016 · 3 comments
Closed

Define more exactly when document.styleSheets is updated #696

zcorpan opened this issue Feb 15, 2016 · 3 comments
Assignees
@domfarolino
Labels
compat Standard is not web compatible or proprietary feature needs standardizing topic: style

Comments

@zcorpan
Copy link
Member

zcorpan commented Feb 15, 2016

https://html.spec.whatwg.org/multipage/semantics.html#link-type-stylesheet

Once a resource has been obtained

See https://bugzilla.mozilla.org/show_bug.cgi?id=958415#c6 onwards

Also https://www.w3.org/Bugs/Public/show_bug.cgi?id=29464 for the bug on the CSSOM side (I suppose both HTML and CSSOM need to be clearer here).
@zcorpan zcorpan added the compat Standard is not web compatible or proprietary feature needs standardizing label Feb 15, 2016
@zcorpan zcorpan self-assigned this Feb 15, 2016
@annevk annevk mentioned this issue Sep 4, 2017
Open
@annevk annevk mentioned this issue Jan 16, 2018
Closed
@TakayoshiKochi
Copy link
Member

Related: when .sheet property for both <style> and <link rel=stylesheet> becomes available is unclear.

According to #2997 (comment) CSS parsing should be observed atomic, so things will happen in this order

  1. loading completes
  2. stylesheet is parsed
  3. CSSStyleSheet object is ready (including cssRules being populated)
  4. .sheet is associated with the object
  5. document.styleSheets reflects the object
  6. load or error event is fired against its owner node

@domfarolino domfarolino mentioned this issue Nov 25, 2018
Merged
@pshaughn pshaughn mentioned this issue Dec 4, 2019
Open
@emilio
Copy link
Contributor

emilio commented Nov 18, 2020

https://bugzilla.mozilla.org/show_bug.cgi?id=1673885 changed Gecko behavior here.

@zcorpan zcorpan removed their assignment Oct 27, 2021
domenic pushed a commit that referenced this issue Feb 10, 2022
@xiaochengh
Add the render-blocking mechanism and blocking=render attribute
f522f07 
Closes #7131.

The new render-blocking mechanism is used to specify cases where <script> and <link> can be render-blocking in all browsers, but were not according to the spec. This closes #3355 (although note that #696 remains open).
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
@xiaochengh @mfreed7
Add the render-blocking mechanism and blocking=render attribute
e225f7f 
Closes whatwg#7131.

The new render-blocking mechanism is used to specify cases where <script> and <link> can be render-blocking in all browsers, but were not according to the spec. This closes whatwg#3355 (although note that whatwg#696 remains open).
@domfarolino domfarolino self-assigned this Nov 26, 2022
@domfarolino
Copy link
Member

As per #4031 (specifically #4031 (comment)) I think this issue can be closed. Everything in #696 (comment) seems to be properly specified in the way that the comment outlines, with the exception of the CSS parsing particulars, which is tracked by #2997 specifically. But the order of all the other steps, including their relation to the hand-wavy CSS rule parsing, looks right to me.

I'll close this now, but please re-open if you think I am mistaken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@domfarolino domfarolino

Labels
compat Standard is not web compatible or proprietary feature needs standardizing topic: style
Milestone
No milestone
Development

No branches or pull requests
5 participants
@zcorpan @emilio @annevk @TakayoshiKochi @domfarolino