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

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.

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.