Last modified: 2011-01-05 15:58:54 UTC
Summary: create section links with id attributes in divs, allowing CSS formatting of divs. Currently, the beginning of a page section has this 1990s-style HTML: <p><a name="References" id="References"></a></p> <h2>References</h2> An improvement would be to remove the semantically-void paragraph, and enclose the entire section within a div. Then the div id, including standardized id's like "See also", "Notes", "References","External links", could be used to format the page using CSS, or to manipulate it using Javascript. <div id="References"> <h2>References</h2> . . . </div> For example, the list items in all pages' References sections could be formatted as a standard bibliography using the following in a style sheet: #References ul { list-style-type: none; list-style-image: none; padding-left: 0; margin-left: 1em; text-indent: -1em; } #References li { margin-bottom: 0.5em; } Or Javascript could be used to expand/collapse divs. See also Bug 1521: allow anchor name to be defined independent of section header text
Better semantic HTML for sections would also allow the section edit links to be formatted properly for all headings, levels h2 through h6. See Bug 4525: "Section edit links should be moved down .5em".
sorry if this does not belong here: At http://www.unicode.org/reports/tr9/#Directional_Formatting_Codes you can read: " ... All of these codes are limited to the current paragraph; thus their effects are terminated by a paragraph separator. ... " I assume it makes sense to preserve paragraph subdivisions of the page. I only mention this because the "improvement" is not using them (<p> ... </p>) any more.
The only paragraph I propose removing is the one which surrounds an empty anchor before each heading, and contains no text at all.
Bug 6104: Give all sections an HTML DIV with CSS CLASS and perhaps ID
From Brion, bug 6104 comment #1: > This isn't practical with current system; sections may split up > across table cells, etc. The div wrapper is therefore not going to realistically be implementable in the foreseeable future, except perhaps by someone cleverer than I. Any tag enclosing the header has to enclose the entire section, otherwise the divs will be invalidly nested, and we can't guarantee that. The <a name="References" id="References"></a> will stay until we're sure that really really nobody is using browsers that don't recognize id-based anchors. It doesn't hurt anything to use that instead of ids on some otherwise existing element. I don't know why the <p> is there, but I expect there's some reason.
In summary: everything that can be improved at the present time has been. Section wrapper is WONTFIX, would screw up XHTML validity. I would say changing the 1990s-style <a name...> is LATER, when really really no browser doesn't support id's and so there's really absolutely no cost in changing them, so I'll mark this as LATER.
> sections may split up across table cells, etc. What does that mean? A table may contain a heading? Is there a single example of an article like this in Wikipedia? The Wikitext parser allows this? This kind of tag soup is considered acceptable in an open-source web application in 2006? > Any tag enclosing the header has to enclose the entire section, otherwise the divs will be invalidly nested, and we can't guarantee that. Don't tags left open get closed at the end of the page body to maintain validity? Then just close them at the end of each section. > The <a name="References" id="References"></a> will stay until we're sure that really really nobody is using browsers that don't recognize id-based anchors. Where do we check the stats to see if someone still is? Which browser doesn't recognize <div id="References" name="References"></div> as an anchor? Is it critical that in-page anchors work for Netscape 3 users? Or does "until we're sure" really mean "who knows? let's not deal with it"? > I don't know why the <p> is there, but I expect there's some reason. Why do you expect that? Maybe it's there because it was implemented in nineteen-ninety-something, or out of plain ignorance. Easier not to deal with that one either? When will Wikimedia software graduate to browser technology of 1997? This is a disappointing "resolution".
(In reply to comment #7) > > sections may split up across table cells, etc. > > What does that mean? A table may contain a heading? Is there a single example of an article like this in Wikipedia? The > Wikitext parser allows this? This kind of tag soup is considered acceptable in an open-source web application in 2006? Why is it "tag soup" for a table to be sectioned with headers? Or, in a more general case, for header tags to be enclosed in some other kind of tag, say a div? > Don't tags left open get closed at the end of the page body to maintain validity? Then just close them at the end of each > section. Tags opened in the section, you mean? Okay, fine, I guess that might be possible, assuming someone wants to do it. Of course, tags opened in an nth-level section would only close when the next nth-level section starts, not when subsections start. And something would have to be done about tags intended to be wrapped around the entire page, as well, or those wrapped around just a section header (those should be included in the section). And the result would have to be carefully scrutinized to make sure nothing breaks. But it could be worth it, yes. > Where do we check the stats to see if someone still is? Which browser doesn't recognize <div id="References" > name="References"></div> as an anchor? Is it critical that in-page anchors work for Netscape 3 users? Or does "until > we're sure" really mean "who knows? let's not deal with it"? It's not critical that we support older browsers, but it's even less critical to make the HTML output look pretty. We're in compliance with *transitional* standards, and there would be no benefit from switching. > Why do you expect that? Maybe it's there because it was implemented in nineteen-ninety-something, or out of plain > ignorance. Easier not to deal with that one either? Because the person who designed Monobook, Gabriel Wicke, knows a lot more about browser support and things like that than I do. I've already tried to second-guess him once (bug 3582) and it turned out he was right (bug 6918). The skin was made in 2004, I think, or maybe 2003. If he were around, I would ask him, but apparently he's disappeared, so may as well leave it. It doesn't hurt anyone, there's no point in risking breakage by changing it. > When will Wikimedia software graduate to browser technology of 1997? This is a disappointing "resolution". Okay, bug 6104 is for section div. I'll repurpose this bug to deal specifically with the anchor style, and I'm maintaining resolution for the time being. Note <http://www.w3.org/TR/xhtml1/#C_8>: "Many existing HTML clients don't support the use of ID-type attributes in this way, so identical values may be supplied for both of these attributes to ensure maximum forward and backward compatibility (e.g., <a id="foo" name="foo">...</a>)."
I can see how elements could be wrapped around headings to format them, but I wonder if this is ever done in practice. I guess elements spanning multiple sections are valid HTML, but it makes no semantic sense for part of a table to be under one heading and part to be under another -- if this happened it would be very confusing for editors. I don't recall ever editing an article section and finding only the beginning or end of some block element in it. Most or all block elements should probably be closed before another heading of the same level. But I see that it may be a lot of work to track down all of the repercussions. Maybe the best way to find any real problems is to try it out and listen for the screams. I have also seen cases where a block is wrapped around the entire page, at least on users' discussion pages. Perhaps an unclosed block element before the first heading should be assumed to be meant to surround the entire page contents. It would be better if there were some way to format div#Content and div#bodyContent instead. Requires some more thought. > We're in compliance with *transitional* > standards, and there would be no benefit from switching. I'm not suggesting changing the XHTML version, just adhering to some sensible semantic authoring conventions. I think trans-section blocks are very rare, so this shouldn't break anything (fingers crossed). Thanks for the detailed response.
See also Bug 16190: Relate section anchors to section headings in HTML, describing a less drastic alternative.
This seems to have been done at some point in the last three years...
