[mediaqueries-4] Port Media Groups section of CSS2.1

[fantasai]

We have definitions for paged, continuous, static, and interactive media. Currently they exist only in CSS2.1; we should port them over to Media Queries.

https://www.w3.org/TR/2011/REC-CSS2-20110607/media.html#media-groups

[frivoal]

Actually, I am not sure. What do we hope to do with these? They are be defined in a very handwavy way in terms of media types, many of which are now deprecated anyway. And on top of that, they're defined informatively.

I don't necessarily mind defining media groups in MQ4, but I'd like to know more strictly what we intend to do with these, so that I can write useful and accurate definitions.

The only use I know is the Media entry in propdef tables, but I'm not entirely sure what its intended effect is. Almost every property we have says "Media: visual", except:

• animations and transitions which are listed as interactive. I'm not even sure this is right, digital signage isn't interactive, but can run animations
• a handfull of properties related to content, which say all
• A few things in GCPM which say paged
• scroll-snap, and caret-color, and nav-*, which claims interactive (but not visual, which seems odd to me, given that scrolling itself needs visual, and that interactive does not necessarily imply visual).
• appearance, which claims all, but seems to me that it should say visual

Also, if we make this normative and link to it from every propdef table, every spec will have a normative ref to MQ4, I hope this doesn't slow things down on the REC track.

And if this is informative only, then the current text from CSS2.1 barely says more than listing the names themselves.

All in all, I think we'd be just as fine dropping the Media line from propdef tables.

[frivoal]

oops, posted early. Also: will-change and custom properties says they're for all.

But piling up on animations and transitions, interactive definitely doesn't seem right, since e-ink devices are interactive, but don't (typically) support transitions and animations.

Anyway, other than saying "this property is not supported in implementations where it doesn't make sense, which we're not 100% sure how to categorize", I don't see how this does anything useful. I'd just drop it.

[css-meeting-bot]

The Working Group just discussed porting media groups, and agreed to the following:

• RESOLVED: Remove Media line from all propdef tables

The full IRC log of that discussion

<heycam> Topic: porting media groups
<heycam> github: https://github.com//issues/2413
<heycam> florian: CSS 2.1 has a section, media groups, which decribes what media groups are
<heycam> ... visual, interactive, static, things like this
<heycam> ... it doesn't define what they are, just lists what exists
<heycam> ... then says visual is print or screen or tv or handheld
<heycam> ... interactive is print or screen or somet tvs
<heycam> ... this is used in the propdef for every property definition
<heycam> ... Media: Visual
<heycam> ... fantasai suggested porting this to something else
<heycam> ... but I don't think it does anything useful
<heycam> ... unllike the Applies line, which says browsers will do nothing on some elements
<heycam> ... this basically says "on some browsers this property won't be supported"
<heycam> ... they're insufficiently described
<heycam> ... the way we've used the Media line, 95% say Visual, the few that say something else are using it wrong
<heycam> ... I suggest we stop having a Media line
<heycam> dbaron: I think the reality is there's been not a lot of implementation of CSS for anything other than visual media
<heycam> ... and what implementation there has been hasn't provided feedback to the WG, so the specs don't account for it well
<heycam> florian: the animations and transitions properties claim to work on interatctive media, not visual
<heycam> ... if you look at how interactie is defined, it would seem to mean the transitions and aanimations work on a kindle with buttons, but not on a digital signage screen with no buttons
<heycam> ... which is wrong
<heycam> ... so we could define it in a way that's correct
<heycam> ... but it's still not useful
<heycam> frremy: makes sense to me
<heycam> myles: is it valuable to say you can't animate on a piece of paper?
<heycam> RESOLVED: Remove Media line from all propdef tables

[css-meeting-bot]

The Working Group just discussed porting media groups, and agreed to the following:

• RESOLVED: Add a normative statement for properties that say "Media: all" explaining what "Media: all" meant.

The full IRC log of that discussion

<heycam> Topic: porting media groups
<heycam> github: https://github.com//issues/2413
<heycam> fantasai: I ran a grep through the tree
<heycam> ... almost everything is Visual, some exceptiosn
<heycam> ... interactive vs not is not interesting
<heycam> ... but we distinguish between CSS props that shuld affect the accessibility tree, and the ones that shouldn't
<heycam> ... or don't
<heycam> ... content prop affects what shows up to a screen reader
<heycam> ... display does
<heycam> astearns: how is that expressed?
<heycam> florian: by Media: all
<heycam> astearns: are we consistent about that?
<heycam> fantasai: yes
<heycam> ... props that should add or remove content from the a11y tool
<heycam> ... it's an indicator to the screen reader as to what content should be added or skipped
<heycam> florian: I think it's not about screen readers
<heycam> ... it's about audio rendering
<heycam> fantasai: yes, but if we remove this, we need to make sure we're very clear in the spec, explicit wording to say this prop needs to affect non visual things
<heycam> dbaron: I think if that was the intent of the spec, I suspect most implementors missed it
<heycam> ... I think it would be good to have the wording in some other way
<heycam> astearns: I think it would be an improvement to be explicit, rather than hide it here
<heycam> frremy: most of these things, if they're defined, are in ARIA, they explicitly call out the properties and what you should do with them
<heycam> florian: for a11y, probably, for visual and non-visual media .... for the ones that say "all", a normative statement that says "this works on all media" is fine
<heycam> astearns: it should be more explicit
<heycam> ... "such as, screen readers"
<heycam> florian: no
<heycam> ... they don't work like that
<heycam> ... they're a visual media
<heycam> fantasai: but they're also not handling gencon properly
<heycam> Rossen: they do
<heycam> frremy: in Edge it works perfectly
<heycam> fantasai: but it is a common bug
<heycam> frremy: the content thing is defined precisely in the ARIA specs
<heycam> ... I don't believe we need to say anything in the CSS specs
<heycam> ... it says gencon should be exposed
<heycam> ... but it shouldn't require any specific wording
<heycam> florian: I would suggest adding a sentence not a11y specific, calling out that this property is supposed to apply to all kinds of rendering, even not visual
<heycam> ... not specifically to a11y, e.g. audio rendering without a screen reader, don't forget this property
<heycam> astearns: would that be enough?
<heycam> dbaron: sure
<heycam> fantasai: we should have these kinds of sentences anyway. in the propdef table it's easy to look up which ones you need to care about
<heycam> ... but it takes up a lot of space
<heycam> ... removing from the propdef table is a benefit overall
<heycam> ... we should add a statement explaining normatively that CSS requires these to work
<heycam> ... we're defining what the properties mean and how they're interpreted, ARIA then uses that
<heycam> RESOLVED: Add a normative statement for properties that say "Media: all" explaining what "Media: all" meant.
<florian> ScribeNick: Florian

[frivoal]

PRs to handle this:

• bikeshed: Do not generate the obsolete "Media" entry in propdef tables speced/bikeshed#1300
• spec: Drop the Media line from propdef tables #2887