/html

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

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

Open
domenic opened this Issue Sep 3, 2017 · 6 comments

Comments

Assignees

@zcorpan zcorpan

Labels
Milestone
No milestone
5 participants
@domenic @annevk @tabatkins @SimonSapin @zcorpan
@domenic
Member

domenic commented Sep 3, 2017

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

@domenic domenic added the clarification label Sep 3, 2017

@domenic domenic assigned zcorpan Sep 3, 2017

@annevk

This comment has been minimized.

Sign in to view
Member

annevk commented 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

This comment has been minimized.

Sign in to view
Member

domenic commented Sep 3, 2017 •
edited

@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

This comment has been minimized.

Sign in to view
Member

domenic commented Sep 3, 2017 •
edited

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

This comment has been minimized.

Sign in to view
Collaborator

tabatkins commented 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).

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

This comment has been minimized.

Sign in to view
Member

annevk commented Sep 4, 2017

See also #696.

@annevk annevk added the topic: style label Sep 4, 2017

domenic added a commit that referenced this issue Sep 8, 2017

@domenic
Improve <style> and <script> processing and conformance 
* 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.
509e84f

domenic added a commit that referenced this issue Sep 8, 2017

@domenic
Improve <style> and <script> processing and conformance 
* 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.
34d65dd

@domenic domenic referenced this issue Sep 8, 2017

Merged

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

annevk added a commit that referenced this issue Sep 14, 2017

@domenic @annevk
Improve <style> and <script> processing and conformance 
* 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.
9c612ac
@SimonSapin

This comment has been minimized.

Sign in to view
Contributor

SimonSapin commented 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:

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>
'>

This was referenced Jul 5, 2018

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