ChangeProposals/dropHgroup

From HTML WG Wiki
< ChangeProposals
Revision as of 09:26, 29 June 2011 by Lgunther (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Proposal: Drop hgroup and investigate alternatives

Summary hgroup should be dropped from the spec. Another element or solution may be added to HTML in the future or the use case for subtitles may be satisfied by other means.

Rationale: What is the risks with hgroup?

Complexity costs must be investigated, not only current usage patterns. Hgrop is a result of the latter. Uninvestigated complexities include the following:

Semantic change of current elements

Hgroup alters the meaning of already implemented elements based on position. Thus it effectively introduces 6 new elements:

  • hgroup
  • h2-h6 that is the non-first child of hgroup

This means that headings become ambiguous. If placed outside of hgroup or as the first child of hgroup they are normal headings. But otherwise they are something else.

While this semantic construct may be relatively easy understood by web designers working on html code it is a nightmare for developers who make tools to parse that markup and make something useful of it. This includes:

  • JavaScripts that make document outlines client side
  • Code written in PHP, Java, Python, Perl, Ruby, etc that make document outlines server side
  • Browsers that should present document outlines to assistive technology, like screen readers

It might also affect the AT programs directly, depending on how the browser makers implement hgroup.

Currently this simple code is unambiguous: document.querySelectorAll("h2")

However, when hgroup has been introduced it will need to be rewritten into something very complex, like document.querySelectorAll(":not(hgroup) > h2, hgroup > h2:first-child")

For scripts that do not have access to advanced querySelectors, as in older browsers or server side, there must be a lot of special casing instead.

Update 2011-06-29: The factor is made even worse by sectioning roots. This extra layer of complexity will make parsing of hgroup absurdly difficult.

Complexity always comes with an increased risk for bugs.

Performance

For long documents this complexity also mean that scripts will execute slower. And the longer the document, the more advantageous it is to add an outline!

Backwards incompatibility

There already exist scripts, both client and server side, that generate outlines. All of these scripts must be updated for hgroup to work, as well as browsers. Thus hgroup violates one of the key design principles of HTML5: Backwards compatibility.

Authors that add hgroup to their markup today, and during the foreseeable future will not reap any benefits at all. They will actually be fooled into using a pattern that has no intended effect, but instead generates unintended effects. The presumed subtitles will still be part of the outline!

Also, detecting proper hgroup support will be virtually impossible, even when implemented, since JavaScript can't access AT apis. Capability testing is a cornerstone of modern web development and it can't be done. That by itself should be enough of an argument to kill this element!

No real semantic investigation

There are in fact two extremes on a scale when it comes to subtitles:

  • True subtitles that are actually part of the title: "Dr Strangelove or how I stopped worrying and started to love the bomb"
  • Tag lines: "Alien - In space no one can hear you scream"

In the first case the subtitle is very tightly bonded to the first part of the title, being part of the title, but in the second case it is quite independent.

These two use cases probably needs investigation. Deciding on hgroup now will shortcut such investigation.

WYSIWYG nightmares

Markup generated in WYSIWYG environments will probably be messed up with hgroup. First of all it affects workflow:

  1. Author writes main part of the title
  2. User writes the subtitle
  3. User does what to make these be wrapped by hgroup?
    1. Select all text and chose "wrap"? Very unintuitive!
    2. Selects the subtitle and sets a "mark as subtitle" button, which in turn triggers a script that will wrap both elements with hgroup tags? Very fragile indeed. What if the author hits that button at the wrong place?

And what if a user decides that the subtitle should be dropped? It is not hard to imagine many pages getting the following code snippets all over them:

<hgroup>
  <h1 />
</hgroup>

Imagine somebody writing a script that assumes that last-child heading elements inside hgroup are always subtitles? The code above will break that script!

Having a separate subtitle element would be way more intuitive and orders of magnitude less error prone.

Teachability concerns

What is the difference between hgroup and header? Expect that question on every seminar in the future!

We are already seeing confusion. One web developer wrote a comment that if hgroup gets dropped he will use <div class="hgroup">, which begs the question why? He wrote that comment to defend hgroup, but the div clearly does not hide the subtitle from the outline. He had misunderstood the whole point of hgroup, but considered himself knowledgeable enough to participate in a discussion about the value of the element.

Other comments say that they are using hgroup for CSS and want to keep it for that reason - which is totally beside the point of it's intended purpose. And there exist several solutions to CSS issues that are even easier and more performant.

Classroom experiments made by Lars Gunther have indicated that students that are new to HTML find hgroup confusing, compared to other patterns.

Some conference speakers and authors feel confident that they can explain hgroup, but the question is really should they have to? Or could some other solution be more easily explained?

Investigation is needed.

Details

Drop hgroup (for now)

Cost of dropping hgroup

Currently there is no meaningful implementation of hgroup in any browser and no work is going on in either Webkit or Gecko, the 2 rendering engines that are being developed in public.

It will take a very small patch to drop what little code there is for hgroup in Webkit. It will take a little bit more to drop hgroup from the validator.

Conformance Classes Changes

  • The use of hgroup will no longer be conforming.

Risks

  • Authors may be confused by the removal of hgroup
  • Existing 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.

(However, these risks are not high compared to the risks of keeping hgroup!)

Other solutions to investigate

There may be more than these.

Subline

Drawback: It is not advisable to add a new element at this stage to HTML5.

The proposed alternative solution will also have some of the problems that hgroup have, at least if headings are allowed as child elements inside subline-elements.

A modified subline proposal that outlaws the usage of headings inside the subline element, i.e. a pure subline element would be very preferable to hgroup according to most of the reasons listed above.

Using Header and Paragraph

<header>
  <h1 />
  <p />
</header>

This pattern effectively promotes the paragraph to be a subtitle, since it is a part of the header. In contrast hgroup demotes headers.

This pattern is backwards compatible, adds zero cost to browser vendors and is probably easily scripted.

While there might be some use cases this pattern will not satisfy, this would actually be something worth investigating before anything else is added to the spec.