search

WICG / cq-usecases

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

need primary editor #49

Closed tantek closed 6 years ago

tantek commented 6 years ago

per @marcoscaceres comment in #44

tomhodgins commented 6 years ago

I'm willing to do this role, or any others I can do to help move this effort forward. I have played around with bikeshed and gotten a little practice at spec writing, and have written a couple unofficial dream specs, including a dream spec for element queries that mirrors the syntax and featureset of the EQCSS plugin.

If we need to create, write, and maintain a new spec I am committed to help :D

marcoscaceres commented 6 years ago

@tomhodgins, that's great to hear.

marcoscaceres commented 6 years ago

@tomhodgins, immediate thing for you to do would be to start triaging the issues in this repo and in the other repo.

Contributors, if you see and issue you like, please please assign yourself to them and start figuring out best way to close them. Coordinate wiht @tomhodgins on any proposed solution.

Otherwise, if you are new, please start by just reading the use cases document and the spec.

@tomhodgins, all, is the plan to replace the current spec with your proposal?

beep commented 6 years ago

@tomhodgins, all, is the plan to replace the current spec with your proposal?

Well, per #6 and #36, we were planning to focus on use cases and requirements before settling on a specific syntax. The EQCSS work might likely make for a good starting point for drafting a container queries spec, but it might be helpful to ensure we’re in agreement on high-level requirements first.

tomhodgins commented 6 years ago

Great! Thanks @marcoscaceres. @ZeeCoder and I were brainstorming a list of potential issue ideas, so we can go ahead and create those issues this week to house discussions for individual topics and people can get started :D

As for bringing in my own spec text to replace the current one—I'm not sure if it would be easier to modify that document as it currently exists to suit the direction our discussion goes, or if it would be easier to start with a fresh document and only add what we agree on. Once we have our meeting hopefully it should be a little more clear how much of the existing spec we can re-use, and where we might want to do things differently!

For everybody new to spec-writing, check out bikeshed to see the tool that we'll be using to compose the spec itself. You write a custom markup language that gets compiled by bikeshed and turned into the styled, HTML spec that you view in the browser, and much of the cross-linking and references between specs are computed automatically.

To all fellow contributors — I really look forward to what we can get done this year!

marcoscaceres commented 6 years ago

@beep nailing down the use cases/reqs sounds like the way to go! Please ping me if you need me to review those.

ZeeCoder commented 6 years ago

We might as well share that list here @tomhodgins ? 😈

tomhodgins commented 6 years ago

The list me and @ZeeCoder ended up with were:

Is that a good set of topics to start with?

beep commented 6 years ago

@tomhodgins As requirements, some of those seem really great! Others seem a little fine-grained for this stage.

If it’s helpful, I liked how @Wilto framed things last year:

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.

(Emphasis mine.)

In other words, the requirements establish the high-level characteristics of a “successful” solution for container queries, and don’t focus on implementation details. And like the requirements for responsive images they’ll contain a mix of author goals (e.g., querying, like, containers) and vendor goals (e.g., avoiding circularity). And that’s key, I think: we have to advocate for both camps in our spec, or it won’t go anywhere.

Heck, I’d be inclined to suggest we base our work off the Requirements section from the responsive images spec, and see if there’s anything we can leverage. What do you folks think?

tomhodgins commented 6 years ago

Don't worry @beep I understand, and I think the high-level discussion is what everybody is here for. It seems like you and @wilto got stuck on looking for use cases and requirements for a long time. I don't want this to be where momentum dies a second time.

The requirements for what the concept needs are pretty well understood by the folks here, many of us have written plugins and use these ideas (with various syntaxes and implementations) already, so a key outcome of this discussion will be evaluating what we have all done so far, what has worked, what can work together, what didn't work, and figure out what we need and want - long before searching for a syntax that can express whatever we come up with together.

Another thing that most of us haven't had the opportunity to do yet (at least in the context of element queries) is dialogue directly with browser folks about what is possible, what things might be harder to implement than others for browsers, and what things are closer to 'impossible'. From a plugin standpoint, I think we've discovered many of these 'more good' and 'less good' ways of doing things, but there's still a big gap in communication between developers and browser makers on this issue I hope we can bridge :D

Would you be able to help bridge the gap between developers and browser makers?

beep commented 6 years ago

The requirements for what the concept needs are pretty well understood by the folks here, many of us have written plugins and use these ideas (with various syntaxes and implementations) already, so a key outcome of this discussion will be evaluating what we have all done so far, what has worked, what can work together, what didn't work, and figure out what we need and want - long before searching for a syntax that can express whatever we come up with together.

@tomhodgins I’m not sure what you’re proposing. Could you clarify what you see as the next steps?

Just to reiterate my position: the gap between a prollyfill/plugin and a native solution is vast. (Even when that plugin is as well-made as your own EQCSS.) So while there’s a considerable amount of prior art out there, getting well-defined use cases and requirements are what’s going to help us get a solid container query specification in place.

tomhodgins commented 6 years ago

I’m not sure what you’re proposing. Could you clarify what you see as the next steps?

The next step is to create Github issues to house the discussions for these topics. We had organized them in roughly chronological order, so you'll notice things like 'naming' and 'syntax' come later on list because the content of those discussions would depend on the outcomes from some topics earlier on the list.

You said that some of our topic ideas were “really great” and some seemed a little fine-tuned, but didn't mention which are which. Could you tell us which topics you think are the “really great” ones so we can begin with those?

Just to reiterate my position: the gap between a prollyfill/plugin and a native solution is vast. (Even when that plugin is as well-made as your own EQCSS.)

I am aware of this, the whole reason we are here is to close the gap between the best that we have been able to do so far without any help from browser makers, to a standardized solution that developers and browsers can both agree on and build toward.

A side note about EQCSS: it isn't the only element query plugin I've made, it's not even the only EQCSS plugin I've made, it's just the first plugin that started my years-long element query plugin-making habit. I probably average a new element query plugin every month — I just can't stop experimenting with this area of research! 😍

So I'm constantly experimenting with new ideas in this space, constantly researching, and constantly learning how to define and build things simpler! All of these plugins have completely different goals, different syntax, and different features. When we first made EQCSS we didn't really know what we were doing. Every plugin I've written after EQCSS tackles the same problems, but manages to solve it with less code, run faster, and distills the individual ideas more clearly. If you look at EQCSS.js, all that functionality is probably 15+ individual smaller plugins that I now know how to write individually and express in much shorter amounts of code, separately from the other parts.

So while I wouldn't hope anybody would point to the code of EQCSS.js as what we should be trying to replicate in the browser, I do hope we can learn from what EQCSS, plus the dozens of other plugins that have come after it can teach us, while we try to spec out the features we want to standardize for CSS authors and browsers (and plugin and tool makers).

So while there’s a considerable amount of prior art out there, getting well-defined use cases and requirements are what’s going to help us get a solid container query specification in place.

There are element queries on thousands of sites in production right now. Not only do we have plugins, demos, articles, websites, and videos explaining the use cases and showing off what these concepts can do, but we have thousands of actual uses out there we can look at today to see how people are actually putting these ideas to use. We can count and measure which features are actually being useful to authors, and see which techniques have been the most helpful in practice.

We need to look through the stylesheets of the sites already using these ideas in production to understand what our solution must to address in order to be useful to the people already using these concepts. If we specify something that fails to capture the needs people are using the idea for today, then our specification will be worthless to them in the future and they will continue solving this idea the ways they already are.

We're at the point where standardizing the existing solutions already out there will be a benefit to everybody already using these ideas: site owners, CSS authors, tool makers, etc.

What 'use cases' are we still looking for exactly?

eeeps commented 6 years ago

Re: input from browser folks – this giant, five-year-old thread is the best resource that I have found, as far as understanding the fundamental constraints that are going to be placed on this work by browser layout-engines. It’s mostly centered around the circularity question, involves lots of scary phrases that I pretend-erstand like “2^n relayouts where n is the number of nested min-content elements”, and ends up with everyone agreeing that the way that <iframe>s work, now, provides a way forward. My sense is, this conversation was part of the inspiration for the CSS contain property — but I’m getting ahead of myself!

The more dialog we can have with people who understand and work on browser internals, the better. In my mind that's one of the main functions of the group – bringing authors and spec/browser folks together.

In the meantime while it’s just a bunch of us authors here – boy, does that Use Cases and Requirements doc need... something. Anything. Right now it has exactly one (very-well-illustrated!) use case and zero requirements.

Everything that @beep said about that horse necessarily coming before any syntax carts is true × 💯

