> ------------ Původní zpráva ------------ > Od: Aryeh Gregor <[email protected]> > Předmět: Re: [Wikitech-l] Anchors haven't id attribute > Datum: 28.12.2008 04:16:43 > ---------------------------------------- > 2008/12/27 Danny B. <[email protected]>: > > *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.
Not true. XHTML 1 was NOT violated. Name attributes in XHTML1 CAN begin with any allowed char (letter, num and some set of punctation). They DO NOT have to begin with letter. Name attributes in XHTML1 are of NMTOKEN which is defined that way. You did not provide any evidence of violating of XHTML. On the other hand I've provided the link to specification confirming what I said. Also W3C validator results confirm my words. > 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). Strong recommendation does not yet mean it's a must. It is recommended, not required nor enforced. Id is recommended because of well-structure which means to keep unique ids. Name attributes are not required to be unique thus could cause wrong results if two or more names are same - user agent wouldn't know to which one to roll, so it would roll to the first occurence. > > 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. Could you *please* stop to turn this discussion into personal area? Thank you. Discuss the topic, not the persons in discussion, please. It doesn't help to anything and raises the temperature unreasonably. Thank you. I am not pretending anything. The statement above is fully true. > > 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. I was not speaking about TOC. That is obvious that since it's automatically generated,it will be correct. What you mean by "automatically added as part of the encoding process"? Does that mean that if I'll write [[#foo]] it will automatically create the #xfoo anchor? If yes, then you're again simply adding load of work and thinking to users. Since this point further they could not simply copy'n'paste the anchor from address bar to wikitext, because it would prepend another x. You are pushing them to think about if the anchor link should or should not start with "x". Wiki should be simple. In case you think about having the linker automatically decide if to prepend it or not depending on if the [[#......]] text starts with x, let me remind, that random headlines can start with "x" themselves, thus it would confuse the algorithm. > 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. Few users? Are Wikipedias used by few users? You are again not saying the true - section links, if in "name" attribute, DO NOT have to start with letter. You made pages invalid by adding the id attribute with the same value copied from name attribute even if it shouldn't have been done because it's against the specification which requires the letter first. If I'll write [[Foo#ěščřž]] link on wiki, it is converted to Foo#.C4.9B.C5.A1.C4.8D.C5.99.C5.BE and WORKS properly (takes me to such section) and it IS valid. Same on non-latin wikis. (I'm speaking about the old version before all these discussed changes.) > > 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). Re the internal links see above. Wiki should be simple and intuitive and copypastable. You'll push people to think more than they need. You will make the anchor links be without any reasonable and necessary reason different than the real section names are. Thus you'll lower down the intuitivity and create the work for people who will have to correct the things they'd normally wrote correctly if it was intuitive. You'll cause headaches to those, who are not so familiar with wiki and just blindly do what they've been taught and it suddenly won't work. You are going to break millions of links. Is it worth it when it is not repairing of any bug, misfunctionality, invalidity or stuff like that? What _concrete_ indisputable and - first of all - necessary benefits it brings over the old version? I haven't heard any yet. But I know about bunch of negatives. > 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. Of course that arguments of the opponents are always weak ;-) However, even when you brought much less evidence than me, I am not saying the same about yours. Re the standard compliance - we do comply the standards. (I should actually say we did, because you broke it with adding of invalid ids). I don't think that re-teaching hundreds of thousands of wiki users how anchor links are going to be treated is "small one-time cost". Besides I also hardly doubt the possible transition will be so smooth as you are presenting here. There are always unexpectable problems. Do we need them? Don't we have the _real_ bugs and misfunctionalities to fix instead of worthless playing on the place where it is not necessary because it works correctly? Do we need to cause unnecessary additional work on software which wouldn't be needed if we kept the old fully working version? Anyway, I'd suggest you to present the full transition plan which could be discussed rather than doing changes in software that either causes massive invalidity of pages or breaks links or does any other evil. That would help this discussion a lot, thank you. By the way, I still think, that _if_ the truth about attributes was on your side, Validator and Tidy were fixed in this way ages ago. But they still confirm my words. I am really very very disappointed that there are problems artifically being created on places where they weren't. Everything was working properly and intuitively. Somebody decided to change it and more and more problems pop-up since then. I'd like to remind two useful principles - KISS and "if it works, don't touch it". It worked, now it does not. It used to be simple, now we have to think about dozens of consequencies. Also I'm a bit confused about the approach to backward compatibility - on one hand we keep in code ancient constructions and structures just for case somebody would have some tool using them, on the other hand we are going to break millions of links. One of the major web principles says Cool URIs don't change. And what about tools? There are indeed tools working with anchor links. So we are going to break them all now? Kind regards Danny B. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
