W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > January 2011

[Bug 11731] Replace <hgroup> element with a <subhead> element used as the child of the <hx> element

From: <bugzilla@jessica.w3.org>
Date: Sun, 30 Jan 2011 19:34:37 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Pjd2j-0002Tl-4m@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11731

Lars Gunther <webmaster@keryx.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |webmaster@keryx.se

--- Comment #5 from Lars Gunther <webmaster@keryx.se> 2011-01-30 19:34:35 UTC ---
Educator perspective:

I have made some research into what pattern is most obvious to people having
little experience in HTML, but are in the learning process = my students. A
made this research with 8 students, all who have studied web design and markup
for about 150 hours.

The purpose was to see what pattern was most intuitive to understand and would
lead to the least amount of misunderstanding and bad usage. The methodology was
as follows:

1. I explained the rationale, i.e. that subtitles/taglines should not be
considered individual headers, and be hidden in outline algorithms.

1b. I explained that such outline algorithms have (at least) two use cases and
pointed to Wikipedia generating outlines for longer articles (intra page
navigation) and explained how users of AT (especially screen readers) use
headers to skim through pages and jump between sections.

I got the impression that the use cases were understood.

2. Trying my very best to be neutral, I presented the following alternatives to
them:

a. hgroup with h1+h2 as the spec stands today.

b. h1+h2 but no hgroup, saying that and h2 immediately following an h1 is
changed because of its position.

c. hgroup with h1 + sibling "subhead" (of any name)

d. h1 with "subhead" child element (this bug).

3. I asked the following questions:
a. Does any pattern make immediate sense to you, i-e. would you intuitively
understand it even if it had not been explained?
b. Could you envision a situation where the markup you've created got destroyed
because the pattern is too fragile? (It was hard to explain this neutrally as a
test giver, since I had to give examples.)

Half of the group of students gravitated towards example c, which they thought
was the clearest. When asked if we really need TWO new tags to describe what
after all is a very simple semantic case, they back peddled, opting for a
combination of b and c, i.e. a h1 element immediately followed by a subhead
element.

1/4 of the group immediately preferred pattern d (this bug). 1/4 could not
decide what pattern they preferred.

Having h2 change its value depending on being inside hgroup (a) or position (b)
was generally confusing. No student liked this idea. It was considered an extra
threshold that would make HTML harder to learn.

When the discussion shifted to consideration b (is the pattern robust or
fragile), every student preferred alternative d (this bug). The only objection
was a gut feeling that hn-elements should not have children at all, which was
abandoned during the follow up conversation. This gut feeling was identified as
a driving factor for students choosing alternative c or the b+c combination in
the first place, making at least 2 students change their "vote" in favor of
(d).

What I can say with certainty from my research is that elements should not
alter their meaning depending on position. An h2 should not be something else
just because it is trailing an h1 or is put inside an hgroup. This does confuse
learners. Of the two, using hgroup is the least confusing option, since it is
explicit.

I can also say with certainty, that my students all agreed that some kind of
wrapping was needed (c or d), otherwise the markup would be fragile. Especially
the students who considered using WYSIWYG editors, or providing such options to
their customers. (I have students who build CMSs in PHP providing that through
CKeditor.) Having subhead elements as siblings to the real header would
deteriorate when customers start to use such tools.

No student could immediately envision an UI or mechanism that would alleviate
such concerns. Having to educate customers was considered something they did
not look forward to doing.

Thus, if the subhead is not a child of the header, it must be wrapped. In the
end there was agreement that option (d) made most sense, followed by option
(c).

But the question remains, do we really wish to add TWO elements in order to
mark up subheaders/taglines? That consideration would disqualify option (c),
leaving option (d) as the winner.

However, since this confirms my own opinion, it could easily be argued that I
was not neutral in conducting the research. I have not seen anyone else even
attempting to do a similar thing, though, and my findings should not be totally
dismissed just because they echo my opinion. It could also be that my opinion
was well informed, since i know what is teachable and what is hard to teach
from my now quite extensive experience.

Thus, I would be the first to admit that this research is woefully incomplete.
Thus, my primary suggestion is still the one I gave in bug 11828 - drop hgroup
from the spec for now and wait until more research has been done.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 30 January 2011 19:34:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 30 January 2011 19:34:44 GMT