-
Notifications
You must be signed in to change notification settings - Fork 10
A rough proposal for syntax #2
Comments
@tabatkins had a decent syntax proposal when we last met up in Redmond. Tab? |
Maybe I shouldn't say something, because I don't know anything. But maybe you get inspired: @container ((.element) with ( min-width: 60em )) {
.child-el {
background: papayawhip;
}
} |
I'm new to the issue but shouldn't we stick closer to the already existing syntax?
|
I would like to see a |
NodeList.prototype.forEach = Array.prototype.forEach;
document.querySelectorAll('.container').forEach(function (container) {
container.addEventListener('@media screen and (max-width: 600px)', function (event) {
console.log(event.oldWidth); // ?
console.log(event.width); // ?
// do something ajax related to fetch more/less data depending on whats needed by the component
});
}); |
Worth taking advantage of element's having the ability to nest? With implied
Alternatively that could be inlined to:
Alternatively it could be similar to matches:
However I suspect the containing element needs to be declared very explicitly to be a container to give the "iframe like behaviour" I have heard others talk about. Such that I think this would be bad:
If all containing elements that matched that criteria, I can see that one being expensive. As for JavaScript, some extension of MatchMedia should be sufficient: The spec outlines a way to add listeners whihc should match what @serapath is after: |
@jonathanKingston i took a look, but I do not have a feeling that this solves the issue for javascript
var setInterval(function testAllTheTime () {
if (window.matchMedia('@media screen and (max-width: 600px)').matches) {
/* the viewport is at most 600 pixels wide, while it was "bigger" before */
} else {
/* the viewport is more than 600 pixels wide, while it was smaller before*/
}
}, 100); // test every 100 ms - most of the time its wasted, because the query doesnt match so instead what i'd like to see: document.querySelector('#containerFooBar').addEventListener('@media screen and (max-width: 600px)', function (event) {
if (event.matches) {
/* the viewport is at most 600 pixels wide, while it was "bigger" before */
} else {
/* the viewport is more than 600 pixels wide, while it was smaller before*/
}
}); // better performance, because the browser fires an event once a media query matches - so i dont need to check all the time |
@serapath matchMedia('(max-width: 600px)').addListener(function(){
console.log(this.matches);
}); However container queries are element specific and can't described with a global Maybe something like this: document.querySelector('#containerFooBar').matchContainer('(max-width: 600px)').addListener(function(){
console.log(this.matches);
}); |
@aFarkas exactly that syntax is what I was thinking thanks. |
I'd prefer arguments being passed into the callback instead of having |
I was thinking about what @WebDevTmas said and, while I was initially resistant to the idea, it's slowly growing on me. On the one hand, adding container query syntax to That said, overloading
|
You forget something here. What you want is that the browser should delay selecting a resource until the size of the container is known (so you can use container queries to describe your sizes). But as soon as the browser is doing this, you don't need to use
|
@aFarkas oh, good point; that totally didn't occur to me. So I wonder how this should be resolved... it'd sure be nice to have the browser select the correct image size based on its actual, post-layout size. That sounds like a big tangled mess to me, going against the reason we needed Thoughts? I sorta feel like I should break this off into a separate issue. |
This has nothing to do with container queries. It would be an additon to responsive images. (Introduce a new attribute: |
@aFarkas yeah, I realised that it's not really specific to container queries after thinking through the issue; hence my previous comment re: wishing we didn't need sizes and wanting something like Looks like someone's already thinking along those same lines: https://github.com/ResponsiveImagesCG/ri-defer-usecases |
Re: a JS API, this is coming - browsers have been talking about resize events on all elements, which would give you this ability. |
wow awesome :-) resize events for elements? On 6 July 2015 at 19:34, Tab Atkins Jr. [email protected] wrote:
|
What about using a pseudo class on the child element itself? Like so: .child-el:container( min-width: 60em ) {
background: papayawhip;
} It wouldn’t be possible to omit the child element then. Another benefit would be, that the browser can determine what element should be used as the container. The browser can traverse the DOM tree up and select the first qualified element as the container. A qualified element has to match certain characteristics, e.g. it must have a width which doesn’t depend on the size of its child elements. If the browser finds no qualified parent element it can use the viewport size. So this behavior would also solve the recursion issue. |
That's a really interesting perspective, and I wonder whether the browser makers would be amenable to that sort of idea. It avoids the need to create a concept of 'viewport-like elements', because the browser already knows what sorts of things are explicitly sized. It might also present a simple model for determining which axis/axes should be considered fixed and hence queryable: "does any parent of this child have an explicit height? if yes, and it matches the query, then apply the styles." It does require the user to be explicit about container size, but I don't see that as a bad thing. My one concern is that it might be hard to reason about what container is being queried, but then, that's just what we've come to expect from CSS, isn't it? "What is this element floating inside? What's the stacking context? What's the positioning context? Why is this button inheriting a green border?! AAAAA!" @tabatkins As a guy who works pretty closely with people who write browsers, can you see any compelling reasons to consider or reject this as a solution? |
Whether you base it on a particular container or the "nearest" container doesn't matter a ton; both are workable approaches. The former is more powerful than the latter, but slightly harder to work with as a result, so it's a trade-off. |
Okay, just checking, cuz I'm pretty ignorant of all this stuff :-) I do like the idea of container queries just not working if the container (whether explicit/particular or implicit/nearest) doesn't have well-defined sizing of some sort (either block-level and normal flow, or floated/absolute and explicitly sized, or flex-with-already-resolved-layout). I feel like it might make layout calculation simple because the parent's size has already been defined and can only be re-layouted as a result of being influenced by elements outside the container. |
I think it wouldn’t be that hard in real world examples. It would work similar to IMO a great advantage of this approach is, that as a CSS author I cannot write “wrong” container queries with it, because I’m unable to select an invalid container. And selectors like |
May Tim Berners-Lee have mercy on our souls, because it is time to kick off The Great Bikesheddening.
I’m a big fan of the syntax @jonathantneal proposed way back when, but I have two issues with my own preference:
First, it doesn’t make sense strictly in terms of container queries. This syntax is fine for styling child elements if we always assume something like this:
But there’s nothing stopping someone from writing:
At which point, would we just throw those styles away? That seems strange.
The second issue is the repurposing of
media
, which doesn’t seem to make semantic sense in this context. It feels a little telephone-gamed frommedia="handheld"
—which checks out—to@media( min-width: 30em )
—which kinda makes sense—to.el:media( min-width: 30em )
, which makes no sense whatsoever.The text was updated successfully, but these errors were encountered: