Re: hgroup

On Tue, May 3, 2011 at 15:04, Steve Faulkner <faulkner.steve@gmail.com> wrote:
> Hi tantek,
> while I very much support your right as a working group member ask for a
> revert,
>
> I do not consider it your right to imply that I amongst others who consider
> hgroup to be a problem are

[retracted]

I'm not implying that about you Steve, and clearly such a description
is not helping to productively resolve/fix this issue and thus
retracted. My bad.


> "I believe all "how to write" HTML5 books provide
> documentation of how and when to use hgroup, and *know* that a few
> others "Introducing HTML5"
>
> bruce lawson co-author of "Introducing HTML5" asked for hgroup to be
> reviewed by the html wg[1][2][3]
>
> here is what he had to say:
> "As I travel and teach web devs about HTML5 semantics, I'm getting feedback
> and confusion about <hgroup> that gives me significant misgivings about
> the utlity and thus potential uptake of the element.
>
> People have difficulty grasping the meaning of an element with no meaning
> other than to preserve the outlining algorithm.

I've found that people have difficulty grasping the purpose/meaning of
any feature when provided without real world examples that demonstrate
its use, or just provided with another abstraction as a justification.

E.g. I have found the outlining algorithm as a whole confusing to web
authors/designers and have omitted teaching it in introductory HTML5
courses completely.

Instead, I've been teaching hgroup similarly to as Tab recently said
in email, purely for semantically marking up heading/subheading
clusters which I've found people having no difficulty grasping as soon
as you show them real world examples (books, newspaper articles).

It appears that Bruce and I have different anecdotal experiences with
teaching hgroup.

My advice (to anyone teaching HTML5) is the following: teach
declarative semantic markup based on real world examples, rather than
algorithms (outline or otherwise) or abstractions.


> Personally, I don't see people currently using h1+h2 for title and
> subtitle anyway (the usecase that hgroup serves)"

>From my experience it is an uncommon use case in general, yet common
particularly among books and newspapers (both on the web and off).


The larger issue is perhaps one of stability (sufficient utility) and
consistency.

1. Stability / utility
In my opinion/experience, keeping hgroup is both:
a) not doing harm
b) serving some semantic purpose for some (sufficient(?) # of) authors.

Good enough to keep it IMHO.

2. Consistency. I'd prefer to keep differences between the W3C HTML5
spec and the WHATWG HTML spec to a minimum. Obviously some differences
are going to occur / have occured, but every one of those adds cost
and confusion for web authors. I don't think any of the arguments made
to drop hgroup have provided sufficient justification to overcome
those costs, thus if the dropping proposal is not good enough for both
versions of the spec, it's not yet good enough to be considered.


Respectfully, I don't think "drop it until the working group makes a
decision" is a good justification either, as "dropping it" is a change
that should be *dependent* on the working group making a decision,
rather than precede it.


On Tue, May 3, 2011 at 15:09, Jens O. Meiert <jens@meiert.com> wrote:
>> I also speak from anecdotal positive personal experience having given
>> several HTML5 workshops and talks teaching/demonstrating use of
>> new HTML5 markup including <hgroup>, including mention/documentation
>> in a book[1]
>
> Respectfully, this rather sounds like conflict of interest than a
> well-reasoned disagreement to me.

Why is a positive example/anecdote a conflict of interest?

If you're worried about books seeming accurate / selling as a source
of a conflict of interest, note that most books also do a "second
edition" with updates/corrections etc. which has the opposite
motivation (more change).

Thus anyone can argue this point either way and it's pointless to
conjecture such a "conflict of interest".


> In general, we probably do well in ignoring, at least discounting, any
> mistakes authors may have made when broadcasting features of a
> specification that’s still in progress.

I'll strongly agree that it's better to fix the spec than have it be
"stuck" by any kind of legacy documentation or implementation. I have
no problems with errata to such documentation.

In addition, every HTML5 book I've read (e.g. those mentioned) have
provided strong caveats about both the spec as a whole and various
portions of the spec being in flux.

Thanks,

Tantek

Received on Wednesday, 4 May 2011 02:02:57 UTC