W3C home > Mailing lists > Public > public-html@w3.org > April 2016

Always use h1-h6 by level again

From: Chaals McCathie Nevile <chaals@yandex-team.ru>
Date: Sat, 16 Apr 2016 19:19:33 +0200
To: "HTML WG (public-html@w3.org)" <public-html@w3.org>
Message-ID: <op.yf0vqvm1s7agh9@widsith.local>

TL;DR: https://github.com/w3c/html/issues/169 is likely to be adopted in  
the next Public Working Draft, about the beginning of May.


As a key part of the outline algorithm, HTML recommended two ways to use  
headings. One was the standard approach of having h1 as the most important  
heading, with h2 for things one "level" less important, and so on to h6 -  
as had been the case since HTML was made public.

The other was effectively a copy of the <h> element in XHTML2, but using  
the h1 element and an "outline algorithm", so you could use "sectioning  
elements", and in each sectioning element provide an h1.

The benefit is that it means copying and pasting structures into different  
levels of a page will mean the headings are recalculated.

The minor drawback is that to make it work it is important to have  
sectioning elements, which can get very verbose for simple content.

The major drawback is that this approach doesn't actually *work*.

Browsers produced a naive browser stylesheet, so that in a example like

<section><h1>An outer section</h1>
   <section><h1>A sub-section</h1>

The inner, subsection heading, would *appear* smaller. But this stylesheet  
is easy to selectively override incorrectly, and the visual effect is not  
reflect in e.g. accessibility APIs. So on all browsers I can test, both  
headers are reported by screen readers as being a level 1 heading, even  
though on those same browsers they *look* different.

Given that this bug has been around, and not fixed in browsers, for many  
years, we are proposing to remove the suggestion, and return to the model  
where elements h1..h6 have a defined level of their own.

As Marat Talanin noted, having an actual <h> element designed for this  
would be a potential solution that would be backward compatible with  
existing browsers and content, by not creating a conflict. But that  
requires broser implementation before we could claim it is real.

Comments welcome on the github issue as always.

Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Saturday, 16 April 2016 17:20:40 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:18 UTC