When we get there: Evaluate EQ's per Element.

[jehoshua02]

I want to be sure that EQs evaluate per element. I can have two elements, matching the same selector, but not necessarily the EQ at the same time.

I do this in Reusables Breakpoints.

[tabatkins]

I'm not sure what you mean. Can you give an example?

[jehoshua02]

Maybe this is too technical of a concern for right now? But here's an example.

I have a list of "deals". The first deal is the "hero" deal. It takes up the width of the container. But the rest of the deals flow into columns. I have several EQs on the deals to adjust their content layout however is most appropriate for the width of the deal. Let's call these "small", "medium", and "large".

The EQs should be evaluated independently on each deal. The hero deal, because it has a different width, would match the large EQ. While the column deals match either small or medium EQ, depending on their width. But at a smaller screen, hero deal could match medium EQ, while the others would match small EQ. And on an even smaller screen, they all could match the small EQ.

And also, I think the styles within an EQ should be scoped to the target's children and itself, rather than applying to all elements that match the selector(s).

[tabatkins]

Still not sure what you mean. I think you have a different idea of how this stuff works than I do. Can you provide a markup example? (Just make up some example syntax where necessary.)

[alanmoo]

@jehoshua02, I think the use case in the doc covers exactly the behavior you're describing. The EQ would be checked against each element it applies to, not uniformly applied to all elements on the page based on the sizing of one specific element. (Unless of course that specific element is the one with the EQ on it, which is where we're going to get into implementation EQ-ception trouble...maybe no nested EQ's?...but I digress, that's a conversation for a different repo).

[jehoshua02]

@alanmoo Yes. Evaluating EQ against each element seems like an obvious one. I wanted to bring it up because I want EQs to turn out right.

@tabatkins For example, let's say I have something like this:

<div class="deal deal--hero">...</div>

<div class="columns">
  <div class="deal">...</div>
  <div class="deal">...</div>
  <div class="deal">...</div>
</div>

And an EQs something like this:

@element .deal ($small) {
  ...
}

@element .deal ($medium) {
  ...
}

@element .deal ($large) {
  ...  
}

The .deal--hero might match $large while the .columns .deal elements match $small. The element queries are evaluated per element. Again, seems like an obvious thing, but I feel being explicit is better than implicit.

I have a hard time refraining from pondering implementation. Is there another repo somewhere that has begun to discuss implementation?

[tabatkins]

@jehoshua02 Ah, I understand now. Well, I don't understand why you thought it could possibly be any other way, but I at least get what you're asking about now.

Yes, elements in different contexts, responding to different EQ containers, will evaluate differently.

This is partly why I don't think the example syntax you're using is very good here. Better to integrate it into Selectors proper, and make a pseudo-class that matches on EQ containers if they match the contained EQ. Like:

.container:eq(width > 500px) .deal { ... }

It's far more obvious how things are evaluated here, what element the EQ is evaluated against, etc.

[jehoshua02]

@tabatkins Ah, that's brilliant. I definitely like the pseudo-class selector.

I'm new to standards development. Where can I learn more about the process? Is anyone talking about implementation, syntax, polyfill?

[tabatkins]

That's what you're doing right here. ^_^

[alanmoo]

@tabatkins But as per other issues, this is more of a use case repo. Or are we keeping the actual code use cases, but discussions can be other things?

(Also, yes, pseudo-class syntax makes a lot of sense)

[pdaoust]

I also think the pseudo-class syntax makes the best sense. A couple thoughts:

• When applied to :root, element queries provide the exact same functionality as dimension-based media queries, and can be used in their place by anyone who wants to (not an important point, I suppose, but an interesting one).
• @tabatkins I love the idea of using comparison operators. All of a sudden I can make a query for everything below (but not equal to) a number, which I can't in media queries. I mean, I guess @media (max-width: 29.9375em) is okay, but what I'd really like to do is @media (width < 30em). (There's also the issue of what happens in the gap between 29.9375em and 30em when a user is zoomed in and there are more than one pixel of difference between those two numbers.)

[andykirk]

Hi, just chiming in here. There's a reason media queries don't use < and >. From MDN

Media features Most media features can be prefixed with "min-" or "max-" to express "minimum condition" or "maximum condition" constraints. For example, "max-width:12450px" means the highest condition for applying the styles is, the media have a screen with 12450px width. If the screen is wider than 12450px, the style will not be applied. This avoids using the "<" and ">" symbols, which would conflict with HTML and XML. If you use a media feature without specifying a value, the expression resolves to true if the feature's value is non-zero.

HTH. Personally I'd like to be able to use them, but it's got to work in HTML.

Cheers

[eeeps]

@andykirk have you seen https://www.w3.org/TR/mediaqueries-4/#mq-range-context ?

Parsers are already smart enough to deal with angle brackets in different contexts, e.g. https://codepen.io/eeeps/pen/EXWRJY

[tabatkins]

There's a reason media queries don't use < and >.

That was an extremely old restriction, and stopped being relevant a very long time ago in HTML. In XML it just means you either have to escape the angle brackets or use CDATA. As @eeeps says, MQ4 already allows the angle brackets (tho implementations have been a little slow to support them).

[andykirk]

Ah, right. Thanks for the update. I couldn't see any date-relevant or updated info on MDN, I just knew I'd seen something about that topic somewhere and I thought it was pertinent. Apologies. Just trying to be helpful. :-)