Last modified: 2012-07-30 12:57:37 UTC
The headline id should belong to <h#> tag and not to inner <span>. It is semantically more correct and it is more flexible for CSS constructions which depend on given id (the current way actually disallows styling of full headlines on the basis of their id) thus more usable with an influence on accessibility as well.
Why is this tagged accessibility?
*** Bug 33415 has been marked as a duplicate of this bug. ***
Not sure if this is proper HTML: <h2><span class="editsection">...</span> <span id="License" class="mw-headline">License</span></h2> Correct would be to add the id to the h2-tga instead: <h2 id="License"><span class="editsection">...</span> <span class="mw-headline">License</span></h2> It becomes a problem when you use the CSS3 pseudo selector :target to style the background: *:target { background-color:#fffddf !important } http://i.imgur.com/I7uwr.png
Removing 1.19wmf1 milestone blocker. Not a high priority for 1.19 completion
Tim, Danny and I discussed this today at the Berlin Hackathon: - Current HTML: <h#(wikitext attribs)> (edit section link) <span class="mw-headline" id="(anchor based on heading title)">(heading title)</span> </h#> - Use cases: 1) Ability to jump to the headline from the hashtag. When the skin has a large edit section link or positioned it as a block 2) Ability to style the currently hash-targetted heading with CSS ":target" 3) For screen readers and semantics, the edit section link should not be part of the <h#>. - Conclusions: * We can't put the ID on the <h#>, because wikitext pages can (and do!) contain html tags with an ID already (e.g. <h3 id="awesome">The Awesome Delivery of Resources</h3>). See Linker::makeHeadline * We shouldn't put an empty <span id="..></span> (or div) _before_ the <h#>. Although that solves the jump issue, it still doesn't allow to easily select the header from the :target selector. * We can't put a span around the <h#>. Block element should not be in an inline element. * We *can* put an unstyled <div> around (not before) the <h#>. That solves all three use cases. CSS styling is possible with ":target h# { .. };". Also we should then add the "mw-headline" class to the <h#>. Potentially it can have a class already, but an element can have multiple classes. Note that in this case the attributes have to be merged. With code 'class="y" title="z" class="x"' the last one overrides the earlier. - Proposed HTML: <div id="(anchor based on heading title)"> (edit section link) <h#(wikitext attribs) class="mw-headline"> (heading title) </h#> </div> - Proposed HTML (alternative): <div class="mw-headline" id="(anchor based on heading title)"> (edit section link) <h#(wikitext attribs)> (heading title) </h#> </div>
The motivating application for this request is to support a template on cs.wikibooks.org which will be styled differently depending on whether it is immediately after a heading. There is a proposal for the typical placement to be changed, but they don't want to use a different template name, rather they want to use some sort of sibling selector in site CSS to detect which placement policy is in use in a given instance.
(In reply to comment #5) > [..] > 3) For screen readers and semantics, the edit section link should not be part > of the <h#>. > [..] case 3 is also reported as bug 11555.
I propose we implement the alternative Krinkle suggested in comment 5. Might be most disruptive, but I think it will fit our future usecases better. It's more likely we want to identify the entire block of a heading, then a specific heading elements inside the heading block.
(In reply to comment #8) > I propose we implement the alternative Krinkle suggested in comment 5. Might be > most disruptive, but I think it will fit our future usecases better. It's more > likely we want to identify the entire block of a heading, then a specific > heading elements inside the heading block. Perhaps... though I should say. Semantically what we really want when we think of an id is not the header but the whole section it encompass. ie: If it weren't for the issues with doing so we should have a <section> element with the id on it instead.
