Update Spec with Content #6

Open
tomhodgins opened this Issue Jan 6, 2017 · 10 comments

Comments

Projects
None yet
5 participants
@tomhodgins
Collaborator

tomhodgins commented Jan 6, 2017

Hi RICG!

I've been working on my own syntax for container-query style element queries - and have begun writing that up as a spec! I'd love to see some action in this repository (it's been a year and a half since the last update) and see if there's anything from my spec we can bring over, or what we can do to breathe some life into this again.

The repository for my container query syntax is here: https://github.com/tomhodgins/element-queries-spec

And the syntax described in that document is already able to be tested with the EQCSS JavaScript plugin. You can already find over a hundred examples of this syntax in use (case studies, and demos) on Codepen here: http://codepen.io/search/pens?q=eqcss&limit=all&type=type-pens

New year, refreshed desire to make Element Queries part of CSS!

@tomhodgins tomhodgins changed the title from Update Spec with content to Update Spec with Content Jan 6, 2017

@Wilto

This comment has been minimized.

Show comment
Hide comment
@Wilto

Wilto Feb 3, 2017

Contributor

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

ho-ly

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?

Contributor

Wilto commented Feb 3, 2017

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

ho-ly

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?

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Feb 3, 2017

You have my axe.

You have my axe.

@tomhodgins

This comment has been minimized.

Show comment
Hide comment
@tomhodgins

tomhodgins Feb 3, 2017

Collaborator

😆 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:

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

Collaborator

tomhodgins commented Feb 3, 2017

😆 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:

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

@tomhodgins

This comment has been minimized.

Show comment
Hide comment
@tomhodgins

tomhodgins Mar 2, 2017

Collaborator

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?

Collaborator

tomhodgins commented Mar 2, 2017

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?

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Mar 2, 2017

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?

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?

@Wilto

This comment has been minimized.

Show comment
Hide comment
@Wilto

Wilto Mar 2, 2017

Contributor

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.

Contributor

Wilto commented Mar 2, 2017

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.

@tomhodgins

This comment has been minimized.

Show comment
Hide comment
@tomhodgins

tomhodgins Mar 2, 2017

Collaborator

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?

Collaborator

tomhodgins commented Mar 2, 2017

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?

@Wilto

This comment has been minimized.

Show comment
Hide comment
@Wilto

Wilto Mar 2, 2017

Contributor

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

Contributor

Wilto commented Mar 2, 2017

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

@beep beep referenced this issue in WICG/cq-usecases Mar 2, 2017

Open

Requirements section #36

@beep

This comment has been minimized.

Show comment
Hide comment
@beep

beep Mar 2, 2017

Collaborator

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

Collaborator

beep commented Mar 2, 2017

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

@jpamental

This comment has been minimized.

Show comment
Hide comment
@jpamental

jpamental Mar 2, 2017

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?

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?

@tomhodgins tomhodgins referenced this issue in tomhodgins/element-queries-spec Mar 3, 2017

Closed

Moving eval into separate proposal level? #3

@beep beep referenced this issue in WICG/cq-usecases Jan 24, 2018

Closed

need primary editor #49

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment