Preferrential Display Explainer

This document decribes a proposal for a CSS mechanism and DOM APIs to aid in increasing the level of separation between visual and non-visual structures with runtime reuse. It is useful for Custom Elements, introduces potentially new explanations for how existing elements in the platform work.

Introduction

When editing a document, an author attempts to mark it up semantically and control a separation of visual aspects through CSS. This allows various the user-agent and tools to use the same semantic data to provide any number of affordances for accessibility, navigation, styling and interaction. HTML elements are generally carefully constructed to define what they do that makes them unique, rather than very specifically how they look. This separation leaves room for certain experimentation and variance that is healthy for the long term adaptability of the platform. For example, because a <select> element doesn't strictly define all aspects of the visual properties, it was possible for mobile phones to provide a better user experience where visual real estate is very limited and click areas are shrunk.

Similarly, an author may use various types on the <input> element, which, if undefined still defaults to type="text" and allows UAs like mobile devices provide native controls. In this aspect, the type attribute in some ways acts more like a hint than a requirement. This is, of course, not entirely true (input type is kind of a debacle actually, APIs actually vary making it improbable to use the intended 'text only' fallback without much pain) but it is a laudbile aim and provides a conceptual background for some of the rationale for this proposal.

These examples which already exist in the platform are good, but they are also potentially limited and somewhat magical. They can have impacts on more than visualization as well, to the end effect that they make it difficult for authors to deal with or innovate within.

Preferential Display is a more generalized and more capable extension of the type idea, allowing an author to specify preference hints of the type "when the media is screen and max-width is 767px, I would like to display elements #foo, #bar and #bat as tabsets if possible". At some low level it simply allows the user to manage a special attribute based on a media query from outside the markup and it desugars into existing platform code in JavaScript something like this:

/* This is basically a possible approach today */
matchMedia("screen and (max-width: 767px)").addListener(function(evt) { 

    var element = Array.prototype.slice.call(document.querySelectorAll("#foo, #bar, #bat")); 

    elements.forEach(function (el) { 

        if (evt.matches) { 

            el.setAttribute("preferrential-display", "tabset"); 

        } else { 

            el.removeAttribute("preferrential-display"); 

        } 

    }); 

})

However, this would be a bit more than you'd like to manage in terms of boilerplate, and order should probably follow selector specificity if they have a generic means to add these, and so we can introduce a new API to manage it - something like this:

CSS.associateDisplayPrefernce({ 

    mediaQuery: "screen and (max-width: 767px)", 
 
    selector: "#foo, #bar, #bat", 

    preference: "tabset" 

});

This is considerably more conveneint, but ideally you'd be able to express this in CSS itself in a way that is familliar ala something like:

@media screen and (max-width: 767px) { 

    #foo, #bar, #bat { preferred-display: tabset; } 
 
};

For example, it might be possible to offer a Preferrential Display for <select-timezone> elements which provides a map-like interface similar to those used for choosing timezones in a desktop interface, but ultimately provides a common <select> view on the same DOM, or a <common-panel-set> which can be displayed as any number of visualizations (tabset, accordion, deck or carousel, for example) but has identical structures and accessibility concerns. It is useful then for an author to be able to state "under these media conditions I prefer a tabset view if you have it".

The design of this proposal is intended to be such that it introduces minimal new concepts, but offers new capabilities which answer some existing questions, highlight the importance of this separation, and provide new opportunities for experiementation.

Aims and Requirements

It should be possible to create an element which might have many different visual variations decided by CSS, solve issues like aria once.
It should be possible for an author of HTML to provide no additional information and get a default view that retains the meaning of that thing
It should be possible for an author of HTML to temporarily provide inline information (we do this with style attribute, for example, or by manually attaching a class which would otherwise be attached dynamically) to verify that what they have renders as expected.
It should be easy for a designer to indicate different visuals in a "whole" way which doesn't require JavaScript authorship. This is a different role in many organizations. That is, it should be possible simply say "this element should opt to this display if possible under these media query conditions."
It should not inflate the payload of the CSS dramatically (see point above - preprocessors offer some author time facilities for this, but not runtime - they are copy/paste use oriented)
It should ideally not require an additional HTTP requests or inlining in the HTML.
It should not introduce wholly new semantics and complicated concepts for authors - minimal magic explainable by things in the platform today.

To these points, what I am proposing is a single, display oriented attribute which is maintained via CSS which allows CSS to express informtation that it can select upon in normal fashion and allow experimentation with the various pieces of the platform that are already in place.

Why not...

Just use CSS as it is today? - The authoring/maintenance of this approach is very painful. If you took something like the above examples, you'd be styling individual elements and pseudo-elements of instances without any hint in the CSS itself (aside from comments perhaps) about what it was styling (ie, I want to display '#foo' as a tabset under these conditions). The CSS winds up being excessively verbose (see Vanilla CSS example below) and cannot be re-used in other stylesheets.. In other words, if you define an 'accordion' it's just a bunch of rules which mean accordion, there is no way from another stylesheet to say 'use those rules', you have no choice but to repeat them.
Just use CSS preprocessor? - The authoring/maintenance of this approach is way better (see preprocessor example below), but it's authoring reuse, so the verbosity and difficult to understand still exists. If it takes 100 lines of CSS to define all of the aspects of a 'tabset' and 100 lines to define all of the aspects of an 'accordion', then you have to define when to use them with those lines in a Media Query. If you put your entire applications CSS into a single sheet which it can statically analyze, you'd have the best possible outcome with this approach, but it just isn't how a lot of things work, so you wind up with a lot of copies of the same rules and no runtime reuse...
Wait for CSS aliases, wouldn't they solve this? - They would make the problem better, for sure. However, it requires you to define all of the aliases at once and then to style individual elements and pseudo-elements with aliases, so many of the same sorts of runtime problems above come into play. The author's mental model is more like 'now it should be type "x"' and then just use CSS as per normal and gain all of the normal benefits of CSS and reuse, so it's better if we can reflect that.
Just set a type attribute? - Because a type is static, but if what we are giving is a rendering hint and you are aiming for definiing what it -is- and then styling it, can be variable.
Manage a type attribute with DOM APIs in JavaScript? - Because styling information about visual presentation really belongs in CSS. There should be an explanation of the system in terms of these primitives, but they should be aiming to describe a concept in the right part of the system, JS and CSS are not exclusive domains and the API should be defined by a CSS WG proposal who is thinking about the larger problem.

Introduction

Aims and Requirements

Why not...

Vanilla CSS example without Preferred Display

Preprocessor authoring example without Preferred Display

Preferred Display