"target" doch in XHTML1.1 integriert?!
thewho88
- html
Schönen Nachmittag!
Ich mache mich gerade schlau über XHTML 1.1 Modularisierung und wie sich das Target-Modul, das mir laut W3C (http://www.edition-w3c.de/TR/2001/REC-xhtml-modularization-20010410/#s_targetmodule) das "target"-Attribut in Links wieder zurückbringt, integrieren lässt. Deshalb habe ich mir die DTD (http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd), auf die in meinem Header verwiesen wird heruntergeladen und wollte diese entsprechend ergänzen.
Als ich die Datei dann allerdings genauer unter die Lupe nahm, fand ich in Zeile 292ff folgende Passage:
<!-- Target Attribute Module .................................... -->
<!ENTITY % xhtml-target.module "INCLUDE" >
<![%xhtml-target.module;[
<!ENTITY % xhtml-target.mod
PUBLIC "-//W3C//ELEMENTS XHTML Target 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-target-1.mod" >
%xhtml-target.mod;]]>
Ist "target" jetzt doch wieder standardmäßig verfügbar? Ich kenn mich langsam überhaupt nimmer aus. Kann mich hier wer aufklären?
mfg
thewho88
Nachsatz:
Der W3C-Validator (http://validator.w3.org/) gibt mir immer eine Fehlermeldung (Attribut nicht unterstützt) aus, wenn ich das target-Attribut im XHTML1.1-DOCTYPE verwende.
Hallo,
Ist "target" jetzt doch wieder standardmäßig verfügbar?
Noch nicht.
http://www.w3.org/TR/xhtml11/ verweist auf Working Draft (Arbeitsentwurf, sozusagen ein Prototyp) zur Second Edition von XHTML 1.1. Die bleibende URI davon ist http://www.w3.org/TR/2007/WD-xhtml11-20070216/.
http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd verweist also auf die DTD-Implementierung dieses Working Drafts. Die bleibende URI davon ist http://www.w3.org/TR/2007/WD-xhtml11-20070216/DTD/xhtml11.dtd.
Dies ist wie gesagt der aktuelle Working Draft, der ist seiner Zeit schon voraus. Die letzte maßgebliche XHTML-1.1-Recommendation findet man unter http://www.w3.org/TR/2001/REC-xhtml11-20010531/ und die zugehörige DTD ist dauerhaft unter http://www.w3.org/TR/2001/REC-xhtml11-20010531/DTD/xhtml11.dtd adressierbar.
Wenn man sich die jetzt anschaut, sieht man, dass das Target-Modul erst im Working Draft hinzugekommen ist. Wenn die Second Edition irgendwann fertig ist und das Target-Modul drinbleibt, ist es auch offiziell Teil von XHTML 1.1.
Sprich, wenn du XHTML 1.1 gemäß der Recommendation schreibst, kannst du target nicht verwenden, wenn du XHTML 1.1 gemäß dem Working Draft schreibst, kannst du target verwenden.
Der W3C-Validator (http://validator.w3.org/) gibt mir immer eine Fehlermeldung (Attribut nicht unterstützt) aus, wenn ich das target-Attribut im XHTML1.1-DOCTYPE verwende.
Der W3C-Validator lügt. (Ich liebe es, diesen Satz zu sagen. ;))
Selbst wenn man die URI der neuen DTD des Working Drafts angibt, dann erlaubt er target nicht. Sobald der Validator <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "[irgendwas]"> sieht, dann lädt er sich nicht die tatsächlich angegebene DTD herunter, sondern sucht in seiner internen DTS-Datenbank nach dem Public-Identifier. Und der Validator hat unter diesem Public-Identifier halt die DTD aus der Recommendation gespeichert, nicht aus dem Working Draft (ist ja eigentlich auch sinnig).
Man kann dem W3C-Validator aber explizit sagen, dass er die DTD aus dem Working Draft benutzen soll:
<?xml version="1.0" ?>
<!DOCTYPE html SYSTEM "http://www.w3.org/TR/2007/WD-xhtml11-20070216/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de">
<head><title>Beispiel</title></head>
<body><p><a href="bla" target="bla">bla</a></p>
</body>
</html>
Siehe da, dieses Dokument befindet er für valide.
Strenggenommen ist es auch valide, wenn man diesen DOCTYPE angibt:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Würde ein validierender XML-Parser wirklich die DTD von der angegebenen Adresse beziehen, müsste er target-Attribute auch als valide anerkennen. Aber das macht der W3C-Validator nicht.
Mathias
Herzlichen Dank für die umfangreiche Erklärung!
mfg
thewho88
Hello out there!
Wenn man sich die jetzt anschaut, sieht man, dass das Target-Modul erst im Working Draft hinzugekommen ist. Wenn die Second Edition irgendwann fertig ist und das Target-Modul drinbleibt, ist es auch offiziell Teil von XHTML 1.1.
Da drängt sich mir die Frage auf, warum dieser nutzerfeindliche Unsinn wieder Einzug in die Spec halten soll.
Man kann dem W3C-Validator aber explizit sagen, dass er die DTD aus dem Working Draft benutzen soll: […]
Siehe da, dieses Dokument befindet er für valide.
Eine andere Möglichkeit, vom Validator grünes Licht zu bekommen:
<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ATTLIST a
target CDATA #IMPLIED
>
]>
[code lang=html]<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de">
<head>
<title>Beispiel</title>
</head>
<body>
<p><a href="bla" target="bla">bla</a></p>
</body>
</html>
~~~[/code]
See ya up the road,
Gunnar
--
„Und [dieses Forum] soll […] auch ein Fachforum bleiben und kein Psychologieforum werden.“ ([Kirsten Evers](https://forum.selfhtml.org/?t=158750&m=1033264))
Hallo,
Da drängt sich mir die Frage auf, warum dieser nutzerfeindliche Unsinn wieder Einzug in die Spec halten soll.
Ich nehme an, aus dem selben Grund, aus dem es auch in HTML 5 enthalten sein wird: Die hohe Verbreitung. Oder um möglichst alles modularisiert zu haben.
Finde ich einerseits unsinnvoll, weil sich das ganze auch mit JavaScript und anscheinend auch irgendwann mit CSS realisieren lassen soll und außerdem nicht wirklich was mit einem Dokument zu tun hat. Doch andererseits ist das target-Attribut die einzige Variante, die von Browsern zuverlässig blockiert werden kann (im Gegensatz zur open-Methode in JS).
Eine andere Möglichkeit, vom Validator grünes Licht zu bekommen:
Wer's braucht?
Gruß;
...] unsinnvoll, weil sich das ganze auch mit JavaScript und anscheinend auch irgendwann mit CSS realisieren lassen soll [...]
Ich wollte es eigtl vermeiden, hier eine Grundsatzdiskussion loszutreten, aber meinetwegen: Mir erscheint es _durchaus_ sinnvoll, dass sich bei einer Portalseite eines Vereines die Links zu den Mitgliedsbetrieben in einem eigenen Fenster öffnen.
Die JS-Funktion window.open(...) öffnet meiner Erfahrung nach eine neues Fenster. In Zeiten von Tabbed Browsing möchte ich den User doch nicht mit PopUps überfluten!
Wenn mir jemand eine Möglichkeit nennen kann, wie ich eine target-Alternative implementiere, welche die selbe Browserreaktion wie target="_blank" hervorruft, bin ich gerne gewillt, dies zu tun und auf das Attribut zu verzichten. ;)
mfg
thewho88
Servus,
Mir erscheint es _durchaus_ sinnvoll […]
Richtig, _dir_ erscheint es sinnvoll - anderen aber, z.B. mir, nicht. Deshalb bringt jeder (halbwegs) moderne Browser die Funktion mit, Links in einem neuen Fenster/Tab zu öffnen. Und wie (bzw. wo) ich URLs aufrufen will, weiss der Webseiten-Autor nicht.
Die JS-Funktion window.open(...) öffnet meiner Erfahrung nach eine neues Fenster […]
[…] welche die selbe Browserreaktion wie target="_blank" hervorruft […]
Was bei diesen beiden Dingen passiert, hängt von den Browser-Einstellungen ab. Bei mir passiert in beiden Fällen daselbe wie bei "normalen" Links (ausser window.open hat Größenangaben): Die Seite wird im aktuellen Tab geladen; Wenn ich ein neues Tab will klicke ich mit der mittleren Maustaste, nicht mit der linken ;)
Im Endeffekt ist es IMHO nicht Sache des Autors sondern Sache des Users, wie dieser Links öffnen will. Leider haben viele keine Ahnung, wie man einen Browser bedient :(
Gruss
Patrick
»»Wenn ich ein neues Tab will klicke ich mit der mittleren Maustaste, nicht mit der linken ;)
[...] Leider haben viele keine Ahnung, wie man einen Browser bedient :(
DAS sehe ich auch so. Ich könnt bei jedem externen Link nen Hilfetext einblenden, was der User drücken soll, wenn er das in nem eigenen Tab/Fenster darstellen will. Aber ich glaub, dann fragt mich mein Auftraggeber, ob ich noch alle Tassen im Schrank hab... ;)
mfg
thewho88
Hallo,
DAS sehe ich auch so. Ich könnt bei jedem externen Link nen Hilfetext einblenden, was der User drücken soll, wenn er das in nem eigenen Tab/Fenster darstellen will.
Das ganze geht auch unaufdringlicher. Kennzeichne externe Verweise im Quelltext (eine Klasse, oder das vorgeschlagene rel="external" bieten sich an) und verarbeite das mit CSS oder JavaScript (oder beidem). Es reicht schon eine kleine Unterscheidung, wie es z.B. auch auf der Wikipedia gemacht wird. Da hat sich auch noch keiner beschwert, dass kein neues Fenster aufgemacht wird.
Gruß;
Das ganze geht auch unaufdringlicher. Kennzeichne externe Verweise im Quelltext (eine Klasse, oder das vorgeschlagene rel="external" bieten sich an) und verarbeite das mit CSS oder JavaScript (oder beidem).
Sehr interessant, die Methode war mir bis jetzt nicht bekannt.
Meinst du die Verarbeitung so in etwa? (Hab ich in nem andern Forum gefunden und erscheint durchaus schlüssig)
function externalLinks() {
if (!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName("a");
for (var i=0; i<anchors.length; i++) {
var anchor = anchors[i];
if (anchor.getAttribute("href") &&
anchor.getAttribute("rel") == "external")
anchor.target = "_blank";
}
}
mfg
thewho88
Hallo,
Meinst du die Verarbeitung so in etwa? (Hab ich in nem andern Forum gefunden und erscheint durchaus schlüssig)
Der Ansatz ist schon richtig.
Ich würde aber, wie gesagt, ein für den Benuter erkennbares Merkmal einfügen, dass die Unterscheidung interner/externer Verweis ermöglicht.
Gruß;
Hallo,
Ich wollte es eigtl vermeiden, hier eine Grundsatzdiskussion loszutreten
Dann tu es nicht ;) Ich habe ja Nachteile von beiden Methoden genannt (wobei ich mir bei einem nicht mehr sicher bin, siehe unten).
Mir erscheint es _durchaus_ sinnvoll, dass sich bei einer Portalseite eines Vereines die Links zu den Mitgliedsbetrieben in einem eigenen Fenster öffnen.
Benutzer besucht Webseite. Benutzer klickt Link.
a) Neue Seite öffnet sich im selben Fenster, ergo Benutzer glücklich.
b) Neue Seite öffnet neues Fenster. Benutzer braucht alte Seite nicht und schließt sie. Später möchte er doch gerne nochmal die alte Seite besuchen, kann aber nicht, weil die Zurückfunktion des Browsers beeinträchtigt wurde (* ja, ich weis, dass das nicht die einzige Methode ist).
Die JS-Funktion window.open(...) öffnet meiner Erfahrung nach eine neues Fenster. In Zeiten von Tabbed Browsing möchte ich den User doch nicht mit PopUps überfluten!
Meine 4 Browser (Safari3, Firefox2, IE7 und Opera9) behandeln window.open() mit _blank identisch zum target-Attribut. Außer Firefox ist keiner der Browser speziell eingestellt.
IE7 und Opera öffnen lediglich einen neuen Tab. Safari ein neues Fenster, aber hier konnte ich auch überhauptkeine Einstellung dazu finden.. Im Firefox wird beides wie gewünscht im selben Tab geöffnet. Scheint, als hätte sich da einiges getan, seit wir das letzte Mal getestet haben ;)
Gruß;