Skip to content
This repository has been archived by the owner on Feb 16, 2023. It is now read-only.

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

Open
wants to merge 1 commit into
base: gh-pages
Choose a base branch
from

Conversation

wnr
Copy link
Contributor

@wnr wnr commented Feb 8, 2015

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?

…s. Instead of stating that element queries should be written against containers, it is now keeping it a bit more open.
Copy link
Collaborator

@tomhodgins tomhodgins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

ZeeCoder commented Jan 24, 2018 via email

@marcoscaceres
Copy link
Contributor

@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
Copy link
Collaborator

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

@marcoscaceres
Copy link
Contributor

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

@tomhodgins
Copy link
Collaborator

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.

@@ -29,11 +29,11 @@ If you wish to make comments regarding this document, please send them to <a hre

<h2 id="intro">Introduction</h2>

Given a complex responsive layout, developers often require granular control over how the contents of an individual module will respond relative to the size of their parent container rather than the viewport size. This limitation conflicts with the goal of creating modular, independent components, often requiring a number of redundant CSS, complex exception cases, and workarounds, and the problem compounds itself depending on how dramatically a module adapts at each of its breakpoints.
Given a complex responsive layout, developers often require granular control over how the contents of an individual module will respond to the given module size rather than the viewport size. This limitation conflicts with the goal of creating modular, independent components, often requiring a number of redundant CSS, complex exception cases, and workarounds, and the problem compounds itself depending on how dramatically a module adapts at each of its breakpoints.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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? 🤔

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You've flagged an important distinction.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@eeeps
Copy link
Collaborator

eeeps commented Feb 9, 2018

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
Copy link
Collaborator

ZeeCoder commented Feb 9, 2018

@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".

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants