-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Import condition #7658
base: main
Are you sure you want to change the base?
Import condition #7658
Conversation
@domenic The build is now working, as the remaining mentions of If I understand right, the CSSOM update will require changes in the CSSOM spec as well, so I'm looking into that. Happy for any other feedback you have here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found a few nits, plus one larger question about the scope of this change; those are noted inline.
But indeed, the biggest missing piece is updating CSSOM. I don't really know much about those specs but it looks like the following pieces are relevant and probably will need updates:
- https://drafts.csswg.org/cssom/#concept-css-style-sheet-media does not need changes but will start being given import condition strings instead of media query strings by HTML. That leads to changes to the following sections:
- https://drafts.csswg.org/cssom/#media-queries needs to handle import conditions instead of media queries. (But, we cannot change the names
MediaList
andmediaText
.) - https://drafts.csswg.org/cssom/#serialize-a-css-rule needs to serialize import conditions in import rules (this is independent of this HTML change and seems like just something that was missed by the CSSWG?)
source
Outdated
@@ -13788,8 +13789,7 @@ interface <dfn interface>HTMLLinkElement</dfn> : <span>HTMLElement</span> { | |||
data-x="external resource link">external resource links</span>.</p> | |||
|
|||
<p>The <dfn element-attr for="link"><code data-x="attr-link-media">media</code></dfn> attribute | |||
says which media the resource applies to. The value must be a <span>valid media query | |||
list</span>.</p> | |||
says which media the resource applies to. The value must be a <span>valid import condition</span>.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we update "says which media the resource applies to"? I'm personally not sure. The sentence here is supposed to be a statement of fact so it doesn't need to be super-accurate. But I feel like with the new value space maybe the current sentence becomes inaccurate?
source
Outdated
@@ -14450,7 +14450,7 @@ interface <dfn interface>HTMLMetaElement</dfn> : <span>HTMLElement</span> { | |||
name-value pair is the empty string.</p> | |||
|
|||
<p>The <dfn element-attr for="meta"><code data-x="attr-meta-media">media</code></dfn> attribute | |||
says which media the metadata applies to. The value must be a <span>valid media query list</span>. | |||
says which media the metadata applies to. The value must be a <span>valid import condition</span>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So to double-check, do we have implementer buy-in for changing not only link
and style
, but also meta
and source
? I think it's best if we change them all, for consistency. But it is extra work, and some implementers might not be excited about doing that extra work so that you can do conditional meta theme colors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The layer syntax would only have meaning in the link
& style
elements - and is only needed on the former (the CSS syntax can be used directly inside style
). Other import conditions, such as support queries, may be useful on all three. We could narrow the scope of this PR to only the essential change, and expand later if desired?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do implementers want to do here?
Even for the link
element, media
can be specified and is processed for preload
in addition to stylesheet
. Do we want to check the value of the as
attribute for preloads and decide between media query list or import condition, or always treat as import condition for link
?
For images, videos, and <meta name=theme-color>
, I think it doesn't make much sense to support supports()
since they don't import CSS stylesheets, but I don't feel strongly about it.
We also have the Link
HTTP header which per spec seems to always process the media
header attribute regardless of rel
(https://html.spec.whatwg.org/multipage/semantics.html#process-link-headers step 5). Link
supports preconnect
and preload
rels per spec (not stylesheet
).
For Meanwhile, for I think CSSOM needs to change to allow creating stylesheets with supports conditions, and changing the HTML (Maybe also Edit: filed w3c/csswg-drafts#9361 |
Draft fix for #7540
(See WHATWG Working Mode: Changes for more details.)
💥 Error: Wattsi server error 💥
PR Preview failed to build. (Last tried on Jul 18, 2023, 10:57 PM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.