nicht angemeldet
Hi,
Abschicken sollte man den Driss schon, sonst kommt er nicht an, oder? ;-)
Wahsaga hat mir zwar die Hälfte bereits aus dem Mund genommen, aber trotzdem, dann war's nicht ganz vergeblich.
Wahsaga hat mich auf http://www.w3.org/TR/html4/appendix/notes.html#non-ascii-chars hingewiesen. Dies empfiehlt eine UTF-8-Kodierung von solchen Zeichen innerhalb von URIs. Weiß jemand, ob das auch in irgendeinem URI-Standard so ausdrücklich vorgeschrieben wird?
Ich habe mich in RFC 3986 noch nicht so ganz eingearbeitet (ich hätte doch ein 3/4 Jahr Zeit gehabt? Ja, ihr vielleicht ;-) aber laut Changelog hat sich diesbezüglich nichts geändert: alles außerhalb der Spezifikation im Anhang A muß entspr.codiert werden.
Ich bin zunächst davon ausgegangen, das man einfach
<a name="ö">..</a>
notieren kann (weil name CDATA ist usw., wie diskutiert) und dann mit
<a href="#%C3%B6">..</a>
darauf verweisen kann.
Das ist so nicht korrekt, wenn das name-Attribut eines Ankers als "Fragment Identifier" dient. Auch da gelten die URI üblichen Bestimmungen.
Ergo, wenn man
<a href="#%C3%B6">..</a>
verwendet, sollte man äquivalent
<a name="%C3%B6">..</a>
notieren.
Das verstehen alle genannten Browser, unabhängig von der Kodierung des Dokuments mit dem Anker und der Kodierung des Dokuments mit dem Link.
Ja, denn das ist ja auch aus o.a. Gründen korrekt, aber Du hast natürlich ganz Recht mit ...
Das ist natürlich keine große Erkenntnis, schließlich taucht hier nirgendwo mehr ein »ö« auf, sondern letztlich nur ASCII-Zeichen, die der Browser problemlos miteinander abgleichen kann, ohne irgendwelche De- und Transkodierungen vornehmen zu müssen.
... es ist nicht sehr verwunderlich, das es klappt.
Ich lese daraus, dass besondere Zeichen in Ankernamen extrem umständlich sind - wer kann schon UTF-8-kodierte, Prozent-maskierte Zeichen lesen oder schreiben? - und dass die besagte »Faustregel« gerechtfertigt ist. Oder hat sich ein Denkfehler eingeschlichen?
Nein, ich finde keinen.
Ich würde empfehlen sich auf keine Experimente einzulassen und die (ASCII-)Zeichen aus RFC 3986 (Anhang A) zur Nutzung empfehlen.
Dann gäbe es noch die Möglichkeit der ISO-8859-1-Kodierung:
<a name="ö">..</a>
<a href="#%F6">..</a>
Funktioniert oder auch nicht aus den gleichen Gründen wie bei dem UTF-8 Versuch weiter oben. Nur können Latin-1 wohl mehr Browser.
Ich frage mich, was ich in SELFHTML nun schreiben soll. Es geht unter anderem, ob name="ö" irgendeinen Sinn ergibt. MudGuard meinte, man müsste die Prozent-Maskierung anwenden, dann sind auch Links auf solche Anker korrekt (für name="bla#bla" und href="#bla%23bla" mag das ja gelten, ich habs nicht getestet, aber glaube es gerne).
Ich würde sagen, das name="bla#bla" nicht korrekt ist, da
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pct-encoded = "%" HEXDIG HEXDIG
fragment = *( pchar / "/" / "?" )
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Das ercheint mir eindeutig. Aber kann natürlich auch sein, das es nur mir so erscheint, lasse mich gerne vom Gegenteil überzeugen. Imerhin gehe ich vom Kontext aus (URI) und nicht von der DTD (CDATA). Die DTD von XHTML machts mit NMTOKEn und der Definition desselben auch nicht gerade einfacher.
Ich weiß nicht, ob es dem theoretisch zuzustimmen ist - folgt denn irgendein oben genanntes Verhalten einem bestimmten Standard?
Nein, natürlich nicht, wie kommst Du darauf? Dafür müßtest Du doch eigentlich schon lange genug dabei sein, dies bei keinem Browser einfach so zu vermuten ;-)
Ich habe die neueste Version des Abschnitts »Wahl eines geeigneten Ankernamens« im Bugtracker gepostet. Hat jetzt noch jemand Ergänzungen?
<a name="Ein ♥ für Kinder">
Finde ich aufgrund des '#' nicht korrekt, wenn es als Anker dienen soll. Und außerdem noch ein blödes Beispiel, da dort entweder CDATA oder NMTOKEN stehen muß aber kein PCDATA. Da wird nix geparsed.
Im Übrigen ist sowieso ziemliche Wichserei. Im Vergleich zu 8.0 steht künftig ein riesiger Haufen langweiliger und für Anfänger unverständlicher Theorie in dem Abschnitt. Vorher gab es nur eine verständliche Praxisempfehlung, die zugegebenermaßen eher empirisch und mit dem gesunden Menschenverstand als theoretisch begründet war.
Ja, die sollte da auch besser bleiben. Die trockene Theorie mag sich hinter einem Link verstecken.
Ich habe zwar selber auch über 30 Jahre gebraucht es zu lernen aber doch: ein wenig Pragmatismus tut hin und wieder ganz gut, er beruhigt die Nerven. Die alte Praxisempfehlung ist ja schließlich so falsch nicht.
Und außerdem: wenn's eine Referenz hätte werden wollen hieße es nicht SELFHTML sondern HTML-Referenz, oder? ;-)
so short
Christoph Zurnieden
MudGuard