This basically means replacing the part of the spec that says "Otherwise, the LinkStyle interface's sheet attribute must return a StyleSheet object with the following properties".

Anne: How do I set the URL, title, media, etc, of the style sheet?

http://dev.w3.org/csswg/cssom/#create-a-style-sheet

Anyone know who is editing this spec now? I should make sure they're not planning on changing this.

This bug was cloned to create bug 17999 as part of operation convergence.

(punting since CSSOM editorship recently changed and they are probably still getting up to speed)

Glenn, Shane: Can you help me out here? What do I need to do? See in particular my questions in comment 1.

(Also, is there somewhere to report bugs on CSSOM? The spec seems to have had some mistakes introduced, e.g. some of the method definitions are no longer normative, lacking "must" invokations, etc.)

(In reply to comment #6)
> Glenn, Shane: Can you help me out here? What do I need to do? See in
> particular my questions in comment 1.
> 
> (Also, is there somewhere to report bugs on CSSOM? The spec seems to have
> had some mistakes introduced, e.g. some of the method definitions are no
> longer normative, lacking "must" invokations, etc.)

I gather you are asking that the prose description of the algorithm specify appropriate parameters that you can pass arguments from the prose in HTML that invokes these algorithms, yes?

There is a CSSOM component under the CSS product in BZ [1].

[1] https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=CSSOM&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=Importance&list_id=948

(note to self: see also bug 19924)

This will also need to handle CORS-cross-origin style sheets somehow.

And be more explicit about only having sheets be in .styleSheets while they're in the document.

Ian asked me to update this with what Gecko does for cross-origin sheet loads.

We return the stylesheet from .sheet for such loads.  The URI of the sheet is the URI that was listed in the page originally (so the pre-redirect URI, hence not able to leak any information the page did not have).  The page can also read/set the sheet's media.  Attempts to get .cssRules on the sheet throw a security exception.

*** Bug 17165 has been marked as a duplicate of this bug. ***

From bz in bug 17165:

In particular, at what points are the stylesheets actually loaded/parsed respectively?  What happens if the DOM inside <style> is mutated?  What happens if the CSSOM is mutated and then attributes that affect the styling behavior (e.g. title, rel, media) are changed?

Also, how changes to rel and media interact with .disabled.

zcorpan, this may be relevant to your new interests

(In reply to comment #14)
> zcorpan, this may be relevant to your new interests

Also, note the parsing algorithms now present in the Syntax spec.  Feel free to invoke them; this is what I wrote them for.

(In reply to comment #9)
> This will also need to handle CORS-cross-origin style sheets somehow.

This is possible now. Set or unset the origin-clean flag when creating the CSS style sheet.

(In reply to comment #11)
> Ian asked me to update this with what Gecko does for cross-origin sheet
> loads.
> 
> We return the stylesheet from .sheet for such loads.  The URI of the sheet
> is the URI that was listed in the page originally (so the pre-redirect URI,
> hence not able to leak any information the page did not have).

I made .href return pre-redirect URL for same-origin as well. Should that be changed? (If so please file a new bug on CSSOM.)

> The page can
> also read/set the sheet's media.  Attempts to get .cssRules on the sheet
> throw a security exception.

Specced.

(In reply to comment #13)
> From bz in bug 17165:
> 
> In particular, at what points are the stylesheets actually loaded/parsed
> respectively?

This isn't well specified yet.

> What happens if the DOM inside <style> is mutated?

HTML should say to create a new CSS style sheet when that happens.

> What
> happens if the CSSOM is mutated and then attributes that affect the styling
> behavior (e.g. title, rel, media) are changed?

For title and media, the stylesheet gets updated in place. HTML needs to invoke create a CSS style sheet with media and title being the relevant attributes (rather than the value of the attributes). See https://dvcs.w3.org/hg/csswg/diff/0b21977c2ed3/cssom/Overview.src.html

> Also, how changes to rel and media interact with .disabled.

When rel is changed, HTML should say to create a new CSS style sheet. Per spec currently, .disabled doesn't change based on the alternate flag or media. It's possible that the spec is wrong on that point, though.

HTML should have an algorithm for <style> and an algorithm for <link> that are similar to http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction

They should run when an element is inserted or removed from the document, when type is set/changed/removed, for <style> when textContent is changed, for <link> when rel/href/crossorigin is set/changed/removed.

The "fetch a CSS style sheet" algoritm takes care of the quirk of applying non-text/css resources, so that can be dropped from HTML.

> I made .href return pre-redirect URL for same-origin as well

Yes, correct.

> For title and media, the stylesheet gets updated in place. HTML needs to invoke
> create a CSS style sheet with media and title being the relevant attributes
> (rather than the value of the attributes).

I don't follow this, sorry.  Especially the combination of "updated in place" and "create a CSS style sheet".  The question is whether CSSOM modifications to a sheet are lost when title/media change on the DOM node; I think they are in some UAs but not others.  Of particular interest is what happens here if the sheet is not even done loading or parsing when these attributes change.

> It's possible that the spec is wrong on that point, though.

I suspect it is, since the load-time value of @media does affect .disabled.

(In reply to comment #18)
> I don't follow this, sorry.  Especially the combination of "updated in
> place" and "create a CSS style sheet".

Ah, yeah, I meant *when* it creates a CSS style sheet (e.g. because the <link> was inserted to the document)...

> The question is whether CSSOM
> modifications to a sheet are lost when title/media change on the DOM node; I
> think they are in some UAs but not others.

I propose that the modifications should not be lost.

> Of particular interest is what
> happens here if the sheet is not even done loading or parsing when these
> attributes change.

That's a good point. https://www.w3.org/Bugs/Public/show_bug.cgi?id=22478

> I suspect it is, since the load-time value of @media does affect .disabled.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22479

Thanks!

I just added the concept of "environment encoding" to CSS Syntax, and
defined it there for <link rel=stylesheet> :

http://dev.w3.org/csswg/css-syntax/#environment-encoding
http://dev.w3.org/csswg/css-syntax/#environment-encoding-html

The latter part should be moved to the HTML spec.

Note: I included the charset attribute even though it’s marked obsolete in HTML, as this is what implementations do. I’d be in favor of dropping it if someone want to convince implementers, but in the meantime the spec should reflect reality.

(In reply to Simon Sapin from comment #20)
> Note: I included the charset attribute even though it’s marked obsolete in
> HTML, as this is what implementations do. I’d be in favor of dropping it if
> someone want to convince implementers, but in the meantime the spec should
> reflect reality.

It looks like the charset attribute is used in the wild.

In http://webdevdata.org june data set, I see 322 instances of <link charset> that's different from the document's charset (out of 2359 <link charset>s in total, in ~53,000 pages).

$ find ./ -name "*.html.txt" -print0 | xargs -0 -n1 -P8 grep -HnEio "<link\s([^>]*\s)?charset\s*=[^>]+>" >> ~/Desktop/link-charset.txt
$ cd ~/Desktop
$ python find-interesting-charsets.py > link-charset-different-from-content-type.txt

See http://lists.w3.org/Archives/Public/www-archive/2013Oct/0049.html for the script and the output.

annevk said in #whatwg:
I don't see the point in dropping <link charset> / <?xml-stylesheet charset?> as long as you still inherit from the document
both are in control of a potential attacker
so given that, the compatibility risk does not seem worth it

Does this mean the charset attribute should be "unobsoleted" from the spec? I’m fine with keeping the current author requirements (must not use) but implementation requirements should be specified.

Yup, sounds like it. Can you file a separate bug for adding charset="" support to the spec? Then I'll use this bug to track connecting the HTML spec to the various algorithms in the CSS spec(s).

Is there something I should call when the <link> or <style> no longer applies?

Should I really reload the stylesheet if rel="stylesheet" changes to rel="alternate stylesheet"? Surely we just change the alternate flag on the fly somehow (like passing the "create..." algorithm some sort of lambda that can tell you if it's alternative or not). Especially since we're tracking the title="" in real time too, which can do the same thing, basically.

What do UAs do?

Gecko will in fact reload stylesheets if you mess with some of those attributes, for what it's worth.  But that's just because it's a lot easier than trying to update various complicated state in-place...

(In reply to Ian 'Hixie' Hickson from comment #24)
> Is there something I should call when the <link> or <style> no longer
> applies?

http://dev.w3.org/csswg/cssom/#remove-a-css-style-sheet

http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction step 2 does this.

> Should I really reload the stylesheet if rel="stylesheet" changes to
> rel="alternate stylesheet"?

Yeah, I think so. It's simpler to implement and I'm not aware of use cases for it. Possibly blunt stylesheet switchers that don't use the API for switching stylesheets, but that doesn't seem like something we should optimize for (unless a lot of pages do that, but that seems unlikely).

> Surely we just change the alternate flag on the
> fly somehow (like passing the "create..." algorithm some sort of lambda that
> can tell you if it's alternative or not). Especially since we're tracking
> the title="" in real time too, which can do the same thing, basically.

In Blink, as far as I can tell, rel reloads but title doesn't. Not sure about Gecko.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2737
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2738
(check Network inspector)

The relevant Gecko code is as follows:

1)  If the attribute being changed is not href, rel, title, media, type, do nothing.

2)  If the attribute is being unset, or if it's being set and is one of title/media/type, or if it's being set and its name is "rel" and the new value doesn't include "stylesheet", do a forced update.

3)  Otherwise, do a regular update.

The difference between a "forced" update and a "regular" update is that for a regular update if there is already a stylesheet (which is created when the node is inserted in the DOM, note) and its URI matches the new URI we do nothing.  So basically, changing from rel="stylesheet" to rel="alternate stylesheet" or vice versa is more or less a no-op, as is changing the "href" attribute in ways that don't change the final resolved URI (e.g. from relative to absolute).

In either case, if the update happens (so is forced, or the regular update found a URI difference), we go ahead and remove the old sheet and load a new one.  Whether that ends up hitting the network depends on the object cache in the per-document style loader object, so while you get a new DOM CSSStyleSheet object there might not actually be any network access here.

Checked in as WHATWG revision r8390.
Check-in comment: Update how the interaction with CSS style sheets and CSSOM is defined.
http://html5.org/tools/web-apps-tracker?from=8389&to=8390