- From: Tommy Hodgins <tomhodgins@gmail.com>
- Date: Tue, 6 Sep 2016 14:21:25 -0400
- To: Mat Marquis <mat@matmarquis.com>
- Cc: Marcos Caceres <marcos@marcosc.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, public-respimg@w3.org
- Message-Id: <6992B718-B54D-4232-B87C-9FE874D4CA4F@gmail.com>
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> wrote: > > >> On Sep 5, 2016, at 10:08 PM, Marcos Caceres <marcos@marcosc.com> wrote: >> >> cc'ing Tab for comment... >> >> On September 6, 2016 at 6:44:44 AM, Tommy Hodgins (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. >> >
Received on Tuesday, 6 September 2016 18:21:58 UTC