-
Notifications
You must be signed in to change notification settings - Fork 24
Requirements section #36
Comments
(Ah, jinx—the above overlaps with @Wilto’s comment on WICG/container-queries#6.) |
If we were to add a Requirements section to this document what would it look like for element queries? Over the course of developing EQCSS we've run into a number of roadblocks and decision points that have shaped the syntax into something that has been incredibly useful to work with. I feel like some of these discoveries and decisions are going to be similar to what these requirements specify, I'm just not sure the best way to package the R&D we've done into this format. When writing requirements like these what types of things should be included? When writing my element queries spec I was able to base a lot of the structure on the CSS media queries specs. Would a similar list of requirements exist for media queries anywhere? @Wilto: any advice? |
These requirements, like the respimg ones should only be super high-level, and used for framing any implementation conversations around the feature—no syntaxes, no gritty details. For example:
“Responsive images are…” As for more detailed requirements:
“Responsive images have to be as accessible as regular images” was an immutable requirement from the outset.
We couldn’t rule out a native solution on the basis of not being JavaScript-able—not entirely—but this was obviously a way bigger deal than a nice-to-have. So, thinking through requirements for container queries might be something like this: We know we need to be able to style an element based on the space it occupies in a layout, similar to media queries and the viewport size. The elevator pitch.
We know the parent elements having viewport-like behavior will be complicated. What do we know about it? We know it absolutely cannot result in an infinite loop.
|
Thanks, that's a helpful translation between english to 'spec-ese' :D I'll see what I can come up with for a section like this, I spoke with somebody who was searching for sections like this in various CSS specs recently so I have another perspective on what people reading these details are looking for! |
Given some recent activity in the container-queries repo (e.g., WICG/container-queries#6; WICG/container-queries#7), a question: how does the RICG evaluate the quality of a proposed implementation?
I think it’d be helpful to spell out what the success/fail criteria are for proposed solutions: e.g., does it address circularity concerns; does the syntax meet certain architectural criteria; &c.
I'm wondering if the use cases document needs a "Requirements" section, similar to the one in the responsive images use cases doc.
The text was updated successfully, but these errors were encountered: