Re: [User Context] alternate taxonomy keys (GPII, Schema.org, etc.) could be implemented as custom media features

On Thu, Oct 30, 2014 at 2:37 PM, James Craig <jcraig@apple.com> wrote:
> Media Queries Level 4 includes a "Custom Media Queries" section.
> http://dev.w3.org/csswg/mediaqueries-4/#custom-mq
>
> It seems extensible enough to use for the alternate taxonomy key use case we've discussed for IndieUI User Context. In other words, it'd be inappropriate to include all of the GPII or Schema.org keys directly as CSS media features, but these groups could choose to implement their taxonomies as prefixed custom media features. I spoke with Tab Atkins (one of the CSS editors, copied here) about this idea briefly at TPAC.
>
> For example, GPII could define a set of de facto "--gpii-"-prefixed keys, and even provide an GUI editor to generate the CSS rules.
>
> The end user could add these generated custom media rules to their user style sheet:
>
>   @custom-media --gpii-prefers-transcript (color) or (monochrome); /* use any always-true media feature */

Using a pair of exhaustive MQs joined with "or" to produce an
always-true MQ is pretty hacky.  You can do this much more directly
with the script-based API:

CSS.customMedia.set("--gpii-prefers-transcript", true);

Using the script-based API, you can also produce custom MQs with
keyword or number values.

I don't think it's worth doing keyword/numeric values for custom MQs
in the CSS syntax, as it's reasonable to assume that they might change
over the lifetime of the page, and I'd prefer people just used the
script API rather than doing more complex CSSOM manipulations.  But
the boolean form might be worth supporting directly in the CSS syntax
(particularly since it's already possible, though hacky, to do pure
booleans), so you can just write:

@custom-media --gpii-prefers-transcript true;  (or false)

> I think this means that, once CSS.customMedia is implemented, alternate taxonomies like GPII and Schema.org can operate on their own to define the list of prefixed keys. If some of those keys end up being useful in mainstream user contexts, those groups could document and propose them individually as mainstream media features, as we did with a few in CSS4.

I agree.  Every a11y feature that actually shows up in browsers, I'd
be glad to get them into the MQ standard.  The taxonomy of *possible*
a11y features, though, is too large and too theoretical to bake in
officially.  This sort of distributed extensibility seems to handle it
reasonably and let the community converge on the types of a11y keys
they want to respond to.

~TJ

Received on Thursday, 30 October 2014 21:53:58 UTC