@tomhodgins I completely agree that the large body of thousands of existing, polyfilled pages is a great place to start building/communicating a shared understanding of what authors need/want here. Do you have the bandwidth to undertake a survey like this? Maybe we should spin up a separate issue to track progress?

keithjgrant commented 6 years ago

That one example is perfectly iconic: using width of container to determine which layout to use for the module within.

A second use case that follows logically: what about using height to determine the layout of the module? Then, other media-query-esque features, like aspect-ratio/orientation of the container?

I just thought of another, way-outside-the-box possibility: the darkness of the container‘s background color (e.g. to adjust font & border colors to a different scheme). Smack me if I’m getting feature-creep-y here 😱

I’m unsure how vital each of these would be, but they seem like a reasonable considerations to start with.

tomhodgins commented 6 years ago

the large body of thousands of existing, polyfilled pages is a great place to start building/communicating a shared understanding of what authors need/want here. Do you have the bandwidth to undertake a survey like this?

Anybody interested in checking out the code being used with these plugins can use a source code search engine like one of these:

If we're going to be investing some money into researching this, we should have a clear idea of what we're looking for and how we will use that information once we collect it. I think an “element query census” like this would give us an updated view of the reality of where things are at today:

Are those reasonable goals for looking at the body of existing solutions in production? How would we use those results once we have them?

Also: Is anybody wanting this research to happen willing to chip in some $$ to help make that possible?

Everything that @beep said about that horse necessarily coming before any syntax carts is true × 💯

I think it's very safe to say everybody here is all on the same page about this!

ZeeCoder commented 6 years ago

I think it's important we have a concise list of requirement / use cases. We basically need to zip all the things @tomhodgins refers to into something more digestible / approachable.

I think that would also make it more appealing for browser vendors: a simple set of features with clear goals and constraints is easier to consider / argue about.

marcoscaceres commented 6 years ago

@tomhodgins wrote:

The requirements for what the concept needs are pretty well understood by the folks here.

