This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Is the lack of marking up subtitles/taglines in HTML 4 such a big problem, that we should at this stage introduce a solution - any solution - that clearly is not really liked? The decision that will be taken now will live on for many, many years to come. Thus my suggestion really is 3. Drop hgroup altogether and await patterns to emerge, research those and revisit this for HTML5.1 (or whatever the W3C will call the next frozen version.) No browser has yet implemented hgroup in any other way but add some defualt styling and bragging about it on their web sites. Thus this is not really costly for implementers.
See also bug 11731.
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: <hgroup> is in fact the result of awaiting patterns. The pattern is that people use <h1> and <h2> as heading and subheading respectively (without meaning heading and subsection). All <hgroup> does is wrap them up so they don't impact the outline algorithm. "Not really liked" isn't a technical argument, so that's not a reason to drop it. Having said that, I don't feel particularly strongly attached to having the <hgroup> element in the HTML5 spec. If you really want me to remove it, please reopen the bug and I'll take care of it.
Hi Ian, you wrote: > Having said that, I don't feel particularly strongly attached to having the > <hgroup> element in the HTML5 spec. If you really want me to remove it, please > reopen the bug and I'll take care of it. I really want the hgroup removed until the issue of its inclusion is decided by the HTML working group. (In reply to comment #2) > 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: > > <hgroup> is in fact the result of awaiting patterns. The pattern is that people > use <h1> and <h2> as heading and subheading respectively (without meaning > heading and subsection). All <hgroup> does is wrap them up so they don't impact > the outline algorithm. > > "Not really liked" isn't a technical argument, so that's not a reason to drop > it. > > Having said that, I don't feel particularly strongly attached to having the > <hgroup> element in the HTML5 spec. If you really want me to remove it, please > reopen the bug and I'll take care of it.
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: Accepted Change Description: see diff given below Rationale: I've removed it from the W3C spec.
Checked in as WHATWG revision r6052. Check-in comment: remove <hgroup> from the w3c spec by request of steven faulkner http://html5.org/tools/web-apps-tracker?from=6051&to=6052
Could you please explain exactly why <hgroup> has been dropped? There is no compelling reason provided here.
This type of change is frozen out at this time in HTML5 unless there's some group consensus. At least that's been my understanding of what the co-chairs have been saying for some time, now. I'm not fond of hgroup, but I'm less fond of arbitrary decisions made by an editor who seems to have poor impulse control.
"clearly not really liked" and "I really want it removed" do not seem like viable reasons to drop it in my eyes.
http://www.w3.org/html/wg/tracker/issues/164
(In reply to comment #8) > "clearly not really liked" and "I really want it removed" do not seem like > viable reasons to drop it in my eyes. Well, actually hgroup should not be added at first. So removing it just fixes the situation of adding new element without proper use-cases.
(In reply to comment #10) > (In reply to comment #8) > > "clearly not really liked" and "I really want it removed" do not seem like > > viable reasons to drop it in my eyes. > > Well, actually hgroup should not be added at first. So removing it just fixes > the situation of adding new element without proper use-cases. Then the time to have asked that hgroup be removed was in May, of 2009, when it was added, along with header. And where is the supposed functionality to replace this item? Last I heard, people didn't want hgroup but they wanted option b or c or some other thing. There needs to be stability in the group, not this reeling from arbitrary decision to arbitrary decision, with an occasional useful, or not, yank by the co-chairs just to remind everyone that, goodness, there are a lot of people dependent on a specification that's based on _some_ level of thoughtfulness--not whatever playful whimsy happens to strike group/editor from time to time. So I won't mention the four HTML5 books I've tech edited, each of which has covered hgroup. And how, based on one arbitrary little decision and seeming indifference from the co-chairs, they're all out of date before they even hit the street. And no, I don't want to hear about, "Oh, anything goes until Last Call (or CR) or whatever"... When you've had an element in the spec as long as hgroup has been in the spec (two years, this month), people have developed an expectation that it has passed through whatever gauntlet it needed to pass through, and they can safely presume that they can cover it in their books. I pushed back on elements in the spec that were added arbitrarily and without discussion and sound vetting, but I did so well over a year ago. Or more. Back before authors (web page and book) and designers and everyone else had become used to the idea of the elements. If the group had a discussion and determined that another option was better, and the group reached consensus on the other option, no one would fault the decision. OK, these things happen. But because the of an act of capriciousness?
The resolution for this bug should be FIXED. Read comment 4 for what to do if you disagree with the resolution.
Before we continue the farce and take this to tracker issue, I remember that the co-chairs set deadlines for significant (non-editorial) changes to the text. And if I remember correctly, we're after that deadline. Co-chairs, isn't there a process in place right now to ensure an orderly move to Last Call? Aren't there deadlines in place regarding just such an edit as this?
Wait a second, according to Steve Faulkner[1] this one is already covered under an issue, with a call for proposals. And there are several proposals. No decision was made. Isn't the procedure to have call for proposals, and then have a survey, followed by some kind of decision? Isn't there anything approaching a consistently applied procedure in place? [1] http://lists.w3.org/Archives/Public/public-html/2011May/0036.html
And just to ensure that the maximum level of chaos is maintained, from the WHATWG IRC <Hixie> aho: <hgroup> is still in html, just not in the w3c copy of html5. http://krijnhoetmer.nl/irc-logs/whatwg/20110504#l-49
When I opened this bug, I also submitted some research to bug 11731 and there was a discussion concerning hgroup and various alternatives on the mailing list. At that time nobody stepped into the discussion and said that opening a bug would violate protocol. When writing books about HTML5 authors should be aware that the spec is not stable and things might get moved around. I can't see the wisdom in keeping an idea that has flaws just because were too late into the process.
(In reply to comment #16) > When I opened this bug, I also submitted some research to bug 11731 and there > was a discussion concerning hgroup and various alternatives on the mailing > list. At that time nobody stepped into the discussion and said that opening a > bug would violate protocol. > > When writing books about HTML5 authors should be aware that the spec is not > stable and things might get moved around. > > I can't see the wisdom in keeping an idea that has flaws just because were too > late into the process. From what I remember of the discussion on the procedures, bugs would be automatically labeled LC comments. But this item has an issue number, there has been various suggestions submitted as replacement, a decision has not been made. More importantly, I believe this issue is a LC issue item, which means, I thought, that this would be discussed in Last Call. Does the HTML WG have a consistently procedure in place, or not?
Sorry, consistently "applied" procedure in place. As for the books--if the specification changes because of processes and procedures in place, then yeah, authors take that gamble. Note, though, that this hurts all the readers, too, so don't discount the negative impact of significant spec changes at this time in the process. Still, a logically arrived at and consistently applied change has to be accepted by everyone. But if the change is applied inconsistently, capriciously--more, in my opinion, to disrupt than form a consensus--than no, authors shouldn't have to pay the cost. Authors shouldn't have to pay the cost for immaturity. No one should.
(In reply to comment #18) > Sorry, consistently "applied" procedure in place. The relevant procedure is defined here: http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html Meanwhile any and all comments and posts that contain assertions as to capriciousness, immaturity, appeasement, armchair complainers, and the like might just as well be directed to the bit bucket as they have no place or relevance here.
(In reply to comment #19) > (In reply to comment #18) > > Sorry, consistently "applied" procedure in place. > > The relevant procedure is defined here: > > http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html > > Meanwhile any and all comments and posts that contain assertions as to > capriciousness, immaturity, appeasement, armchair complainers, and the like > might just as well be directed to the bit bucket as they have no place or > relevance here. So, according to this procedure, the change should be reverted while the issue is being resolved through the issue process. And since the deadline is past for pre-LC issues, this becomes a LC issue.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > Sorry, consistently "applied" procedure in place. > > > > The relevant procedure is defined here: > > > > http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html > > > > Meanwhile any and all comments and posts that contain assertions as to > > capriciousness, immaturity, appeasement, armchair complainers, and the like > > might just as well be directed to the bit bucket as they have no place or > > relevance here. > > So, according to this procedure, the change should be reverted while the issue > is being resolved through the issue process. > > And since the deadline is past for pre-LC issues, this becomes a LC issue. That could very well be the end result, but there is nothing automatic about that process. Meanwhile, Tab Atkins Jr. has taken the first constructive step towards making that happen: http://lists.w3.org/Archives/Public/public-html/2011May/0041.html
I thought that responding in the bug thread is also supposed to be constructive, because not everyone is part of the WG. Perhaps you need another list: constructive actions, filtered by person.
(In reply to comment #22) > I thought that responding in the bug thread is also supposed to be > constructive, because not everyone is part of the WG. > > Perhaps you need another list: constructive actions, filtered by person. The filtering criteria was described here: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11828#c19 Additionally, if there is not a single WG member that supports a revert request, the co-chairs are unlikely to give the request serious consideration.
(In reply to comment #23) > (In reply to comment #22) > > I thought that responding in the bug thread is also supposed to be > > constructive, because not everyone is part of the WG. > > > > Perhaps you need another list: constructive actions, filtered by person. > > The filtering criteria was described here: > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11828#c19 > > Additionally, if there is not a single WG member that supports a revert > request, the co-chairs are unlikely to give the request serious consideration. So what you're saying is there really is no consistent procedure in place. Good to know. Thanks.
Checked in as WHATWG revision r6064. Check-in comment: revert change per http://lists.w3.org/Archives/Public/public-html/2011May/0061.html http://html5.org/tools/web-apps-tracker?from=6063&to=6064
(In reply to comment #24) > > So what you're saying is there really is no consistent procedure in place. Consistent procedure is now documented here, with links to all of the revert requests to date: http://dev.w3.org/html5/status/revert-requests.html
Now the discussion is being held at HTML5 doctor. http://html5doctor.com/the-hgroup-hokey-cokey/comment-page-1/ I am making my arguments at http://html5doctor.com/the-hgroup-hokey-cokey/comment-page-1/#comment-14948 and http://html5doctor.com/the-hgroup-hokey-cokey/comment-page-1/#comment-14960 In short: The burden of proof does not rest with those of us calling for a temporary withdrawal but on anyone wanting to include hgroup. The fact that it was "in the spec" for some time basically just means everyone had bigger fish to fry. It is not until people actually start implementing it, that we will see how good an idea is, and Webkit's half hearted implementation is evidence that the current proposal is not working.
I started investigating the real world usage practices for marking up subtitles and tag lines. From the pages collected so far, there seems to be a tendency towards using h1/h2 and h1/p elements for these purposes. Some examples are surprisingly close in structure to the design of the hgroup element. http://wiki.whatwg.org/wiki/Hgroup_element If you find more examples of real world usage, please feel free to add them.
mass-move component to LC1