Difference between revisions of "ChangeProposals/hgroup"

From HTML WG Wiki
Jump to: navigation, search
(Why subline instead?)
(summary)
Line 2: Line 2:
  
 
=== summary ===
 
=== summary ===
Replace hgroup with [http://www.html5accessibility.com/tests/subline.html subline], an element that more closely reflects current usage for marking up subheadings, subtitles, taglines and bylines.
+
Replace hgroup with [http://www.html5accessibility.com/HTML5extensions/subline.html subline], an element that more closely reflects current usage for marking up subheadings, subtitles, taglines and bylines.
  
 
=== Rationale ===
 
=== Rationale ===

Revision as of 21:14, 7 December 2012

replace hgroup with the subline element

summary

Replace hgroup with subline, an element that more closely reflects current usage for marking up subheadings, subtitles, taglines and bylines.

Rationale

markup examples in support of hgroup do not show a pattern in support of the hgroup construct

  • real world examples gathered on the whatwg wiki do not reflect a compelling pattern or need for hgroup, but they do reflect the usefulness of a proposed element that can be used to signify a subheading, subtitle, tagline and byline. This is illustrated in the same real world use cases provided in support of hgroup, but marked up using the proposed subline element.
    • It is unclear what common markup pattern(s) were used to support the inclusion of the hgroup element in HTML5 as none have been clearly articulated in any change proposal or other communication to the working group (or elsewhere AFAIK), but here is one I can offer:
      • authors use 2 headings wrapped in a container element to indicate a heading and subheading. This pattern can then can be used to check against the real world examples provided in support of hgroup,for example:
<div>
<h1>
<h2>
</div>
  • Of the 19 real world examples provided only 2 exhibit the same markup pattern.
  • If an element such as the proposed subline element is be used to identify subheading, subtitle, tagline and bylines in conjunction with existing HTML5 elements such as header and article, it is more able to be used to identify the semantic constructs as used in the wild and still fulfils the only prescribed use case for hgroup (masking subheaders from the outline algorithm). It does a better job, because it's design is more versatile and better reflects the diversity of ways subheadings, subtitles, tagline and bylines are marked up in the real world. It provides authors with the ability to identify such semantics with a minimum of constraints on how and what markup is used in conjunction with the proposed semantic identifier.
  • It does not codify an existing usage pattern on the web. The creator of <hgroup> describes it thus:
<hgroup> is in fact the result of awaiting patterns. The pattern is that people
use <h1> and <h2> as heading and subheading respectively (without meaning
heading and subsection). All <hgroup> does is wrap them up so they don't impact the outline algorithm.
  • Problem being with the statement "The pattern is that people use <h1> and <h2 as heading and subheading respectively (without meaning heading and subsection)" is that it is not a pattern that prevails over the other patterns that people use to mark up headings and subtitles. No cow paths are being paved with the addition of the <hgroup>, in fact it is the opposite, it is an attempt to force a pattern upon the markup where none previously existed, simply to support the newly created outline algorithm.

The hgroup element has not been generally well received by authors:

  • Bruce Lawson author of 'Introducing HTML5', well known speaker and HTML5 evangelist wrote an article critical of hgroup On the hgroup element Of the 21 unique responses (not including ping backs and off topic) 10 appear to have a neutral tone, 11 appear to be negative towards hgroup, none appear to be supportive of hgroup.
  • HTML5 Doctor a well known site promoting use of HTML5 published an article about hgroup and how to use it ,with a neutral to positive tone: The hgroup element. Of the 52 comments on the article 28 were on topic responses from people other than the author of the article. Of those 28, 13 appear negative towards hgroup, 13 appear neutral and only 2 appear positive.

The hgroup element has not been generally well received by people involved in HTML5 specification development

There are a number of proposals to replace,add other elements or remove hgroup:

The only zero edit change proposal in support of hgroup offers no substantive arguments for its retention

hgroup support has been shipped in multiple browsers, books explaining  
its use have been sold, and content on the Web have started to use it.  
Removing hgroup (and possibly using a different element or markup  
pattern to solve the use case) is disruptive.
  • features obsoleted in HTML5 have shipped support in browsers for some for many years - this is not a substantive argument for retention
  • Many books have been sold explaining the use of features now obsoleted from HTML5 - this is not a substantive argument for retention
  • Features obsoleted in HTML5 are commonly found in web content - this is not a substantive argument for retention
  • The hgroup is a new element for which the implementation in browsers is purely of a visual display nature i.e. default CSS. No user agent has implemented the meaning it is supposed to convey i.e. masking some content it contains in an outline and the changing of semantic information convoyed via accessibility APIs. So no disruption to the user will occur if the element is obsoleted. browser will continue to support the visual display. Disruption for authors is an argument that could be used for any obsoleted feature. - this is not a substantive argument for retention.

The hgroup element has not been generally well received by implementor's: in terms of its semantics and effect on the outline algorithm

  • zero implementations of the semantics, only implementations of default style. hgroup conveys no meaning to any user.
  • No browser has implemented the outline algorithm to display document outlines or change the semantics of H1 to H6 elements based on the outline algorithm.
  • No browser has implemented the effect of the hgroup element on the document outline (i.e. masking the subheading as defined in HTML5 section 4.4.7 or the in document effect i.e. to remove the heading level semantics of the individual heading elements within a hgroup element and assign the heading level semantics of the top level heading element within hgroup to the hgroup element as defined in HTML5 section 3.2.7.
  • The only rationale provided for the inclusion of hgroup in HTML5:
The point of <hgroup> is to hide the subtitle from the outlining algorithm.
  • One assistive technology (JAWS) has implemented the outline algorithm, it effects the representation of heading levels for page content. JAWS has not implemented the effect of hgroup on the outline or in page. From a recent discussion with a vendor working with freedom scientific (maker of JAWS) to implement HTML5 features, there are no plans to implement hgroup.

This is not a good enough reason to add an element to HTML5.

  • As currently specced it removes semantic information for some users.
    • For assistive technology users it removes any semantic difference between headings contained within a hgroup, it does not do this for other users:
      • For example, it does not homogenize the visual styles of the headings inside a hgroup, it is obvious to visual users that there is a semantic difference between headings inside a hgroup when they have different visual styling.
  • as it is not implemented and may well not be, encouraging authors to use it by giving it the status of being in the HTML5 spec is not helpful or useful to anyone.
  • current patterns in real world examples do not show a clear tendency for authors to mark up subheadings, subtitles, taglines and bylines with headings. The subline element does cover the real world use cases.
  • The real world examples show that authors do not as a general rule put a container element only around headings and subheadings, subtitles, taglines and bylines. they use a variety of markup structures, in most cases the grouping structure reflects the existing HTML5 header element.
  • One implementer (Firefox) had started to consider hgroup implementation, after discussion has decided to wait on the outcome of the HTML WG process and also indicated support for implementing subline if added to HTML5.

Why subline instead?

  • The subline element provides the same functionality as the one identified use case for hgroup i.e. it identifies content as a subheading which can be masked from a generated document outline.
  • It does not require a new markup pattern, that is not well represented as occuring in the wild.
  • It builds upon current markup patterns for subheadings, subtitles, taglines and bylines. The reasoning for the addition of other structural elements has cited the frequency of certain CSS class names. It is noted that these stats have not been used as a reason to include hgroup. Unfortunately the google stats cited do not provide enough data to analyse and infer aggregate usage of class names for subheadings, subtitles, taglines and bylines and do not provide any data on id names. But another study does provide useful data: From that study in Figure 33. Most frequently used classnames and Figure 34. Most frequently used ID-s data can be extracted which indicates that 'byline' is the 8th most used class name and 'subhead' is the 10th most used id value in the sampled pages. Which supports the utility of an element that maps on to such content containers in the wild.
  • It can be implemented to convey meaning via the user agent rather than take meaning away as hgroup does. Taking meaning away denies user agents such as AT that rely upon the accessibility representation of the content cannot choose what how they represent the user interface to the end user. The subline element does the opposite, it conveys semantic information provided by the author via use of the element which can then be represented to the user by the AT and preferences about how such information is presented can be offered to the end user. This is not possible with hgroup as defined.
  • As defined subline can be used now without the requirement for browser default CSS display implementation, but would benefit from it.
  • of the 19 examples provided in support of hgroup, the subline element can be used in every case, in many cases just by adding the subline element, without the need for changing the current coding patterns. This is not the case for hgroup which requires significant code changes in a number of instances.

Details

  • Remove the hgroup element from HTML5, remove the 52 instances of the text "hgroup" in the HTML5 specification.
  • Add details about hgroup under 11.2 Non-conforming features
hgroup - Use subline instead.
  • Add the subline element to HTML5. Replace current instances of the text 'hgroup' with 'subline' where appropriate.

Impact

Positive Effects

  • provide authors with a more flexible element to mark up exisiting content structures.
  • provide a clear semantic structure to convey differences in content to users.
  • covers hgroup use case + more.
  • does not encourage users to mark up taglines, bylines, subtitles etc as h1-h6 headings when in many cases the heading semantic is not a good fit.

Conformance Classes Changes

  • The use of hgroup will no longer be conforming.
  • The use of subline will be conforming.

Risks

  • authors may be confused by the removal of hgroup
  • exisitng instances of the hgroup element in the wild will need to removed in order for pages to be conforming.
  • current advice in tutorials and books will require modification.