This is true. But the requirements document helps me pitch this internally within Mozilla (who are not web developers!). When @tantek and I take this back to our implementation teams within Gecko, we need to have good answers to why this is needed (and why the polyfills are insufficient, and why this can't be done with Houdini, JavaScript, or whatever - basically, we need to answer the whole gamut of questions that will get thrown at us).

We (Mozilla) don't allocate resources to things lightly, because it will be competing for limited resources over other things we want to add to the web... the same goes for other browser vendors. So whatever we take back to Mozilla needs to be rock solid.

The use case and requirement document is crucial.

@ZeeCoder wrote:

I think it's important we have a concise list of requirement / use cases.

Absolutely. Don't go nuts and keep it short! Aim for 1-2 pages of non-boilerplate content MAX. The Responsive Images document is very detailed because the WHATWG folks were having trouble understanding what we needed, so we had to provide lots of detail. I don't think that's the case here - it's like @eeeps said, "it's like an iframe" and working out exactly what that means.

Folks here do understand the problem and what we want here (so it should be no drama to bash what we need out)... the document helps us articulate that, and it gives us something to aim for.

Basically, when we do finally have a spec, I should be able to pick up a requirement and say, "Oh yeah, if I do X, I can totally address requirement Y". It also helps us understand what is in or out of scope.

@tomhodgins wrote:

If we're going to be investing some money into researching this, we should have a clear idea of what we're looking for and how we will use that information once we collect it.

We don't need to go this far. All browser vendors know this is a problem that we need solved for the Web. We just need to frame the problem properly and what bits of it need to be tackled.

Also: Is anybody wanting this research to happen willing to chip in some $$ to help make that possible?

If it comes down to it, Mozilla can pony up the money. But I don't think we need that yet. We are at the point where we need to articulate the scope of the project. And, as @beep said, the use cases and reqs are needed for that.

tomhodgins commented 6 years ago

I've revised this shorter list as a springboard for further ideas based on the requirements section from the more sprawling EQCSS spec

Are these the kind of requirements we're looking for? If so, I can't imagine we'd have a solid list of requirements like this until after we've had a few discussions and figured out for ourselves the scope of what it is we're trying to specify.

I could only come up with ~3 very general requirements so far, based on the limited discussion we've had to date in this repository, and even these probably aren't 100% locked down :D

Is there a similar list of use cases and requirements for CSS media queries somewhere we can reference? It seems like a lot of what we'll be doing here will be expanding on top of the great work done bringing media queries to CSS.

(Sample) Requirements for Element Queries

  1. The solution must allow authors the ability to toggle the inclusion of CSS rules based on conditions relating to the properties of an element in an HTML document (rather than the viewport, like CSS media queries)

This is the concept of element-based breakpoints

  1. The solution must allow authors the ability to query various properties of an element in the HTML document that match a CSS selector to determine the validity of CSS rules

This is the concept of querying properties of elements as they appear rendered in an HTML document

  1. The solution must allow authors the ability to query conditions based on an element's width and height, and possibly other conditions like number of child elements or text content length, in an HTML document

This is a list of potential query features

  1. If the solution uses a CSS at-rule syntax rather than a pseudo-class syntax, the solution must provide a way to target and select the elements in the HTML document which match both a CSS selector and the query conditions (something like a :self selector)

This is a description of a self-targeting selector

beep commented 6 years ago

This is a real good start, @tomhodgins! A few off-the-cuff thoughts from me:

This is looking solid! Excited to see how this shapes up.

keithjgrant commented 6 years ago

Regarding circularity: I agree this is going to be a very important point. But I want to make sure we’re careful how we approach it. Based on the current use-case, we do want a CQ to affect the container's layout—but only in the opposite dimension of the query.

For example, if we want to re-layout the module based on the container's width, this will, by definition, almost certainly affect the container’s height. But I think it’s safe (and probably necessary) to say it cannot affect the width.

beep commented 6 years ago

Based on the current use-case, we do want a CQ to affect the container's layout—but only in the opposite dimension of the query.

@keithjgrant Oh, that’s an excellent point. Thank you.

So just following that out a bit, presumably that’d preclude and queries, huh? Query the width and the height could change, or query the height and the width could change, but not both?

tomhodgins commented 6 years ago

Let’s make sure we’re standardizing on “container queries” for the name. (On reread, I realize that might have been caused a copy/paste from EQCSS; if that’s the case, please ignore this note!)

It wasn't caused by copy/paste, the term we use here should be the result of the Name for the Specification topic. Should we create that topic and discuss it?

We absolutely need a requirement on avoiding circularity. Something like, “In order to avoid circular layout dependencies, the solution MUST ensure that a query-enabled container’s layout is not affected by changes to any descendant element.” (Except with, like, better words than that. 😄)

This is the idea of the 'container' in container-style queries. This was the first topic slated for discussion as Query targets: self, child elements and global scope (Talks about the targets and possible boundaries of queries.) as well as the topic Circularity (What can browsers do about it?). Should we create these two topics and discuss them?

I’m unsure about the possibly other conditions like number of child elements or text content length clause. Personally, I feel they’re out of scope for CQs, but I’d be interested to hear what other folks think.

When citing “conditions” or “various properties”, do we need to be more explicit? For example, the respimg use cases spell out “viewport dimensions, screen resolution, and device-pixel-ratio” as selection criteria. (@marcoscaceres and @eeeps might have some insight as to what’s best for our use cases.)

This was what the What Query Conditions to Support (What are the essentials and what are just nice to have?) topic was about. Should we create these topics and discuss them?

The fourth item seems like it’s diving into syntax.

It wasn't, it's diving into the concept of a self-selecting selector. If I was diving into syntax examples, that might look like this in the case of a pseudo-class:

selector:pseudo-class(true) {}

Which naturally works as a 'container' selecting self and its children in almost all ways you can already compose a selector using CSS, like:

selector:pseudo-class(true) child {}
body selector:pseudo-class(true) {}

In both cases, the selector acts as its own self-selecting selector that applies styles only to that element and its descendants. The only edge cases I can think of where using a pseudo-class based selector could select an element outside of itself would be in these edge cases:

selector:pseudo-class(true) + * {}
selector:pseudo-class(true) ~ * {}
:has(selector:pseudo-class(true)) {}

So we would need to specify in those cases what we would do about those—if a pseudo-class style syntax ends up being what we support.

In the case that the syntax is provided as an at-rule, there would need to be some kind of idea of a self-selecting selector that could be used inside the group body rule to represent the element(s) matching both the selector and the query conditions:

@at-rule {

  :self {}

}

The edge cases where this syntax would let you select an element beside or outside itself are similar as before:

@at-rule {

  :self + * {}
  :self ~ * {}
  :has(:self) {}

}

Can you revise that item to be a bit higher-level? Like, what’s the goal we’re trying to achieve with that?

So rather than including ^ this kind of syntax in the requirements, I happy to talk about things at a high level. Can you think of a higher-level way of expressing the concept of a self-selecting selector than what I wrote?

In looking over the respimg use cases, I like the requirements for graceful degradation (3), min/max values (6), polyfills (8), and performance-friendliness (10). Are those relevant here?

Things like that should be relevant here, as much as they are for things like CSS media queries. I really think we'll be able to glean a lot of insight from how CSS media queries are specified for the work we're doing.

For example if you look at the media queries spec the different conditions you are able to query are called "media features". Media features come in different types: "range" and "discrete". For media features of the "range" type, you can use min- and max- prefixes, as well as a special range syntax with comparisons like > or < (and more).

You could say that all of the following media query features depend on knowledge of the viewport's inner width, that's the knowledge that's being exposed from the browser to CSS:

The media feature width is a range-type feature, it is based on knowledge of the viewport's width, and it can be used in the following ways:

@media (min-width: 500px) {}
@media (500 < width) {}

Orientation is also a media feature that is based on knowledge of the viewport's width, but it is not a range-type feature, so you can't use min- or max- prefixes with it like this:

@media (min-orientation: landscape) {}

If we're discussing element query conditions there are 2 facets:

Those 2 decisions have to be decided before we could decide which features might be range-type and accept min- or max-, and which features might be discrete-type. Trying to figure that out at this point would be getting into syntax before we know the scope of what we're building here.

Knowledge of an element's own offset width in the layout could power (for example) the following query conditions:

Maybe we want those, maybe we don't. But how these get exposed in syntax is a totally separate issue. It seems that a feature like width could be expressed as a range-type feature, so maybe we could design a syntax that allowed authors to use it with min- and max- prefixes. It appears orientation is not one of those.

This is all stuff we will have to discuss to figure out what we want, what's feasible, and the best way we can expose those features to CSS authors.

@beep Here you've said that some of the topics we had listed seemed "really great", can you let me know which topics those are so we can go ahead with those? I think those topics are the 'Requirements for writing the Requirements' ;)

ausi commented 6 years ago

I’m unsure about the possibly other conditions like number of child elements or text content length clause. Personally, I feel they’re out of scope for CQs, but I’d be interested to hear what other folks think.

@beep I think too that these conditions are out of scope, they are probably more related to the :has() selector.

In the case that the syntax is provided as an at-rule, there would need to be some kind of idea of a self-selecting selector that could be used inside the group body rule to represent the element(s) matching both the selector and the query conditions:

@tomhodgins I think the concept of such a selector is already present in CSS with the “Reference Element Pseudo-class: :scope”

tomhodgins commented 6 years ago

they are probably more related to the :has() selector.

The :has() selector is for selecting elements that contain other elements that match CSS selectors. If anything, :has() is more like a 'parent selector' than like element queries. In the case of testing an element's text content length, that's not really a child element or something a selector can select, so I don't see how it would relate to :has() at all — it's something :has() can't do.

In the case where you would write something like :has(*:nth-child(4)) to select elements that contain an element that matches a selector based on :nth-child, it's an indirect way of querying the number of children an element has, but in this case you're still selecting one element (the one that :has() targets) based on matching another different element to another different selector. In this case you're not querying the element you're selecting directly, so that's the difference between what we're talking about and what :has() is.

However, number of children and text content length are both things that are exposed through Mutation Observer, so it seems like there is already some mechanism in the browser for handling these values in a similar way that we might be able to build on top of Resize Observer for width and height based queries!

The majority of element queries written use an element's width as a breakpoint, but if other properties are equally as difficult/easy to implement in the browser as width is, I think it's worth considering them too :D This is where we need to hear from browser developers to see how other features compare in difficulty to implement compared to width.

It could be that there would be different levels to this spec too (Level 1, Level 2, etc) that would contain different features to come first, and others that build on top of the previous levels.

I think the concept of such a selector is already present in CSS with the “Reference Element Pseudo-class: :scope”

It does sound similar, and it would be good to know the current status of :scope. As I understood it, :scope had been specced and enjoyed preliminary support in multiple browsers at one point, but I believed support was being removed for it currently.

Who knows the answers to these questions?

ausi commented 6 years ago

Do we know the reason why it was removed from browsers that previously implemented it?

I don’t know of any browser that removed support for :scope. It’s supported in every major browser except Edge (see codepen).

Maybe you are thinking of <style scoped>? Because this feature was removed from browsers some time ago.

The majority of element queries written use an element's width as a breakpoint, but if other properties are equally as difficult/easy to implement in the browser as width is, I think it's worth considering them too :D This is where we need to hear from browser developers to see how other features compare in difficulty to implement compared to width.

I totally agree! Maybe we should try to get this topic represented similar in the requirements? Meaning width and height MUST be queryable and other properties that fall into the same category (from a browsers perspective) MAY be supported too.

tomhodgins commented 6 years ago 
<ul>
  <li>item
  <li>item
  <li>item
</ul>

<script>
  // should be ul tag but returns null?
  alert(document.querySelector('ul').querySelector(':scope'))
</script>

In this example, shouldn't :scope refer to the <ul> element itself? It seems like it can only be used for the purpose of querying an element's children, but not used to select the element itself. In JavaScript what's the practical difference between:

document.querySelector('ul').querySelectorAll(':scope li')
document.querySelector('ul').querySelectorAll('li')

Don't both of those lines equally refer to only those <li> elements inside the particular <ul> element that's selected in JS as the point of reference with document.querySelector('ul') rather than starting with document?

But you're right that I was thinking of <style scoped> when I was talking about browser support, because I thought when that was supported in HTML the idea was that you would use :scope as a selector inside your CSS stylesheets, rather than :scope only being something supported when querying the DOM via JS (like with querySelector, etc).

Is/was there ever a way to use :scope as a selector inside a CSS stylesheet?

ausi commented 6 years ago

querySelector(':scope li') and querySelector('li') are practically the same, but querySelector(':scope > li') makes a difference for example as it only matches lis that are direct children. And there is also a difference between querySelector('ul li') and querySelector(':scope ul li'), the first one matches, the second one doesn’t.

Is/was there ever a way to use :scope as a selector inside a CSS stylesheet?

None that I know of, but I don’t see a reason why we couldn’t reuse this selector for CQs (if we need this feature at all).

beep commented 6 years ago

Hey, there’s some excellent stuff here, but I feel this thread’s gotten a little off-scope.

If we’re looking for a lead editor, I’m hearing a lot of different perspectives: on the parts of the specification we should be focusing on first; on what constitutes “good” use cases; on various syntax discussions; and on relitigating the container queries name. And while all of these are excellent topics, that still leaves us without an editor.

So! A pre-coffee proposal: let’s table this discussion until our kickoff meeting, where someone who’s ~survived~ gone through the standards process—perhaps @marcoscaceres, @eeeps, @yoavweiss, and/or @Wilto?—could advise us on how to get started. From there, we could figure out who best matches up with an editor’s (or co-editors’) responsibilities.

How’s that sound?

tomhodgins commented 6 years ago

but I feel this thread’s gotten a little off-scope.

If we’re looking for a lead editor, I’m hearing a lot of different perspectives: on the parts of the specification we should be focusing on first; on what constitutes “good” use cases; on various syntax discussions; and on relitigating the container queries name. And while all of these are excellent topics, that still leaves us without an editor.

No. It doesn't leave us without an editor. Though I haven't gone through the standards process before, I am the only person here who has succeeded in writing a spec for element queries so far, and I'm willing and wanting to do this work, and it seems like you're trying to remove me from this role before the work can even begin.

A few days ago I posted the list @zeecoder and I had put together for topic discussions and you said some were "really great" and I've asked you which are which, so we can go ahead and begin those discussions in their own proper threads rather than here.

yoavweiss commented 6 years ago

I think it makes sense to take a step back and look at the goal here. As I see it, the goal of this repo is not to just create a document, but to eventually enable shipping of a feature that solves the problems developers are facing, and which this community is set out to solve.

Creating a deliverable describing the use-cases and the requirements is needed in order to support those, but that is just the first step. After that, the community would need to move on to specify the eventual feature in a way that is implementable, and is likely to actually be implemented by browser engines.

Looking at your list of use-cases and requirements, I see you are approaching the problem from a "how will it work?" and "what would it look like?" approach rather than a "what does it need to do?" one. I think the latter is significantly superior to the current phase we're at.

For the use-cases part, you shouldn't worry about "Query targets" and "Media Types". You should ask yourself:

I think it's great that you're enthusiastic about this problem space. At the same time, at least on this thread, it seems like your passion for the subject drove you to shut down other people's opinion in favor of your own.

Being a primary editor of a community use-case document or specification is not a responsibility to be taken lightly and certainly not something that you call dibs on. You have to gain the community's trust, and based on this thread, I don't know that this is the case here. Therefore, I really don't appreciate you closing this issue while the discussion is still ongoing.

tomhodgins commented 6 years ago

I'm sorry for closing the issue, and I'm not sure where I'm shutting down people's opinion so if you felt that way I am sorry for that as well. I think we've got a chance in this repository to start with a fresh discussion to work these ideas out, and I'm excited to help get that discussion going. I'm not trying to shut out opinions, I'm trying to collect and organize them, and the more the better :)

