need primary editor #49
Comments
|
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 |
|
@tomhodgins, that's great to hear. |
|
@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? |
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. |
|
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! |
|
@beep nailing down the use cases/reqs sounds like the way to go! Please ping me if you need me to review those. |
|
We might as well share that list here @tomhodgins ? 😈 |
|
The list me and @ZeeCoder ended up with were:
Is that a good set of topics to start with? |
|
@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:
(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? |
|
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? |
@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. |
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?
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).
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? |
|
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 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? |
|
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. |
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?
I think it's very safe to say everybody here is all on the same page about this! |
|
I think it's important we have a concise list of requirement / use cases. 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. |
|
@tomhodgins wrote:
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:
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:
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.
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. |
|
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
|
|
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. |
|
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. |
@keithjgrant Oh, that’s an excellent point. Thank you. So just following that out a bit, presumably that’d preclude |
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?
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?
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?
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: 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) {}
}
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?
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 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 @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 @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 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 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' ;) |
@beep I think too that these conditions are out of scope, they are probably more related to the
@tomhodgins I think the concept of such a selector is already present in CSS with the “Reference Element Pseudo-class: |
The In the case where you would write something like 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 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.
It does sound similar, and it would be good to know the current status of
Who knows the answers to these questions? |
I don’t know of any browser that removed support for Maybe you are thinking of
I totally agree! Maybe we should try to get this topic represented similar in the requirements? Meaning |
<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 document.querySelector('ul').querySelectorAll(':scope li')
document.querySelector('ul').querySelectorAll('li')Don't both of those lines equally refer to only those But you're right that I was thinking of Is/was there ever a way to use |
|
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). |
|
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 How’s that sound? |
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. |
|
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".
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. |
|
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? |
|
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. I hope we can do something next week maybe? |
|
👆 How does that sound @yoavweiss ? |
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).
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.
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. |
|
@tomhodgins wrote:
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:
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:
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.
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:
There is more great guidance in that email, so I encourage everyone to read it. Hope that helps! |
|
All right so in light of all that: Is there anyone else? |
|
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 🛩 🗼 |
|
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. |
|
This is great all. @tomhodgins wrote:
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:
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 :) |
|
@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. |
|
Given #50 and what we decided there, closing. |
per @marcoscaceres comment in #44
The text was updated successfully, but these errors were encountered: