It's not clear how a style sheet's CSS rules are obtained#2997

domenic · 2017-09-03T03:07:17Z

For both <style> and <link>, the "Create a CSS style sheet" algorithm is called with the CSS rules "left uninitialized". Neither of them seem to pass off the source text to the CSS specification.

<style> defines the concept of "style data", but never seems to indicate how this gets wired up to create CSS rules. <link> doesn't even do that.

Is this taken care of behind the scenes in some way by CSS? If so, we should add a note. If not, we've got a pretty glaring spec hole.

I guess at some point someone should call the algorithms in https://drafts.csswg.org/css-syntax/ ? /cc @tabatkins @SimonSapin

The text was updated successfully, but these errors were encountered:

annevk · 2017-09-03T09:01:00Z

Another thing I'd like to see clarified is whether CSS rules can be added incrementally or whether they need to be there all at once atomically (from the moment you can observe the stylesheet itself).

domenic · 2017-09-03T20:09:31Z

@guest271314 sure, but nothing in the HTML spec says to actually apply that procedure to the source text.

As for links, I'm specifically talking about stylesheet links here, which have the same problem.

(Replying to deleted post.)

domenic · 2017-09-03T20:56:36Z

Off-topic

@guest271314, I'd like to keep this issue focused on the issue identified in the OP. If you have additional suggestions or questions, please ask them elsewhere. Instead you seem to be discussing a lot of other stuff that is only barely related by virtue of having to do with style sheets. Please take comments which are not directly related to the issue discussed in the OP elsewhere. (If you are confused about the issue in the OP, feel free to ask in IRC or by email and I can further explain.)

When I'm back at my computer I'll edit both our posts to hide this off-topic stuff behind a <details>.

tabatkins · 2017-09-03T23:36:13Z

Another thing I'd like to see clarified is whether CSS rules can be added incrementally or whether they need to be there all at once atomically (from the moment you can observe the stylesheet itself).

To the best of my knowledge, webcompat requires stylesheets to appear to be parsed atomically - if you can see the stylesheet, it needs to contain all of its rules fully parsed. (And you need to be able to see the stylesheet if you can see the style/link element.) @bzbarsky has said things to this effect, iirc, in reference to conditional stylesheet loading (<link media>).

annevk · 2017-09-04T11:17:06Z

See also #696.

* De-genericizes <style> and <link rel="stylesheet"> to only deal with CSS. Fixes #2995. * Makes type="" on <style> "obsolete but conforming", since it is always redundant. * Makes type="(a JS MIME type)" on <script> obsolete but conforming as well. Previously we had a "should" requirement but had not recorded it in the centralized obsolete-but-conforming section that collects such requirements. * Makes <style> operate on child text content. Fixes #2996. * Adds pointers to #2997. * Makes it clearer that parameters are not allowed in the content type value for script or style. Fixes #3022.

* De-genericizes <style> and <link rel="stylesheet"> to only deal with CSS. Fixes #2995. * Makes type="" on <style> "obsolete but conforming", since it is always redundant. * Makes type="(a JS MIME type)" on <script> obsolete but conforming as well. Previously we had a "should" requirement but had not recorded it in the centralized obsolete-but-conforming section that collects such requirements. * Makes <style> operate on child text content. Fixes #2996. * Replaces the conformance requirement (noted in the source as "temporary") prohibiting unmatched comment-like syntax inside <style> with a conformance requirement to be valid CSS. * Adds pointers to #2997. * Makes it clearer that parameters are not allowed in the content type value for script or style. Fixes #3022.

SimonSapin · 2018-02-10T23:15:21Z

Yes, I think HTML still needs to define how the input stream (in Unicode code points) or the input byte stream is constructed, for consumption by CSS Syntax.

https://html.spec.whatwg.org/multipage/semantics.html#the-style-element defines:

The child text content of a style element must be that of a conformant style sheet.

This sort of implies that the (Unicode) input stream is the child text content, but it’s not quite a proper definition.

By the way I was surprise that child nodes would be used, rather than descendant nodes. But the test case below shows that this is what’s implemented. (The difference is only testable in XHTML or with DOM manipulation, since the HTML parser treats <style> specially.)

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5787

<iframe src='data:application/xhtml+xml,
  <html xmlns="http://www.w3.org/1999/xhtml">
    <style>
      .p1 { color: green }
      /*<span> This text node is not a direct child of style, and so not part of the stylesheet */
        .p1 { color: red }
      /*</span> The stylesheet resumes here */
      .p2 { color: green }
    </style>
    <p class="p1">One</p>
    <p class="p2">Two</p>
  </html>
'>

