michael wrote:

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".

gangleri wrote:

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.

michael wrote:

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

ayg wrote:

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.

ayg wrote:

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.

michael wrote:

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".

ayg wrote:

(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>)."

michael wrote:

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.

michael wrote:

See also Bug 16190: Relate section anchors to section headings in HTML, describing a less drastic alternative.

happy.melon.wiki wrote:

This seems to have been done at some point in the last three years...