https://bugzilla.wikimedia.org/show_bug.cgi?id=16190
--- Comment #8 from Happy-melon <[email protected]> 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 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 -- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
