WICG / cq-usecases

Use cases and requirements for standardizing element queries.
Other
184 stars 24 forks source link

What about Javascript? #20

Closed jehoshua02 closed 6 years ago

jehoshua02 commented 9 years ago

There may be times I want to execute some javascript when EQ matches or unmatches.

One definite use case for this I've encountered so far is with rendering ads in responsive designs. I don't want to inflate impressions with ads that aren't being displayed. So I want to defer rendering of the ads until they are going to be displayed in a responsive design.

Let's say I want to render ads in a column layout between every two rows. But my layout goes from one column to two column to three column. Meaning the number of items between each ads changes with the columns. If I can hook into the EQs that are responsible for the columns, I can execute javascript that renders the appropriate ads.

Also very common is displaying ads of different dimensions at different screen sizes. If I can hook into EQs that are responsible for changing layout, I can render the ads of appropriate size.

I'm doing this sort of thing with Reusables Breakpoints

marcoscaceres commented 9 years ago

This sounds interesting. You would want some kind of matchMedia() support.

PaulSpr commented 9 years ago

Can't we already bind resize events to elements? Then check element size and perform an action if necessary.

Also, assuming that Element Queries would be build in CSS using some kind of selector syntax, couldn't we use CSS selectors to detect if we need to do something if a certain matching element appears?

jehoshua02 commented 9 years ago

@PaulSpr Yes we can listen to resize on the window and check element size and do stuff. But defining and evaluating breakpoints without a library is messy. That's why I wrote Breakpoints.js.

Using selectors in javascript would be a familiar and consistent interface for element queries in javascript. If I knew what the selectors would look like Breakpoints.js could become a javascript polyfill by parsing the selector and defining breakpoints as usual.

beep commented 6 years ago

Marking this as out of scope for v1, but we may revisit in the future.

eeeps commented 6 years ago

It's probable that Container Queries in CSS are going to be built on hooks and primitives that are going to be exposed in JavaScript, first (e.g., ResizeObserver). The problems described by the OP are solvable, now, (though not in the simplest or DRY-est way) with ResizeObserver, but it would certainly be nice in the future when there's a CSS-y syntax to let you use that syntax in JS, too (like matchMedia).

A MatchMedia-like feature, while out of scope for our current work, seems easy to add later.

The CSS itself somehow emitting events when container breakpoints are hit is super interesting, but to my (small) knowledge, unprecedented? Are there other CSS things that emit JavaScript events?

A question for the future...

ausi commented 6 years ago

Are there other CSS things that emit JavaScript events?

Yes, animations and transitions for example transitionEnd

eeeps commented 6 years ago

@ausi did not know that. Thanks!

(I wonder if anyone's suggested events for media query breakpoints before?)