We both have the same goals here, and have been doing everything I can for the past few years to be able to do this the right way. I also want to see to it that we give this the best shot at coming up with something helpful, something implementable, and something usable, but so far without a discussion involving people who understand browsers there has previously been a limit on how much progress we could make. The more we can close that gap between developers and browser folks who can tell us about what would be helpful to have, the easier it will be to come up with something useful.

This list of questions is great, I could write about each one and give examples—is that okay to do here on Github or should I do that in a blog post instead? Are there more questions like this that would be helpful to answer?

ZeeCoder commented 6 years ago

As I see it @tomhodgins sort of picked up the mantle based on this comment by @marcoscaceres .

While I don't have a problem with that, I support talking things over at the kickoff. Therefore I would close this issue in favour of the kickoff meeting: https://github.com/WICG/cq-usecases/issues/50

I hope we can do something next week maybe?

ZeeCoder commented 6 years ago

👆 How does that sound @yoavweiss ?

yoavweiss commented 6 years ago

This list of questions is great, I could write about each one and give examples—is that okay to do here on Github or should I do that in a blog post instead?

Either on a separate GH issue or a blog post. A blog post is probably better for long form explanations (which we could later potentially sum up).

Are there more questions like this that would be helpful to answer?

Could be. I haven't followed up the discussion all that closely, so it's very likely I'm missing some more things that need to be spelled out. The larger "meta" questions we'd need to answer are: "Why is this thing needed?", "who will it help?", "in what way?", etc. The more specific questions are derived from that.

