- From: <bugzilla@jessica.w3.org>
- Date: Fri, 25 Feb 2011 07:08:08 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11731 Ian 'Hixie' Hickson <ian@hixie.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |ian@hixie.ch Resolution| |WONTFIX --- Comment #6 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-02-25 07:08:06 UTC --- (In reply to comment #0) > * It is slightly less verbose Minimally so, given that most people would probably end up using a <span> around the main heading in order to get easier styling control. > * It is easier to style with CSS. <hgroup> requires detailed knowledge of the > markup structure whereas with <subhead> and a :heading(n) selector, one can do: > > :heading(n) {/*rules for the heading*/} > :heading(n) > subhead {/*special rules for the subheading*/} As opposed to: h1 { ... } hgroup h2 { ... } ...this doesn't seem simpler. Also, I think it would probably end up being really: h1 span.main { ... } h1 subheading { ... } ...vs: hgroup h1 { ... } hgroup h2 { ... } ...which is at least a wash, if not more confusing, IMHO. > * It is semantically less confusing. There is no ambiguity about whether the > <hgroup> is the heading element or the child <hx>. That means it is more > obvious what a :heading selector will select, and more obvious how > accessibility APIs will map the various elements. I don't think this confusion exists with anyone except the spec weenies amongst us, and the spec weenies will find the answer unambiguously in the spec. > * It arguably has better fallback semantically (if not visually, although that > is easier to fix using CSS; see above). A legacy UA will consider the whole > thing to be one heading rather than several headings with a > possibly-nonsensical parent-child relationship as in the <hgroup> case. I'm not sure the semantic fallback really matters. <hgroup> has significantly better graceful degradation in real use cases, even without CSS. > * It preserves the invariant that all <hx> elements represent headings, which > may make certain tools easier to write. I also think it makes the outline > algorithm slightly easier to implement. The outline algorithm doesn't even mention <hgroup>, so I'm not sure it would make much difference at all. The only complexity <hgroup> adds is in getting text out when you need just a single string, and that is pretty minimal complexity, at least compared to the outline algorithm. > * It seems harder to use incorrectly. The only obvious mistake that one could > make would be to use <subhead> outside a <hx> element which would be relatively > harmless (semantics of <div>). Given how <h1> is misused, I don't see any reason to think that misuse of any proposal here would end up being appreciably worse. > The main disadvantages I can think of are: > > * It makes it slightly harder to determine the text of a heading (need to walk > the tree skipping <subhead> elements). On the other hand simple properties like > .textContent should be considered inadequate anyway since alt text should be > considered part of the heading text. It makes generic algorithms for grabbing text inadequate too. In fact, I'd say it basically means you have the same complexity problem as <hgroup> mentioned earlier. > * Doesn't support the use case of multiple subheadings of different weights. > This seems like a very minor use case that could be addressed in the future if > it is significant. The spec itself in certain incarnations has three levels of headings, so wouldn't be able to use this (but does use <hgroup>, at least when not published by the W3C). (In reply to comment #5) > Educator perspective: Thanks for this, it's quite interesting information. Please continue to provide these insights! > 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? > 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. This is interesting, because it contradicts what we see in the wild: what people tend to do when they have subheadings (assuming they use anything other than <div>s) is use an <h1> immediately followed by an <h2>. > What I can say with certainty from my research is that elements should not > alter their meaning depending on position. Agreed, though I don't think the meaning of <hx> change with <hgroup>, at least not at the level Web developers would look at it. They're still headings with different "weights" (intentionally not using a term of art like "rank"). <hgroup> just groups them together, like <form> does to a bunch of <input>s, or <datalist>, <select>, and <optgroup> do (in various ways) to a bunch of <option>s. > 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. Option (a) presumably also addresses that need. > 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. Well we can all empathise with that. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I don't really see what problem the proposals here solve. <hgroup> is unambiguous, easy to style, has great graceful degradation, paves an existing cowpath (one in particular widely used by the W3C's own documents), is not especially verbose, not especially complicated... and it's documented in tutorials, and used by some newer sites. It's not something that comes up all the time, so it's not something that must be understood by new authors immediately, but when they do see it it's pretty self-explanatory, and easily searched for ("hgroup" is not a common word like "subhead"). We discussed the new sectioning elements years ago, shook out the obvious problems, and now it's long past time to stop bikeshedding these decisions and just move on. -- 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 Friday, 25 February 2011 07:08:11 UTC