What kind of support exists for <style>? With

<style>body { background:lime</style>
<style disabled>body { background:red</style>

I get red in each browser.

Yes, the content attribute doesn't exist for <style>. The WebIDL attribute does though, and it forwards to the underlying .sheet (so style.disabled = true; is effectively if (style.sheet) style.sheet.disabled = true; and so on.

I note from the linked intent to implement and ship thread that this is more of an FYI:

@slightlyoff:

If there's a larger project to do here regarding the disabled attribute behaving consistently across elements, that's something they can weigh in on and, if they support, can help drive.

So, for the purposes of the implementing and shipping, no need to block on us; we will discuss whether there is more work to explore here and comment here if we have any thoughts.

How does the integration with CSSOM's disabled attribute work?

(Working notes)

There was mention in the original bug(s) about HTMLStyleElement and SVGStyleElement, but the PR on HTML only seems to address HTMLLinkElement. We should follow up what happened with the other two.

So one thing I'm trying to understand is how dynamic changes of disabled are processed. It seems like the change to the "linked resource fetch setup steps" means that the stylesheet isn't even loaded -- and then I think the change to "The appropriate times to fetch and process this type of link" means that changing disabled would mean that it causes the style sheet`s CSSOM representation to be dropped? Is that correct? (And is it desirable?)

If it's not correct... then what causes setting the disabled attribute to disable the stylesheet?

So one thing I'm trying to understand is how dynamic changes of disabled are processed. It seems like the change to the "linked resource fetch setup steps" means that the stylesheet isn't even loaded -- and then I think the change to "The appropriate times to fetch and process this type of link" means that changing disabled would mean that it causes the style sheet`s CSSOM representation to be dropped? Is that correct? (And is it desirable?)

Yes, that's correct and intentional. <link rel=stylesheet disabled> has link.sheet == null;. It indeed doesn't even load the stylesheet if the attribute is present in the first place.

This matches WebKit / Blink's behavior when coming from the parser (they had a quirk where if you remove and add the attribute again after loaded, it'd behave differently in somewhat odd ways). See https://github.com/whatwg/html/issues/3840#issuecomment-481034206 for context.

When disabled is removed, then stuff is processed normally, except for the "explicitly enabled" bit, which also makes alternates to work.

How does the integration with CSSOM's disabled attribute work?

They're completely independent. HTMLLinkElement.disabled just reflects the disabled attribute on the link. This is, I'd note, different from HTMLStyleElement.disabled and SVGStyleElement.disabled, which just forward to their inner stylesheet.

Firefox used to make HTMLLinkElement.disabled (the WebIDL attribute) behave just like HTMLStyleElement.disabled and SVGStyleElement.disabled, but we had to change it for compat reasons because people were using the link attribute, and here we are now.

Note that I intentionally proposed to make them two completely separate mechanisms, because figuring out a sane interaction between the CSSOM disabled flag and the link element felt really weird (setting link.sheet.disabled = true should ideally then also reflect on the link's attribute?). That also didn't match any engine.

So I went with a compromise described in the comment above.

(Working notes)

There was mention in the original bug(s) about HTMLStyleElement and SVGStyleElement, but the PR on HTML only seems to address HTMLLinkElement. We should follow up what happened with the other two.

HTMLStyleElement and SVGStyleElement have a disabled WebIDL attribute, but not a disabled html attribute... This is all more messy than it should, I know.

Ideally either:

• The <link disabled> attribute wouldn't do anything special and all the WebIDL attributes would do the same thing in all the relevant elements. This is what Gecko used to implement, but had to implement the attribute for compat.

• Maybe we also implement <style disabled>, behaving the same as <link>? That may be nice, though on the other hand the "explicitly enabled" stuff is a bit hackish, so not a fan of making it apply to all LinkStyles... Still may be a better end state.

• Maybe we also implement <style disabled>, behaving the same as <link>? That may be nice, though on the other hand the "explicitly enabled" stuff is a bit hackish, so not a fan of making it apply to all LinkStyles... Still may be a better end state.

That seems somewhat problematic given the existence of disabled on HTMLStyleElement, since it would be weird to add a disabled attribute to <style> without having it reflected to JS as disabled. So it seems like the solution of having disabled on <link> be a totally different thing from what it is on <style> is probably less horrible than the compatible alternatives.

Also, to comment on the original question: it sounds like it would have been nice to have more consistent behavior across elements, but based on @emilio's comments and the need that we found the need to implement inconsistent behavior in Gecko for compatibility, it sounds like that's not an option, and it feels like this PR has resolved some real interop problems.

Closing this, the TAG is happy to see this moving forward.