Therefore I would close this issue in favour of the kickoff meeting:

50

I hope we can do something next week maybe?

I'd prefer it if we keep this issue open, but discussing that during the kickoff meeting sounds like a good idea. I'll do my best to join it.

marcoscaceres commented 6 years ago

@tomhodgins wrote:

and it seems like you're trying to remove me from this role before the work can even begin.

I'm pretty sure this is not what @beep said or is trying to do. I'm frankly a little bit concerned to be reading this 😔 More below, where I try to clarify what the role of Editor is...

@yoavweiss wrote:

For the use-cases part, you shouldn't worry about "Query targets" and "Media Types". You should ask yourself: ...

Exactly - this list is critical. I think I said similar things elsewhere. We should make separate issues for each of those, and attempt to answer them (as pull requests, into the main use cases document).

@beep wrote:

When citing “conditions” or “various properties”, do we need to be more explicit? For example, the respimg use cases spell out “viewport dimensions, screen resolution, and device-pixel-ratio” as selection criteria. (@marcoscaceres and @eeeps might have some insight as to what’s best for our use cases.)

Something along the same lines - what is best is to always link it back to concepts already defined by CSS - so to avoid duplicating definitions, and so there is a clear path to integration. I don't have specific conditions and properties in mind, as this is not my area. But yes, I would expect to see those listed or given a bit more thought.

