WICG / cq-usecases

Use cases and requirements for standardizing element queries.
Other
184 stars 24 forks source link

Discussion #1: Query Targets & Containment #52

Open tomhodgins opened 6 years ago

tomhodgins commented 6 years ago

This topic is created as a place for us to discuss and determine the scope of the queries and the styles they can apply.

Things that need to be decided:

Hopefully by the time we reach the end of this discussion we'll know:

ZeeCoder commented 6 years ago

I'm not sure what you mean by asking if there's a container concept? A container is an element that can contain other elements. Coming with a React background I might as well call them Components, or in the BEM methodology, I would call them "blocks". The idea is always the same, a reusable unit of elements with a clear boundary.

At least that is my definition, others might think differently, cc/ @ausi @eeeps @marcj

But anyway I think it's less important to discuss what we call it than to clarify what we want it to do (aka: requirements):

☝ I personally think that is enough in itself for Discussion#1.

marcoscaceres commented 6 years ago

@ZeeCoder wrote:

At least that is my definition,

Seek a definition in the CSS spec - there has to be something there :) But your definitions are good for clarifications.

ZeeCoder commented 6 years ago

@marcoscaceres do you think there's already something in the current CSS spec about container query? 🤔 I'm not sure I understand what I need to look for.

marcoscaceres commented 6 years ago

No, just about “container” of some sort. @tantek?

tantek commented 6 years ago

Current Selectors spec (L4) editor's draft: https://drafts.csswg.org/selectors-4/

There is a concept of "container" but it is about the element being selected, rather than any ancestors. e.g.:

The key for any new use of "container" as a term (as in "container query") would be to state it in such a way that does not confuse/conflate that existing but different meaning. If the concept can be broadened in the spec to consistently apply to both kinds of "container" (container that is being selected, container of the thing being selected), yet be clear from context which is meant when, then that would be even better.

Aside: one meta-thought, once we get to drafting an actual CQ spec, it will likely work best to think of it like another chapter in the Selectors spec, but write it up separately until we get some implementation commitments. Then we can decide later whether to ship it separately or land it into the current actively edited Selectors draft, whichever works best at that (future) time.