This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The html spec has a "media" attribute on <link>[1] to support media queries. This may be useful when used with html imports (e.g., using different widgets on smaller screens). The interaction between html imports and media queries feels underspecified: what happens if a user rotates their screen and a different html import matches after the page has loaded? [1] http://www.w3.org/html/wg/drafts/html/master/single-page.html#attr-link-media
Applying media queries for imports seems about as silly as applying them to scripts.
(In reply to Philip Rogers from comment #0) > The html spec has a "media" attribute on <link>[1] to support media queries. > This may be useful when used with html imports (e.g., using different > widgets on smaller screens). The interaction between html imports and media > queries feels underspecified: what happens if a user rotates their screen > and a different html import matches after the page has loaded? > > [1] > http://www.w3.org/html/wg/drafts/html/master/single-page.html#attr-link-media Since the imports run script, they do not have the same apply-unapply semantics as stylesheets.
(In reply to Anne from comment #1) > Applying media queries for imports seems about as silly as applying them to > scripts. I can imagine using imports for templates where you want different templates for different screen sizes or media types. Regardless of whether you buy my strange usecase, specifying what happens when you use the media attribute seems useful.
It is specified, no? It has no effect.
(In reply to Anne from comment #4) > It is specified, no? It has no effect. I apologize if I am being dense, but I think this is specified as having an effect. The html5 spec states "However, if the link is an external resource link, then the media attribute is prescriptive. The user agent must apply the external resource when the media attribute's value matches the environment and the other relevant conditions apply, and must not apply it otherwise." (http://www.w3.org/html/wg/drafts/html/master/single-page.html#attr-link-media) The imports spec doesn't mention "media".
My apologies, you're correct. That needs patching somehow. It's also unclear to me why HTML imports does not use the "obtain the resource" algorithm from HTML to get to the bits. It seems that could be reused.
(In reply to Anne from comment #6) > My apologies, you're correct. That needs patching somehow. > > It's also unclear to me why HTML imports does not use the "obtain the > resource" algorithm from HTML to get to the bits. It seems that could be > reused. Unfortunately the "obtaining..." algorithm cannot be used for imports as is because: - It does have to handle de-dup. - Its CORS behavior is different. For imports, "cross-origin request" should be always performed. In other words, it needs different @crossorigin default, that is Anonymous, instead of null. Any CORS-unaware HTML shouldn't be loaded through import system. I clarified it needs different fetch algorithm [1]. It wasn't that obvious before. [1] https://github.com/w3c/webcomponents/commit/85ad4cb477af8176be47a9c59b302e2a94734703
Explicitly ignores @media. https://github.com/w3c/webcomponents/commit/fdeacaa94bdf89d2564dd62ca0906248654169f4 I agree that it can be useful if it works as expected, but as Dimitri and Anne mentioned, we cannot "unapply" script execution. That means one of the important aspect of @media query, dynamic application based on the environement change, doesn't work. This is confusing. Theoretically we can evaluate it statically (only once), but I'd just skip it now. We can reconsider this later if we see strong demand.