Again, let's make this a separate bug, as this is outside the scope of this issue.

@ZeeCoder,

As I see it @tomhodgins sort of picked up the mantle based on this comment by @marcoscaceres.

To be clear, we are seeking volunteers. Sometimes it's hard to get even one editor, but sometimes we get lucky and we get more.

However, as @yoavweiss said, being an editor comes with significant responsibilities: particularly with respect to consensus building, temperament, and working with the community. What we do not want, and will not have, is to have a benevolent dictator as an editor (we created the WICG and RICG in response to this at the WHATWG) - and we do not want to limit this to a single editor, if others are willing to help edit.

The role of an editor is one that helps bring out the best possible technical solution, while supporting other folks in the community so they can contribute.

A editor drafts pull requests (based on discussions), but will then seek review and an OK from other editor's and implementers before merging into the main spec - and only once consensus is reached shall text land in a spec. Here is an example pull request from the Payment Request API, which I currently edit, to show how this process works in practice: I can't merge stuff until I get an ok from 4 implementers - including other folks at Mozilla - and other people in the community.

This does not preclude anyone else from contributing spec text via a pull request. Everyone is invited to contribute and edit spec.

So the questions to ask for anyone wanting to be an editor are, am I willing to:

The above is basically the job of being an editor. Here is another excellent take on what an Editor does, which has been guiding my own work as Editor for many years:

