The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Not that 80

by Henri Sivonen in WHATWG

In his post Parroting Pareto, Jeremy Keith says that HTML5 needs to cover cases that “fall far outside the 80%-90% curve”, in particular accessibility. “By their very nature, accessibility concerns are not going to affect the majority of users. That doesn’t mean they can be dismissed.”

My understanding of applying the 80/20 rule to the design of HTML5 is that the “80” isn’t about 80% of users. It is about (proverbial) 80% of authoring cases. That is, it doesn’t make sense to support (for accessibility or otherwise) things that people would only publish very rarely if engineering support for the rarity would complicate the implementation of the language significantly.

See Hixie’s email to the HTML WG on the topic.

↔

4 Responses to “Not that 80”

  1. Henri wrote:

    That is, it doesn’t make sense to support (for accessibility or otherwise) things that people would only publish very rarely if engineering support for the rarity would complicate the implementation of the language significantly

    Can some examples be provided for elements and attributes where this has been applied or would apply?

  2. The axis attribute seems to be about supporting a relatively rare authoring case (n-dimensional spaces as tables in a way that presumably is not covered by stacked th elements) that would require non-trivial UI design and browser support.

    More generally, elements with narrow domain-specific semantics have not been introduced even if from time to time someone seriously suggests including a narrow domain-specific element. I guess the canonical examples that keep popping up are elements whose purpose would be making sure that all possible meanings of italicized text have their own element (e.g. biological taxonomical names). See DocBook and TEI for examples of how narrow domain-specific elements can be. However, some grandfathered elements with a relatively narrow domain of use (e.g. samp) are retained, because the cost of dropping them is considered higher than the cost of keeping them.

    Unlike axis, though, these narrow-domain suggestions motivated by a desire to prove i (and b) useless usually don’t come with complex browser UI expectations—merely default styling expectations. However, actually doing something more than just styling with the semantic (to justify the encoding of the semantic) would be either complex or esoteric (or both).

  3. Oh, a better example that I missed in my previous comment: The Web Forms 2.0 date type exist to cater to ecommerce sites where people make reservations using the calendar used for international commerce. Support for non-contemporary dates are handled the easy way: proleptic Gregorian calendar all the way to the start of AD. BC dates, locale-specific Julian roll-overs or calendar systems that aren’t typically used for airline and hotel reservations are not supported.

  4. Still one more example: Web Forms 2.0 week only supports ISO weeks, because ISO week numbers are practically sufficient to cover the majority of authoring cases in locales where week numbers are actually used in communication. (It isn’t worthwhile to support U.S. week numbering, for example, because using week numbers at all is mainly an European thing. Moreover, supporting even one week number schema that deviates from the International Standard would open the floodgates of complexity for all non-ISO week schemes under the sun.)