It's not clear how a style sheet's CSS rules are obtained #2997
Comments
|
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 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.) |
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 |
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 |
|
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.
* 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.
|
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 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.
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: