Last modified: 2012-03-04 12:25:17 UTC
Because each section anchor is buried in a <p> before the section heading (ie. outside of its section), there is no way to use it in CSS to select the section heading or any following content. The current situation (from [[w:en:T-34]]): <p> <a name="References" id="References"></a> </p> <h2> <span class="editsection">[<a href="/w/index.php?title=T-34&action=edit&section=20" title="Edit section: References">edit</a>]</span> <span class="mw-headline">References</span> </h2> There is no way to use a CSS selector involving, #References to select the article's References heading or section, for example to apply a format to all References sections. A sensible arrangement would allow, e.g., the following simple code to work, without having to change the rendering in old browsers: #Notes + h2 + ul { [style for a list in any section entitled “Notes”] } Any of the following would allow this: * Remove the <p> from around the anchor -- since there is no contained text, it is effectively invisible anyway. Is there any disadvantage to this? * Apply the ID attribute to the heading instead of an anchor in front of it (and name, for Netscape 4, right?).
This was done at some point in the past three years...
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?
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.
There were concerns from r52963 about how it handles headings where the ID is manually specified.
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&action=edit&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&action=edit&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.
@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.
(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
