This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html Section: http://www.whatwg.org/specs/web-apps/current-work/#outlines Comment: <section> is not associated with the conceptual section it creates Posted from: 81.234.240.242 by philip@foolip.org User agent: Opera/9.80 (X11; Linux i686; U; en) Presto/2.8.115 Version/11.10
I extended Geoffrey's <http://hg.gsnedders.com/anolis2/file/0ae85731c3ae/src/lib/processes/outliner.py> to also keep track of the node associations that the spec mentions (code available if anyone wants it). Using that, I tried splitting the following document into sections as defined by the outlining algorithm: <!doctype html> <head><title></title></head> <body> <section id="main"> <h1>Main</h1> Introduction <section id="first"> <h1>First</h1> Foofoo <b>bold</b> </section> <section id="second"> <h1>Second</h1> Barbar <i>italic</i> </section> </section> </body> </html> The resulting list of conceptual sections are these: Section created for outlinee <body>. Associated nodes: <body> <section id=main> </section> </body> Section created for outlinee <section id=main>. Associated nodes: <h1>Main</h1> Introduction <section id=first> </section> <section id=second> </section> Section created for outlinee <section id=first>. Associated nodes: <h1>First</h1> Foofoo <b>bold</b> Section created for outlinee <section id=second>. Associated nodes: <h1>Second</h1> Barbar <i>italic</i> What I consider a bug here is that the <section> elements aren't associated with the section they create, rather they are associated with their parent elements.
Apart from being weird, it's also inconsistent, because <body> is associated with the section it creates, and if <section> isn't used <h1> elements are also associated with the elements they create. To be honest, it's not clear to me what the point of the associations are, but it was fun to play with and seems buggy.
The problem is the same for other sectioning content: article, aside, nav
I never thought about associating the sectioning elements with sections... I figured it was clear that the section element was related to the section it created. :-) Fixed. The use case here, FWIW, is allowing a UA to report the "current section title" at any point. The idea is that a UA can now unambiguously determine which heading element applies to any other element in the DOM. 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: Concurred with reporter's comments.
Checked in as WHATWG revision r6092. Check-in comment: Associate sectioning elements with their sections, in case anyone actually tries to use this algorithm as written even for sections. http://html5.org/tools/web-apps-tracker?from=6091&to=6092
mass-moved component to LC1