Re: Rebuttal of dropHgroup CP (ISSUE-164)

(If you see this twice, my apologies. My mail client says it was sent, 
but it never showed up on the list.)

Look at the total sum of things this way:

1. We want a way to mark up subtitles.

2. Subtitles should not appear as headings in the document outline.

What solution is KISS?

a. Use headings and then hide them.

b. Do not use headings to begin with.


2011-11-06 11:13, Simon Pieters skrev:
 > 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>
 >

Even if the LEVEL is affected by sections, h1-h6 are still headings.

Using hgroup would alter the meaning in a more drastic way.

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

Yes, but the complexity of that algorithm would increase dramatically. 
My argument was that such an *extra* layer of complexity is bad.


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

Assuming one would like to select h2 *headings* it is unambiguous.
Assuming one would like to select second level *headings* it is not.

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

I could not explain the fact that hgroup is a very complex technique 
better myself

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

Is it really? I would very much like to see two scripts that produce 
outlines, one with and one without hgroup, side by side yo prove that point.

Also I would like to see 2 scripts that extract certain headers, one 
with and one without hgroup, to prove that statement.

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

At least dropping hgroup will make the performance somewhat better. 
Until we have tests we can not say for certain.

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

Yes, but without hgroup the job will be simpler.

-- cut---

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

And no specific suggestion was made. But it illustrates the fact that 
subtitles are complex in ordinary language and that some more research 
would be good before we decide on a solution.

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

My remark was the result of trying to write an UI (on paper) for hgroup. 
No matter how I did it, I could not get away from the fact that the 
intuitive way of working was to select the text for the subtitle and 
chose "set as subtitle", which in turn would trigger backstepping and 
wrapping of the selected text and the heading preceding it in hgroup.

Thus, the UI is totally disconnected from the markup it produces.

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

 From my experience with WYSIWYG editors I'd say "don't hold your breath..."

We already see hgroup being abused by authors who code by hand, e.g:
http://wiki.whatwg.org/wiki/Hgroup_element#Apple

Also, this perfectly illustrates the principle of complexity. Why should 
such detecting be necessary and when should it be triggered?

And what if a user then changes his or her mind again and CTRL+Z is 
invoked? The undo-history will also be more complex.

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

Once again, could the complexity of hgroup be better illustrated? This 
is not an argument in favor of hgroup!

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

Yes, sections are hard to teach. (I have not found a way to do it that I 
am satisfied with in a book I am writing.)

So why make it even more complicated?


The rebuttal also fails to address why hgroup is superior to the other 
patterns, e.g. this one:

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

That solution *is* backwards compatible - hgroup is not. Hint: HTML5 
design principles...

Since the p-element is semantically made a part of the header, I'd say 
it perfectly fits as a solutions for subtitles.



-- 
Lars Gunther
http://keryx.se/
http://twitter.com/itpastorn/
http://itpastorn.blogspot.com/

Received on Sunday, 6 November 2011 19:07:32 UTC