------------ Původní zpráva ------------
Od: Aryeh Gregor <Simetrical+wikilist(a)gmail.com>
Předmět: Re: [Wikitech-l] Anchors haven't id attribute
Datum: 28.12.2008 04:16:43
----------------------------------------
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.
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.