Update Spec with Content about container-queries HOT 10 OPEN

As the Chair of the Responsive Issues Community Group, let me here and now—for the record—formally state the following:

I need to take a little bit to read though this, but if you’re down to make your progress so far the baseline for something a little more formal, couple things:

We’ll have to norm around some “container queries” language—it was a sticking point. We’ll also have to figure out something in the way of… viewport-ish container behavior, since the dropping rules in the case of recursion was seeming like a no-go.

There’s tinkering to do yet, but this is incredible work so far. Let’s make this a Thing.

@SaraSoueidan has expressed an interest in making this happen, and I see you there thumbs-uppin’ stuff, @jonathantneal. Prolly time to set up a Slack instance, huh?

from container-queries.

You have my axe.

from container-queries.

😆 This is wonderful!

If you're interested in reading articles about style scoping, element queries, and container queries the way we're doing it with EQCSS I can point you to these:

• Writing Element Queries Today Using EQCSS

• The Search For The Holy Grail: How I Ended Up With Element Queries, And How You Can Use Them Today

• How Style Scoping Works with Element Queries

• What the Heck are Element Queries & Container Queries?

And if you're wanting to chat about element query related stuff please join us in the EQCSS room on Gitter: https://gitter.im/eqcss/eqcss Everybody is welcome :D

from container-queries.

Hello again! It's been almost a month since the last activity here so I was just wondering if there is any kind of update.

In the meantime, Ethan Marcotte has written a blog post titled On Container Queries where he's calling the RICG into action. Will the RICG hear and respond?

Is anyone working on standardizing container queries? Well, I’m not sure—but I don’t think there’s much movement. The Responsive Issues Community Group (RICG), the community-led working group that brought us the responsive images specification, identified container queries as their next priority. In fact, Mat Marquis, chair of the RICG, wrote an excellent article covering container queries: their background, their status, and how the community can get involved.

In the meantime the spec I've been working on has surpassed 100 stars too, so people are finding and liking it.

Is there any update here? I'm still working on this, producing content every day, building new demos, writing new articles, recording new videos, etc.

Is there any update from the RICG?

from container-queries.

Why don’t we call a meeting? What would think of this agenda?

1. Identifying a CSSWG representative for container queries.
2. A brief review of the arguments for and any known challenges of container queries with the rep.
3. A brief, 2 to 4 week "Round One" suggestion box period for container query syntax/algorithm suggestions. I dunno if this is a tweet storm or what, but at the end we’ll curate some suggestions and bring them to the CSSWG and let them respond to them before moving on to Round Two.

Thoughts?

from container-queries.

That makes good sense to me, @jonathantneal.

One caveat is that I don’t want to focus too hard on syntax just yet. It’s a real alluring rabbit hole to go down, especially as devs, and it’s way down the list of potential issues between this whole idea and real implementation.

The first step—the one that took us a couple years to get to on respimg, and the start of any real traction there—is going to be refining the Use Cases and Requirements doc per ongoing work on the spec draft, and vice versa. Not “how do we write this, as developers” but really nailing down, in advance of discussing the gritty details, where we know we’ll have room to compromise on the big issues, and where we know we can’t. The less focused we are on the most common use cases, the more this thing stands to expand—and the more it expands, the less “possible” it starts to become in the eyes of vendors.

from container-queries.

When you say 'use cases and requirements' what kind of format of things are you looking for?

I don't just have theoretical use cases, I have actual cases of use I can share! What can I contribute to help shine a light on the problems?

There are a number of potential problems with element and container queries we have encountered already and worked around, but this isn't written up anywhere. Is the 'Use cases and requirements' document you're talking about a place where I could list things like: 'If you try to do this, you would run into this problem. By doing this instead you can work around it'?

How can I contribute to this the research we've done so far?

from container-queries.

Those specifics are going to become more and more valuable as things evolve, but documented requirements are very high level. For example, one of the requirements for responsive images was:

The solution must afford developers with the ability to include content that is accessible to assistive technologies.
— http://usecases.responsiveimages.org/#requirements

from container-queries.

In the weirdest jinx ever, I just opened an issue proposing a Requirements section for the use cases doc.

from container-queries.

I actually included @tomhodgins work in the RWD course I just finished recording; it was a really interesting experiment. I worry a little bit about things like @SaraSoueidan 's use case altering font-size in general getting design systems too fragmented based on their own selves rather than as part of a cohesive whole, but I do admit that it likely stems from my stodgy typographer self rather than the specifics of that particular use case (so I apologize Sara for singling you out; it's just that was the thread that led me here).

But all in all I do think that the notion raised of an 'immediate parent viewport' sort of notion is really interesting. (and if combined with Tim Brown's CSS Locks idea could give more unified constraints for things like type scaling). At its simplest we're really looking for a way to react to the proportional size of the element we're in as a percentage of the whole though right?

Basically I kinda think that if we could have a way of knowing the physical dimensions of the object as it's currently rendered, that would answer almost all the needs. Since type sizes are set based on a real-world physically rendered 'good', we could do a lot building from there, couldn't we?

from container-queries.