--- Comment #8 from Happy-melon <> 2011-01-05 21:09:43 UTC 
(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

> 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? 

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

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.

Wikibugs-l mailing list

Reply via email to