--- Comment #8 from Happy-melon <happy-me...@live.com> 2011-01-05 21:09:43 UTC
(In reply to comment #7)
> 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
> 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
> 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: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- 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