RE: Update on Element Queries

I’m assuming he has, but has Tab updated the thread on why this is NOT simple to implement in the browser? While I agree the concept is simple, the implementation of it is not.

Additionally, I suggest taking a look at the resizeObserver as I think this is a cleaner approach to solving the same problem. https://wicg.github.io/ResizeObserver/

Greg

Sent from my Windows 10 phone

From: Tommy Hodgins<mailto:tomhodgins@gmail.com>
Sent: Tuesday, September 6, 2016 11:23 AM
To: Mat Marquis<mailto:mat@matmarquis.com>
Cc: Marcos Caceres<mailto:marcos@marcosc.com>; Tab Atkins Jr.<mailto:jackalmage@gmail.com>; public-respimg@w3.org<mailto:public-respimg@w3.org>
Subject: Re: Update on Element Queries

TLDR: In the future Houdini will allow us to write better plugins/polyfills, but that’s different than proposing a spec to be included in CSS. A lot of people are hesitant to look at element queries until it’s at least a proposed spec, and would likely also reject Houdini-based support for the same reason. Let’s spec it out!

The same day the first draft of the RICG article about use cases for element queries went online, we had the first alpha of what is now the EQCSS plugin. We were already working out the syntax we would need, and what we have come up with has proven very useful. I was so excited to see the RICG article and know that we weren’t alone identifying the need and use cases for element queries, and I was hopeful that development on this concept was going to happen quickly after that.

Element queries seem like something intuitively missing from CSS — it’s such a simple concept. I thought then that we might be 4–5 years away from having a spec approved, plus wide enough browser support be able to use element queries in regular CSS…but today it feels like we’re in the exact same position we were at the end of 2014.

Here’s how I envision the roadmap for element queries, from concept to browser support:

Step 1 ? Define a syntax

Step 2 ? Prototype an implementation of the syntax

Step 3 ? Build demos to test syntax, features, browsers, & edge cases

Step 4 ? Refine syntax according to discovery

Step 5 ? Distill research (updated syntax, demos) into a spec

Step 6 ? Use the implementation prototype(s) as a roadmap for the work to be done for implementation in browsers

I've been working hard on Steps 1–4 and I want to know how to take all the research we’ve done over the past 2 years and distill that into a spec that can be  proposed for CSS.

Currently for Step 2 we have used JavaScript to build a plugin that interprets our syntax live on the page. In the future Houdini may provide a more direct way to do this. In the meantime I’m also experimenting with the idea of reading our syntax and outputting all of the custom JavaScript and CSS you would need to manage styles on those elements according to their own responsive conditions. People have suggested PostCSS might be useful for this.

Either way, no matter how many different technologies there may be to build different implementations for Step 2, I am ready to move forward with Step 5. We can continue repeating Steps 2–4 over and over by building as many different plugins as we want as we work on Step 5 and the only side effect will be that we will have a clearer picture of the kind of syntax that works, and have a better understanding of what browsers would need to do to support that syntax in Step 6.

In many ways element queries are a natural extension of @media queries so a lot of the language, structure, and content of the spec ought to be very similar. Where do we go from that starting point?


On Sep 6, 2016, at 12:03 PM, Mat Marquis <mat@matmarquis.com<mailto:mat@matmarquis.com>> wrote:


On Sep 5, 2016, at 10:08 PM, Marcos Caceres <marcos@marcosc.com<mailto:marcos@marcosc.com>> wrote:

cc'ing Tab for comment...

On September 6, 2016 at 6:44:44 AM, Tommy Hodgins (tomhodgins@gmail.com<mailto:tomhodgins@gmail.com>) wrote:
The RICG has positioned itself as the unofficial authority
on this issue to people are looking to it for answers, but as somebody
working with element queries every day I have to ask, “Where is
the RICG?” From all appearances it seems dead in the water.

Not at all... but I think a lot of us have been waiting to see what
magic the Houdini effort produces. IIUC (which I might not, because
I've not been following), it's supposed to enable user-land solution
to things like element queries.

I’m ready to get moving on this! Is anybody with me?

We are all with you :) But I'll defer to Tab on how the group should proceed.

It might be that creating an informal specification for
implementation, in the spirit of the Promises A+ spec, might be a
great start.

Yeah, I emailed back and forth with Dean Jackson over at Team WebKit, and he agreed that a spec was the place to start regardless of the form the solution takes. Even if container queries end up being something developers build from Houdini and the like, there should be a spec for authors to follow—the way Picturefill tried to follow the spec, y’know?


Having said that, it could be good to make necessary changes to:
https://github.com/ResponsiveImagesCG/container-queries

And maybe see if the stuff coming out of Houdini will be able to
actually give us element queries.