happy.melon.wiki wrote:

This was done at some point in the past three years...

michael wrote:

Not really. The id attribute is now in a span nested inside the heading element. Still no help in using CSS to style a particular heading.

For example, I can't use <code>h2#References {}</code>, or any other selector, to style the text of an article's reference heading, because the #References ID belongs to a meaningless span INSIDE the heading.

This is a symptom of [[wikt:divitis]] and classitis. Resolving this bug means adopting best-practice semantic HTML. Reopening.

You could use h2 span#References {...}

You wouldn't be able to style the h2 directly, but do you really need to?

michael wrote:

span#References only styles (part of) the inline text inside the heading element. It can't change the heading block's attributes such as margins, padding, background-colour, position, etc.

do you really need to?

The point of semantic HTML is to simplify the code while giving a designer control over ALL of the page. So a creative person can do something you and I haven't imagined yet. Without Javascript hacks.

happy.melon.wiki wrote:

There were concerns from r52963 about how it handles headings where the ID is manually specified.

ayg wrote:

Specifically, if

<h2>Foo</h2>

gets translated to something involving

<h2 id="Foo">Foo</h2>

then what do you suggest we do with

<h2 id="Bar">Foo</h2>

as wikitext input? Currently, explicitly-specified <h#> is treated pretty much the same as wikitext headings. One solution would be to make the <h#> contain only the actual title, so instead of

<h2><span class="editsection">[<a href="/w/index.php?title=T-34&amp;action=edit&amp;section=20" title="Edit section: References">edit</a>]</span> <span class="mw-headline" id="References">References</span></h2>

do

<div id="References" class="mw-headline"><span class="editsection">[<a href="/w/index.php?title=T-34&amp;action=edit&amp;section=20" title="Edit section: References">edit</a>]</span> <h2>References</h2></div>

or something. But that would have to be deployed carefully to not break existing content.

michael wrote:

@Happy-melon:

It looks like those were concerns with that implementation, not with resolving this issue. r52963 didn't allow for a manually-typed ID to override a generated one, but rather created a second ID attribute.

But even with the r52963 solution, if an editor NEEDS to add a second ID, why not use an <a> or other element after the heading? (And if she needs to add a third one, it must be done that way anyway.) I didn't see any evidence that an editor actually needs to manually specify an ID, just the theoretical desire not to change current behaviour.

The purpose of the heading ID is to identify the heading element, not just a span of text.

@Aryeh Gregor:

Why not just change id="Foo" to id="Bar" in the rare case when an editor specifies it? With the current situation, wikitext is inadequate and I'd have to type HTML for every heading if I want my CSS or Javascript to access them.

A surrounding <div> or HTML5 <section> would be better still, but much more complicated to implement. Even without it, HTML5 clearly defines the scope of a section, based on the *headings*, so a CSS designer or Javascript can use this, *if* the headings are identified.

happy.melon.wiki wrote:

(In reply to comment #7)

@Happy-melon:

It looks like those were concerns with that implementation, not with resolving
this issue. r52963 didn't allow for a manually-typed ID to override a generated
one, but rather created a second ID attribute.

Indeed; but that's the reason why the move to attach the id to the <h2> wasn't completed then.

But even with the r52963 solution, if an editor NEEDS to add a second ID, why
not use an <a> or other element after the heading? (And if she needs to add a
third one, it must be done that way anyway.) I didn't see any evidence that an
editor actually needs to manually specify an ID, just the theoretical desire
not to change current behaviour.

It was more that people couldn't be bothered to dig out whether it was reasonable and practical to change the current behaviour. Passing Linker::makeHeader() an array of attributes rather than a string would go a long way towards increasing our flexibility here, but no one did the necessary work.

The purpose of the heading ID is to identify the heading element, not just a
span of text.

Indeed.

@Aryeh Gregor:

Why not just change id="Foo" to id="Bar" in the rare case when an editor
specifies it?

Because the code generating the ToC isn't aware that that change has been made, and so will output a broken link. Both IDs need to be included *somewhere* around the header.

A surrounding <div> or HTML5 <section> would be better still, but much more
complicated to implement.

That's bug 6104