You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
It's not clear how a style sheet's CSS rules are obtained #2997
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.
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).
@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>.
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>).
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.
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.)
<iframesrc='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>
'>
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?
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. :(
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.
Activity
annevk commentedon Sep 3, 2017
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 commentedon Sep 3, 2017
@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 commentedon Sep 3, 2017
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 commentedon Sep 3, 2017
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/linkelement.) @bzbarsky has said things to this effect, iirc, in reference to conditional stylesheet loading (<link media>).annevk commentedon Sep 4, 2017
See also #696.
Improve <style> and <script> processing and conformance
Improve <style> and <script> processing and conformance
Improve <style> and <script> processing and conformance
SimonSapin commentedon Feb 10, 2018
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:
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
Improve <style> and <script> processing and conformance
cdoublev commentedon Jan 6, 2022
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 commentedon Jan 6, 2022
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 commentedon Jan 7, 2022
@whatwg/css ^^
tabatkins commentedon Jan 7, 2022
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 commentedon Jan 8, 2022
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.