Declarative Expression of when Affordances should be applied

MediaAffordancesList

For purposes here I am defining what I will call a MediaAffordancesList.

A MediaAffordancesList is a string serializable description that allows authors to express preferred affordances that should be employed when a given media query matches. I am choosing to serialize them like this like this:

<!-- Under 800px, on a screen, I prefer that this is collapseable  -->
[screen and (max-width:800px)] collapseable

Specifically: wrap square brackets around a media query, followed by a name (or space separated names) of the affordances that should apply. There's slightly more ability here (these can be pipe separated) but this is enough understanding of the idea to wrap your head around it.

A MediaAffordancesElement base class

To make use of this, I have defined a MediaAffordancesElement interface. I'm not sure if that is actively useful on its own, really, I think its value is as a base class (potentially a Mixin in IDL) for a few more concrete components. Effectively, what it does is allow you to declaratively configure boolean 'named states' via a MediaAffordancesList and then (in a subclassed/mixed in element or via JS interface) do something useful with that.

You can provide this string as an mq-switch attribute on the element itself if you prefer that, or in your CSS via the --const-mq-switch custom property.

The main challenge here is that this is a new idea in at least some ways, and there a lot of ways to look at the problems, and precedents one can losely compare to. There is a lot to think through about which concerns can or should be where, and why - and how that can (or can't) actually work.

The "easiest" solution seems to be to allow a "default" (configuration) expression in an attribute. That is, it is similar to selected in <option> and not reflective of state. This seems worth allowing as sometimes as it's handy and as it is somehow 'configuring' the states, this seems to ask the fewest new sorts of questions (more below). However, that sort of demands an inline/single expression like the one supported by the custom element and also it's gross if you just want to say "here's how they all work in this design".

The clearest thing for authors would appear to be to do it in CSS. The 'natural' thing to intuit would probably be using existing media query rules and perhaps a property. However, there are a number of challenges and "new" questions this would introduce. CSS would be suddenly helping change semantics and interaction in ways it never has. Some people might note similarlities with appearanace, but appearance really seems to try hard to avoid semantics or interactions changing. One might note that scroll overflow does change interactions, but it doesnt' change semantics. Others still would note that there have long been requests for things "adjacent" to this which would use a "css-like" language (CAS or Generalized Cascading Sheets or Behavioral Stylseheets/XBL)or even simply "a static profile" which could offer enough of those same sorts of ideas we could plug into. These paths are, in some ways, *very* appealing because they open many more doors. However, they are nearly all unknowns and difficult to speculate about much further. One thing that does seem safe to say though is that as they are not 'live' in the 60fps profile, they have more in common with configuratio attributes than they do how we write media queries today. For such a system to use media queries entirely differently (that don't change values but somehow provide complex configuration information) is compelling, but contains many more questions than a single property with all of the information it needs, bound to something for configuration.