Page MenuHomePhabricator

Support for @container (CSS Container Query) in templateStyles
Open, Needs TriagePublicFeature

Description

Feature summary (what you would like to be able to do and where):
Please add support for @container queries.

Compatibility is good thanks to interop efforts:
https://developer.mozilla.org/en-US/docs/Web/CSS/@container#browser_compatibility

Spec:
https://w3c.github.io/csswg-drafts/css-contain-3/#container-rule

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
This is Msz2001's new navbox prototype:
https://pl.wikipedia.org/w/index.php?title=Wikipedysta:Msz2001/Navbox.css&action=submit

Would be great to use (now widely supported) @container. Something like would provide a better experience (as currently no navbox is displayed on mobile):

.navbox2 {display:none}

/* desktop navbox */
@media (min-width:720px){
	.navbox2 {display:block}
	// ...
}
/* mobile/thin navbox */
@container (max-width: 700px) {
	.navbox2 {display:block}
	// ...
}

This would work if main css would contain something like (can be added to MW:common.css, linter warns but doesn't block):

.mw-body {
  container-type: inline-size;
}

Benefits (why should this be implemented?):
The @container is better for responsive template layouts. All readers would benefit, not only those using mobile devices.

Event Timeline

I was planning to file this task when there was a greater percentage of views supporting them and when they were no longer at working draft.

Your motivation isn't right. You can already use @media queries to support differing resolutions (@media (min-width: 720px) {}) already. What @container provides support for is being able to ignore the width of the sidebars (or non-bars, as in Minerva) that most skins have when considering the design of our templates. That should be the real motivation.

Besides that, I'd also request that when this gets implemented that .mw-parser-output be added as a CSS container, possibly directly in TemplateStyles. Most content that we will want to judge against a container will want to compare to .mw-parser-output, and I believe we will not be able to do that without it being supported in the extension.

Maybe I wasn't clear. Firstly I know what those queries are for 😉. I want the templates to change based on the width they can actually occupy. E.g. in less obvious things like dynamic preview (which you could then use to preview template on small screen):

obraz.png (639×642 px, 48 KB)

I agree that adding proper, common containers in extensions/skins would be nice, but not required. You can do that already in site-wide CSS (eg).

I agree that adding proper, common containers in extensions/skins would be nice, but not required. You can do that already in site-wide CSS (eg).

If everyone wants it, we should avoid having it in Common.css, and I think everyone will want it, otherwise we'll be back to third party users saying "why doesn't my navbox look like mobile" in support forums. :)