* De-genericizes <style> and <link rel="stylesheet"> to only deal with CSS. Fixes whatwg#2995. * Makes type="" on <style> "obsolete but conforming", since it is always redundant. * Makes type="(a JS MIME type)" on <script> obsolete but conforming as well. Previously we had a "should" requirement but had not recorded it in the centralized obsolete-but-conforming section that collects such requirements. * Makes <style> operate on child text content. Fixes whatwg#2996. * Replaces the conformance requirement (noted in the source as "temporary") prohibiting unmatched comment-like syntax inside <style> with a conformance requirement to be valid CSS. * Adds pointers to whatwg#2997. * Makes it clearer that parameters are not allowed in the content type value for script or style. Fixes whatwg#3022.

cdoublev · 2022-01-06T18:58:05Z

Is parse a CSS stylesheet the missing step to get the cssRules? I'm not sure because it uses parse stylesheet, which creates a stylesheet, then processes it to interpret its style rules and discard invalid at-rules. Is it expected to create then "discard" this stylesheet, before creating a new one?

domenic · 2022-01-06T20:22:09Z

Yeah, I don't really know the answer. It's not clear whether the CSSOM spec and CSS Syntax spec were designed to integrate with each other :(.

annevk · 2022-01-07T07:37:55Z

@whatwg/css ^^

tabatkins · 2022-01-07T19:44:08Z

Yeah, I don't really know the answer. It's not clear whether the CSSOM spec and CSS Syntax spec were designed to integrate with each other :(.

They weren't, directly at least. CSSOM came first and has been completely hand-wavey, I wrote Syntax in a hopefully usable fashion, but CSSOM was still too handwavey to really use a precise algo anyway. OM hasn't had an active editor since zcorpan left. :(

cdoublev · 2022-01-08T10:33:18Z

I wrote Syntax in a hopefully usable fashion

I confirm that, thank you Tab. My question above is just the result of the accumulated confusion at the end of my day, because I couldn't fully grasp how to hook things up appropriately, but the next day all makes sense after the expected implementation is found. I will figure out on my own, for sure.

domenic added the clarification Standard could be clearer label Sep 3, 2017

domenic assigned zcorpan Sep 3, 2017

annevk added the topic: style label Sep 4, 2017

domenic mentioned this issue Sep 8, 2017

Improve <style> and <script> processing and conformance #3024

Merged

This was referenced Jul 5, 2018

Define more exactly when document.styleSheets is updated #696

Closed

How does access to .cssRules behave before the sheet is "done loading" WICG/construct-stylesheets#11

Closed

domenic mentioned this issue Jan 7, 2022

Bug with script-blocking <style> elements #7469

Closed

bathos mentioned this issue Jan 23, 2022

Removing a Shadow DOM that contains a style tag edited with the CSSStyleSheet API loses its styles #7520

Closed

zcorpan removed their assignment Feb 3, 2022

cdoublev mentioned this issue Feb 12, 2022

[syntax-3][cssom-1][selectors-3][mediaqueries-4][cascade-3][css-counter-styles-3] Improve the procedures used for parsing a CSS input w3c/csswg-drafts#7040

Open

14 tasks

xiaochengh mentioned this issue May 5, 2022

Set requests' render-blocking flag when fetching resources for render-blocking elements #7885

Merged

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

It's not clear how a style sheet's CSS rules are obtained#2997

It's not clear how a style sheet's CSS rules are obtained #2997

domenic commented Sep 3, 2017

annevk commented Sep 3, 2017

domenic commented Sep 3, 2017 •
edited

domenic commented Sep 3, 2017 •
edited

tabatkins commented Sep 3, 2017

annevk commented Sep 4, 2017

SimonSapin commented Feb 10, 2018

cdoublev commented Jan 6, 2022 •
edited

domenic commented Jan 6, 2022

annevk commented Jan 7, 2022

tabatkins commented Jan 7, 2022

cdoublev commented Jan 8, 2022

It's not clear how a style sheet's CSS rules are obtained#2997

It's not clear how a style sheet's CSS rules are obtained #2997

Comments

domenic commented Sep 3, 2017

annevk commented Sep 3, 2017

domenic commented Sep 3, 2017 • edited

domenic commented Sep 3, 2017 • edited

tabatkins commented Sep 3, 2017

annevk commented Sep 4, 2017

SimonSapin commented Feb 10, 2018

cdoublev commented Jan 6, 2022 • edited

domenic commented Jan 6, 2022

annevk commented Jan 7, 2022

tabatkins commented Jan 7, 2022

cdoublev commented Jan 8, 2022

domenic commented Sep 3, 2017 •
edited

domenic commented Sep 3, 2017 •
edited

cdoublev commented Jan 6, 2022 •
edited