Page MenuHomePhabricator

The headline id should belong to <h#> tag and not to inner <span>
Open, MediumPublic

Description

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.


Version: 1.18.x
Severity: enhancement

Details

Reference
bz31932

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:53 PM
bzimport set Reference to bz31932.

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.
  • Proposal 1:
<div id="(anchor based on heading title)">
  (edit section link)
<h#(wikitext attribs) class="mw-headline">
  (heading title)
</h#>
</div>
  • Proposed 2 (alternative)
<div class="mw-headline" id="(anchor based on heading title)">
  (edit section link)
<h#(wikitext attribs)>
  (heading title)
</h#>
</div>
  • Proposed 3 (Figure out a way to keep track of the custom ID, or decide not to support a custom ID on headings)
  (edit section link)
<h#(wikitext attribs) id="(anchor based on title or custom)">
  (heading title)
</h#>
  • Proposed 4 (Allow custom ID, but move into span for anchor purpose only)
  (edit section link)
<h#(wikitext attribs) id="(anchor based on title or custom)">
  <span id="(optional custom ID)"></span>(heading title)
</h#>

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)

[..]

  1. For screen readers and semantics, the edit section link should not be part

of the <h#>.
[..]

case 3 is also reported as bug 11555 (T13555).

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.

Krinkle lowered the priority of this task from Medium to Lowest.
Danny_B raised the priority of this task from Lowest to Medium.May 28 2016, 3:08 PM
Danny_B added a project: Accessibility.