2008/12/27 Danny B. Wikipedia.Danny.B@email.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.