"the editor should expect to have all the responsibilities of the author but none of the rights. That is, the editors should definitely expect to draft the specification without relying on wording from others in the WG, but not to have the kind of intellectual ownership that comes from being the ones who determine what should and should not be in the spec. The intellectual responsibility for the spec should remain with the WG, and the editors need to be willing to write into the spec whatever the WG decides, even if they personally would prefer something else. Ideally, editors need to practice egoless writing and draftsmanship in much the same way that some programming disciplines encourage egoless programming. Of course, in practice the editors will tend to have some leeway in matters which the WG does not explicitly decide, and it would be a very unusual editor who is not ipso facto an influential voice in WG deliberations, so I have known some good editors who were not noticeably egoless."

There is more great guidance in that email, so I encourage everyone to read it.

Hope that helps!

ZeeCoder commented 6 years ago

All right so in light of all that: would you still want to be (maybe one of) the editors @tomhodgins ?

Is there anyone else?

tomhodgins commented 6 years ago

Yes, the description of what and editor needs to be and do sounds like something I can do for us :D

I'm not trying to inject my own opinions here—I have my own draft spec that's 100% full of my own opinions that I can fire up and write in any time I want. Not having an opinion of mine accepted here doesn't stop me from writing it somewhere else.

I'm not trying to inject my own solutions here—I already have a dozen plugins that work in different ways that do everything I have wanted and dreamed for. Not having a solution of mine accepted here doesn't stop me from using that idea, I can make a plugin today and start working with it tomorrow.

I'm not doing these things, and I don't gain anything by making this group effort close to things I've already done, but we all gain if we can come up with a standardized solution together that everybody (including browsers) can use today and in the future. To help get us to that point, I want us to benefit from all of the research, vocabulary, and experiments me and others have created so far to help tease out the best solution for everybody, but that's very different than insisting that whatever we come up with together must look or sound like something done in the past, which I am not doing I don't think anybody (not even me) benefits from.

I see this repository a totally blank slate, and all issues before #44 are history. Since we haven't discussed much yet, there are basically 0 opinions 'in this project' so far, but once discussion gets going I'm sure we'll have a lot of different points to consider. I really look forward to that and can't wait to see what we can come up with together.

It sounds like being editor is like being in the air traffic control tower coordinating flights rather than piloting one of the planes flying around in the air 🛩 🗼 ✈️

dennisgaebel commented 6 years ago

I don't desire to be a "primary anything," but what I would like to offer is any and all help to ensure whatever is written can be read and deciphered by a 6 year old.

marcoscaceres commented 6 years ago

This is great all.

@tomhodgins wrote:

It sounds like being editor is like being in the air traffic control tower coordinating flights rather than piloting one of the planes flying around in the air

Correct. Though sometimes you'll be asked to jump into a plane. Get your pilot's suit ready👨‍✈️.

The Chairs are the ones that keep the airport running and the traffic control towers operational (and the rest of us employed... i.e., assigned to the right issues at the right time).

By the time we meet (#50), we should have a plan for how we proceed over the next few months. I'm working with @beep and @eeeps on that.

@dennisgaebel wrote:

help to ensure whatever is written can be read and deciphered by a 6 year old.

Much ❤️ for this. Please be sure to track incoming pull requests. Making the writing accessible to a wide audience will be critical for the use cases/req doc, so we are going to be counting on you :)

dennisgaebel commented 6 years ago

@marcoscaceres I appreciate that. Unfortunately I don't have time to track incoming pull requests, but If someone were to ask for my help on anything I will make myself available the best I can.

marcoscaceres commented 6 years ago

Given #50 and what we decided there, closing.