Rebuttal of dropHgroup CP (ISSUE-164)

Comments on http://www.w3.org/html/wg/wiki/ChangeProposals/dropHgroup

> Hgroup alters the meaning of already implemented elements based on  
> position.

h1-h6 have different meaning in different places even if hgroup were to be  
dropped. For instance, h2 in the following examples is top-level heading,  
second-level heading and third-level heading, respectively:

<body>
  <h2>foo</h2>
</body>

<body>
  <h1>...</h1>
  <h2>foo</h2>
</body>

<body>
  <h1>...</h1>
  <section>
   <h1>...</h1>
   <section>
    <h2>foo</h2>
   </section>
  </section>
</body>

> 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

These should all implement the outline algorithm if they want to work  
correctly, even if hgroup is dropped.

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

Assuming this wants to select all second-level headings, it is wrong even  
without hgroup (see above).

> 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")

This is also wrong (if we ignore the fact that h2 might not be a  
second-level heading, hgroup's rank is determined by its highest ranked  
child heading, not its first child).

> Complexity always comes with an increased risk for bugs.

The outline algorithm is still on the same order of complexity even if  
hgroup is dropped.

> 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!

Removing hgroup will not change the performance characteristics of the  
outline algorithm substantially.

> 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.

They must be updated to handle sectioning elements anyway.

> 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!

Yes, this is certainly a con for hgroup. However, this is a temporary  
problem and not a serious one, I think (some people use the h1+h2 pattern  
for subtitle so already have a wrong outline).

> Also, detecting proper hgroup support will be virtually impossible, even  
> when implemented

You can't detect support for the outline algorithm even if hgroup is  
dropped (so you can't know if you can use sectioning elements and h1  
safely). However, I don't see what you would do differently even if you  
could detect support. Certainly rewriting the DOM to use different heading  
elements is going to be a perf killer if anything. Instead, if you know  
that support for the outline algorithm is not universal enough yet, you  
just use heading elements in a way that gives an acceptable outline in  
legacy UAs.

> 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"

I think using different markup for the two use cases would be highly  
confusing (not to mention the permathreads about which markup to use for a  
given case).

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

I don't see why the workflow would need to be different compared to a  
different element/markup pattern for subtitles.

> 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:

It's also not hard to imagine that the WYSIWYG editor detects that there's  
only one heading in hgroup and cleans up the markup.

> Imagine somebody writing a script that assumes that last-child heading  
> elements inside hgroup are always subtitles?

Such a script would already be broken since the last child is not  
guaranteed to be the not-highest-ranked heading in hgroup even if there  
are multiple headings.

> Teachability concerns

These concerns may very well be valid. It may also apply to headings and  
sections in general.

-- 
Simon Pieters
Opera Software

Received on Sunday, 6 November 2011 10:12:00 UTC