2008/12/27 Danny B. <Wikipedia.Danny.B(a)email.cz>cz>:
*sigh*
Why do we have to hunt for some other solution when we have fully working, fully valid
and fully intuitive one?
Because:
1) Our previous behavior arguably violated the XHTML 1 specification
by allowing name attributes to begin with nonletters. Please don't
ignore this argument because you think it's wrong. I think you're
wrong on this issue too, but I don't just ignore your opinion when
discussing what the software that we *both* develop should do. Note
"arguably" in the first sentence here -- your opinion counts as much
as mine.
2) It's not arguable at all that the XHTML 1 specification strongly
recommends that <a> elements with a name attribute also have an id
attribute. In fact, section 4.10 states: "In order to ensure that
XHTML 1.0 documents are well-structured XML documents, XHTML 1.0
documents MUST use the id attribute when defining fragment identifiers
on the elements listed above [including <a>]."
I'm not saying these reasons outweigh the reasons against, but those
are the reasons it was done. In particular, I don't think I've seen
an argument from you against (2).
Old version was used for many years. It was fully
valid
Could you *please* stop pretending that a debate doesn't even exist
here? It's obnoxious and uncivil, and you keep on doing it.
First major problem is, that this change is breaking
millions of existing links to sections. Links used on pages on wikis, links used on
external sites, links in people's bookmarks, in emails, forum threads etc. Well, OK,
let's discount all external stuff, since we don't have any influence on it, but we
still have millions of links left on our own wikis which won't work anymore since
r45109.
First of all, all auto-generated internal links (in TOCs) will
automatically switch to the new format. Second of all, it should be
one extra line of code to fix up all manually-created internal links
as well, so that the x is automatically added as part of the encoding
process. (I didn't find where this needed to be done at a quick
glance.) So we're only talking about external links here.
This is a one-time cost and I don't think it's a big problem -- at
worst, a few users will end up on the wrong part of the page. It
should be pointed out that this will affect *all* section links on
non-Latin wikis (since they get encoded to begin with dots and then
need to start with a letter), but again, only as a one-time cost, and
only external links (links from external sites or links using external
link syntax), and it will still get viewers to almost the right place.
The other major problem is, that since this point
further the anchor links are no longer intuitive - we are now pushing people to constantly
think about prepending x when creating anchor links. No more simple copy pasting of the
headline.
As a side effect we are now adding unnecessary work to people from non-latin wikis by
pushing them to always switch to latin keyboard, or to click on edittools or whatever just
to get the one "x" character in editbox to create the anchor link.
Again, not an issue if internal links are fixed to work correctly. I
didn't think about that aspect, but it should be very simple to fix
(I'd do it now except I'm going to bed).
It seems to me that there are only weak reasons in favor (following
recommended best practice with no practical effect) and only weak
reasons against (small one-time transition cost -- unless you're
correct that there will be longer-term costs, in which case please
clarify why you think this). Normally I would say that standards
compliance by itself (as opposed to standards compliance that brings
concrete benefit) is worth small one-time costs, although not large
enough one-time costs and probably not even fairly small recurring
costs. So as it stands, without further arguments, I'd still be
weakly in favor of keeping the current state of trunk, of course with
the fix for anchors on internal links.