Removed the parts where the document is stating that EQ should be written against parent elements.

[wnr]

See #11 (especially the lower parts). I generated the HTML file with the latest bikeshed version, which changed the HTML quite a lot. If this is undesired then I can simply add my edits manually.

I don't know about the editors policy. Should I add myself as an editor or not for these small changes?

[tomhodgins]

Looks good to me. This wording makes sense as long as there's a possibility these styles will apply to the same elements that are being queried, or descendants that aren't the direct children of the element(s) being queried. The way it was worded originally it did kind of sound like it only affected the direct children of an element being queried, which is much more limited than what we're talking about.

[tomhodgins]

Also just to note: after @wnr made this pull request in Feb 2015, he went on to study element queries academically, and has released plugins as well, including ELQ

A lot has happened since this PR was originally made, thanks for sharing your study and work with everybody, we're going to use it to make web design better! <3

[ZeeCoder]

I'm actually not entirely on board with these changes.
It eliminates the idea of container elements affecting child element's styles, which is the whole "container" idea.

I don't think this should be merged until we decide what features we want to support exactly.
personally, I would like to support both, as in:

1. style an element based on its own size, and
2. style an element based on a parent's size

Also: I'm still not sure if we should support applying global style changes based on local element conditions.

[tomhodgins]

I'm don't think it's eliminating the container idea, or implying that 'global' styling is possible. The way the original working sounds it makes it sound like, given this HTML:

<div>
  <p>I'm a paragraph with a <span>span</span> inside</p>
</div>

• a query written on the div tag could only affect the div p, and not the div or the div p span

This reword now loosens that to make it possible for a query on the div tag to affect the div tag itself, or for a query on the div tag to affect the div p span. I think those are things we want to include.

I don't see anywhere, for example, that indicates that a query on the div could affect the body styling, or that something like div ~ * would be possible (which comes after the queried element in the document, but is not a child of it at all).

Who knows—we may want to add stuff like that at some point later, but isn't this reword a good starting point for editing? Going from “direct children of queried elements” to something more like a defined 'module' in HTML and being able to apply styles to its children? To me it sounds like it shifts the text closer to the container-style way of thinking about element queries :D

[ZeeCoder]

I've reacted more to your first comment than the changes actually, I'll read through it tomorrow. When you summarised what it was about it sounded like the change wood allow for global styling for example.

…

On 24 Jan 2018 22:22, "Tommy Hodgins" ***@***.***> wrote: I'm don't think it's eliminating the container idea, or implying that 'global' styling is possible. The way the original working sounds it makes it sound like, given this HTML: <div> <p>I'm a paragraph with a <span>span</span> inside</p> </div> - a query written on the div tag could only affect the div p, and not the div or the div p span This reword now loosens that to make it possible for a query on the div tag to affect the div tag itself, or for a query on the div tag to affect the div p span. I think those are things we want to include. I don't see anywhere, for example, that indicates that a query on the div could affect the body styling, or that something like div ~ * would be possible (which comes after the queried element in the document, but is not a child of it at all). Who knows—we may want to add stuff like that at some point later, but isn't this reword a good starting point for editing? Going from “direct children of queried elements” to something more like a defined 'module' in HTML and being able to apply styles to its children? To me it sounds like it shifts the text *closer to* the container-style way of thinking about element queries :D — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADglEgqcdzeK7Ee_OAu_g8V8bwC9IKA9ks5tN600gaJpZM4Ddbas> .

[marcoscaceres]

@tomhodgins, @ZeeCoder, what's the status here? I see a tick form @tomhodgins - but we've not merged yet. What do we need to unblock?

[tomhodgins]

:O I just saw my own tick, I think that's my first tick on anything in Github!

[marcoscaceres]

You tick it, you own it @tomhodgins 😂 But seriously, let's decide what needs to happen here.

[tomhodgins]

I guess we need to hear from @ZeeCoder if he has any objections or changes, or if this is okay.

Have you had a chance to review the diff @ZeeCoder? It's about 4 words, plus one sentence that's changed in this edit.

[ZeeCoder]

I would phrase this as:

...an individual module will respond to changes to its own, or a parent module's size, rather than the viewport's size...

My problem with simply saying an individual module will respond to the given module size implies that such a solution would only be able to change an element's style based on it's own size.

That's the "element query" idea, afaik, where in contrast an element in the "container query" sense would be able to adjust it's own style based on a parent containing element's size.

@tomhodgins @marcoscaceres I think that's an important distinction.

Also not sure why we're talking about modules here instead of elements? 🤔

[hereinthehive]

You've flagged an important distinction.

I think an individual element will respond to the given parent element dimensions perhaps reads better?

[ZeeCoder]

Yeah, but I also don't want to rule out elements changing their styles based on their own size.

[eeeps]

takes chair hat off

I really liked it when @beep said over in the Slack:

In other words, rather than talking about containers vs. elements, it might be more helpful to describe what we need in a more general, less DOM-/CSS-focused sense

Thus I like the simpler, more general, less DOM/CSS focused word: “module.” For me, it captures the ambiguity of where we’re at right now. We don’t know what the technical limits of what we can/should be able to query are, yet. We won’t until after this Use Cases and Requirements doc is complete and we start to hash out a technical solution with spec/browser folks. To me, it seems like this PR goes some way towards addressing Marcos’ concerns in #22.

puts chair hat back on

There was some agreement in the Slack that overall momentum was more important than this PR, and that we should leave it open with some kind of label to revisit. I wholeheartedly agree, and went ahead and added the v1 milestone and an On-Hold label to it. Let's leave, go answer some of Yoav’s questions elsewhere in the doc, and come back later when we maybe have a richer shared vocab around the general problems we’re trying to solve.

[ZeeCoder]

@eeeps Yeah, I'm fine calling it a module then or maybe a component.
The latter I feel like is more wide-spread since the rise of "component-oriented" libs like React, Vue and the like.
We should probably note the justification somewhere though, so that we have a link to point to when someone asks why we're not just calling the queried entities "elements".