Requirements section

[beep]

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.

[beep]

(Ah, jinx—the above overlaps with @Wilto’s comment on WICG/container-queries#6.)

[tomhodgins]

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?

[Wilto]

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:

The solution must support selection based on viewport dimensions, screen resolution, and device-pixel-ratio (DPR).

“Responsive images are…” As for more detailed requirements:

The solution must afford developers with the ability to include content that is accessible to assistive technologies.

“Responsive images have to be as accessible as regular images” was an immutable requirement from the outset.

To provide compatibility with legacy user agents, it should be possible for developers to polyfill the solution.

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.

The solution MUST allow the styling of an element’s child elements based on the space the parent element occupies in a layout.

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.

The solution MUST avoid that thing I just said

[tomhodgins]

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!