This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Very often in working with complex web sites, I had to reuse parts of content in multiple pages. If that content has its own heading structure, chances are that including that content to another page will break the heading structure. For example, if the main page has displays searches for two different major categories of the site and on submitting a search, it goes to a separate page for the results. That result page most likely contains the same form to do another search if the results don't match what the user is looking for. On the home page, the heading would have to be an h2 or lower under the Home Page h1 but on it's own page, it should be an h1. Another example is a complex policy or standard document that is displayed both a multiple document set or a long single document. Having a dynamic way of dealing with headings would allow to maintain only one instance (the multiple set one) and have the long single one refrence the pieces. With the new 'section' element, there would be no need for an numbered heading. If section were mandatory and not implied anymore, there could be a single element to deal with all headings. As it is the case with fieldset, the first element of a section could be a heading element defining the title of that section. I understand it would be a bit more CSS (instead of h3 it would be section section section heading {}) but it would create a more compliant structure for complex data.
This is already allowed in HTML5. Sectioning elements reset the heading hierarchy, so you can start over again from <h1>. For example, the following two snippets generate the same outline structure: <h1>Top level heading</h1> <p>text</p> <h2>Second-level heading</h1> <p>text</p> ... <h1>Top level heading</h1> <p>text</p> <section> <h1>Second-level heading</h1> <p>text</p> </section>
(In reply to comment #1) > This is already allowed in HTML5. Sectioning elements reset the heading > hierarchy, so you can start over again from <h1>. > > For example, the following two snippets generate the same outline structure: > > <h1>Top level heading</h1> > <p>text</p> > <h2>Second-level heading</h1> > <p>text</p> > > ... > > <h1>Top level heading</h1> > <p>text</p> > <section> > <h1>Second-level heading</h1> > <p>text</p> > </section> Depending on the level of separation of document, you would end up with a lot of h1 which would become very difficult to manage. Headings would be much easier if there were no number associated to it...and beside, if sectioning allows what you mentioned, then the number don't mean anything anymore since it relies not on the number but on the section.
Sure, one could introduce an <h> element to do exactly the job <h1> is doing there. But why would that be any better?
(In reply to comment #3) > Sure, one could introduce an <h> element to do exactly the job <h1> is doing > there. But why would that be any better? Because if the section allow this kind of behavior: <h1>Top level heading</h1> <p>text</p> <section> <h1>Second-level heading</h1> <p>text</p> </section> Then what is the meaning of h1.....It's using nesting to determine the hierarchy so the number is irrelevant...
The meaning is context-dependent, just like <h> would be. Again, the only reason <h1> is being used instead of <h> is to avoid creating a new tag when we have a perfectly good tag for this already. Yes, the "1" is irrelevant; one could have use <hx> or <hy> or <h9> (but not any of the existing h2-h6, since those mean something different at toplevel from what we want the "heading" tag to mean.
(In reply to comment #5) > The meaning is context-dependent, just like <h> would be. > > Again, the only reason <h1> is being used instead of <h> is to avoid creating a > new tag when we have a perfectly good tag for this already. Yes, the "1" is > irrelevant; one could have use <hx> or <hy> or <h9> (but not any of the > existing h2-h6, since those mean something different at toplevel from what we > want the "heading" tag to mean. As it happens, h2-h6 are fine too per spec.
(In reply to comment #5) > The meaning is context-dependent, just like <h> would be. > > Again, the only reason <h1> is being used instead of <h> is to avoid creating a > new tag when we have a perfectly good tag for this already. Yes, the "1" is > irrelevant; one could have use <hx> or <hy> or <h9> (but not any of the > existing h2-h6, since those mean something different at toplevel from what we > want the "heading" tag to mean. With the current way, the structure is ambiguous....h1 to h6 are ambiguous since at any time you can insert an h1 for which its purpose is undefined. Is the h1 the continuity of the same document (but uses an h1 because it exists as its own entity) or is it a new context. I understand your point but keeping tags just because it use to work a certain way....that's not a major version (HTML 5) more like a minor version (HTML 4.2). Its probably too late now but it would be worth considering deprecating the h1-to in favor of a universal h
Why close it...there is a discussion going on it.
(In reply to comment #8) > Why close it...there is a discussion going on it. Because your original bug (wanting a way to embed headings without having to worry about the heading level earlier in the document) is addressed in HTML5 already. WORKSFORME is the appropriate status. If you have another bug, such as wanting HTML5 to deprecate <h1>-<h6> and replace them with <h>, please file it as a separate bug. (It'll be a duplicate, of course, as this precise request has been made before and rejected.)
(In reply to comment #9) > (In reply to comment #8) > > Why close it...there is a discussion going on it. > > Because your original bug (wanting a way to embed headings without having to > worry about the heading level earlier in the document) is addressed in HTML5 > already. WORKSFORME is the appropriate status. > > If you have another bug, such as wanting HTML5 to deprecate <h1>-<h6> and > replace them with <h>, please file it as a separate bug. (It'll be a > duplicate, of course, as this precise request has been made before and > rejected.) It has only partially addressed...it's still very ambiguous. What's the point of having collaboration tool different and valid ideas are bullied out...
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > Why close it...there is a discussion going on it. > > > > Because your original bug (wanting a way to embed headings without having to > > worry about the heading level earlier in the document) is addressed in HTML5 > > already. WORKSFORME is the appropriate status. > > > > If you have another bug, such as wanting HTML5 to deprecate <h1>-<h6> and > > replace them with <h>, please file it as a separate bug. (It'll be a > > duplicate, of course, as this precise request has been made before and > > rejected.) > > It has only partially addressed...it's still very ambiguous. > > What's the point of having collaboration tool different and valid ideas are > bullied out... Your bug was addressed. It described a valid problem, but one that has already been fixed. Thus, it received a WORKSFORME. If you have a separate bug about the ambiguity of using <h1> in the manner currently described by the spec, please file it as a separate bug.
(In reply to comment #10) > It has only partially addressed...it's still very ambiguous. It is not ambiguous. The HTML sectioning algorithm is stated precisely and explicitly in the spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#outlines If you believe any part of that section of the spec is ambiguous, please say exactly which part. It tells you exactly what the semantics of all the heading elements are. (Of course, it's hard to follow, but you can't demand something that's both completely precise *and* easy to follow.)
mass-move component to LC1