<link> nicht verlinkt
Gunnar Bittersmann
- browser
- html
Ich lasse ein <link rel="foo" href="…"/>
-Element im Viewport anzeigen:
head { display: block }
head > * { display: none }
head [rel="foo"] { display: inline }
head [rel="foo"]::before { content: "Link" }
Funktioniert bestens in Firefox: „Link“ wird angezeigt und ist anclickbar. (Damit er auch per Tastatur funktioniert, bedarf es allerdings noch tabindex="0"
.)
Nicht so in anderen Browsern: Es wird zwar „Link“ angezeigt, ist aber kein Link.
Muss man da jetzt wirklich mit JavaScript rangehen und einen entweder einen Eventhandler registrieren oder für den Link ein a
-Element ins DOM hängen?
LLAP 🖖
Lieber Gunnar,
Ich lasse ein
<link rel="foo" href="…"/>
-Element im Viewport anzeigen:
warum? Das head-Element ist für Meta-Daten und nicht Inhaltsdaten. Wenn Du einen anklickbaren Verweis willst, dann ist das kein Meta-Datum, sondern ein Teil des Inhalts, der foglich in das body-Element gehört. Also ein passendes <a>.
Dass der FF den <head> anzeigt, finde ich grenzwertig, denn dann müsste er ja auch die darin enthaltenen Kindknoten anzeigen, und das sollte für reichlich Verwirrung sorgen. Klar, kann man das ebenso per CSS steuern - aber wozu soll das überhaupt ermöglicht werden?
Es gab doch mal die Überlegung, ob die logischen Beziehungen, die über <link> hergestellt werden können, von Browsern auf Wunsch des Anwenders in geeigneter Form angezeigt werden können sollen, und wie man als Autor auf die Darstellung Einfluss nehmen können soll. Offensichtlich ist diese Idee am mangelnden Support durch die Browserhersteller längst gestorben.
Ja, ich bin der Meinung, dass Du mit einem geeigneten JavaScript-Ansatz ein vom <link> abgeleitetes <a> im <body> erzeugen solltest.
Liebe Grüße,
Felix Riesterer.
@@Felix Riesterer
warum? Das head-Element ist für Meta-Daten und nicht Inhaltsdaten. Wenn Du einen anklickbaren Verweis willst, dann ist das kein Meta-Datum, sondern ein Teil des Inhalts
Nein, in meinem Fall nicht. Die Beziehung zur anderen Ressource gehört nicht zum Inhalt, sondern ist eine Metainformation. Diese soll aber für den Nutzer trotzdem als anclickbarer Link dargestellt werden.
Dass der FF den <head> anzeigt, finde ich grenzwertig
Nö, das ist normal, wenn man ihn mit head { display: block }
darum bittet. Und das machen alle Browser so. Schließlich ist head
auch nur ein Element wie jedes andere. Dass es normalerweise nicht angezeigt wird liegt daran, dass head { display: none }
im Browserstylesheet steht.
denn dann müsste er ja auch die darin enthaltenen Kindknoten anzeigen
Ja. (Von leeren Elementen wie meta
und link
ist allerdings nichts zu sehen.)
Aber nicht, wenn man ihn mit head > * { display: none }
darum bittet, das nicht zu tun.
aber wozu soll das überhaupt ermöglicht werden?
Um im head
vorhandene Metainformation darzustellen ohne sie nochmals zu duplizieren.
LLAP 🖖
@@,
Um im
head
vorhandene Metainformation darzustellen ohne sie nochmals zu duplizieren.
Und wieder zeigt sich der tiefere Sinn einer zentralen Konfiguration ;)
MfG
@@pl
Und wieder zeigt sich der tiefere Sinn einer zentralen Konfiguration ;)
Und wieder zeigt sich der tiefere Unsinn eines am Problem vorbeigehenden In-den-Vordergrund-Spielens einer zentralen Konfiguration. ¯\(ツ)/¯
LLAP 🖖
Hallo Gunnar Bittersmann,
denn dann müsste er ja auch die darin enthaltenen Kindknoten anzeigen
Ja. (Von leeren Elementen wie
meta
undlink
ist allerdings nichts zu sehen.)
Auch von title
nicht. Dito script
, style
, template
und noscript
. Das noscript
-Element wird auch unabhängig von head {display:block}
dargestellt.
Allerdings wird der Inhalt von <fantasie>Fantasie-Element</fantasie>
dargestellt.
Aber nicht, wenn man ihn mit
head > * { display: none }
darum bittet, das nicht zu tun.
Diese Bitte kannst du dir sparen, falls du keine Fantasie-Elemente verwendest.
aber wozu soll das überhaupt ermöglicht werden?
Um im
head
vorhandene Metainformation darzustellen ohne sie nochmals zu duplizieren.
Auch ein Link-Element innerhalb body wird nur im FF anklickbar. Laut spec ist link ja auch nicht interaktiv. Imho verhalten sich die anderen Browser also richtig.
Bis demnächst
Matthias
@@Matthias Apsel
Ja. (Von leeren Elementen wie
meta
undlink
ist allerdings nichts zu sehen.)Auch von
title
nicht. Ditoscript
,style
,template
[…]
Huch, ist das neu (oder mit Perwohl gewaschen)? Mir war so, als müsste man die Kinder alle explizit auf display: none
setzen. Meine Erinnerung kann trügen. Aber ja, eine entsprechende Regel ist nun schon im Browserstyelsheet.
[…] und
noscript
. Dasnoscript
-Element wird auch unabhängig vonhead {display:block}
dargestellt.
Na was denn nun? ;-)
Allerdings wird der Inhalt von
<fantasie>Fantasie-Element</fantasie>
dargestellt.
Um spec-konform zu sein, müsste im Elementbezeichner ein '-' vorkommen: <fanta-sie>
.
Auch ein Link-Element innerhalb body wird nur im FF anklickbar. Laut spec ist link ja auch nicht interaktiv. Imho verhalten sich die anderen Browser also richtig.
Ah, da wären die Tickets (erstmal) nicht gegen die Browser zu erstellen, sondern gegen die Spec.
LLAP 🖖
Hallo Gunnar Bittersmann,
[…] und
noscript
. Dasnoscript
-Element wird auch unabhängig vonhead {display:block}
dargestellt.Na was denn nun? ;-)
Der Inhalt eines noscript
-Elements im head
wird dargestellt, falls JS deaktiviert ist, unabhängig vom Wert der display
-Eigenschaft des head
-Elements.
Besser? ;-)
Bis demnächst
Matthias
@@Matthias Apsel
Besser? ;-)
Ja. ;-)
Zusammenfassend kann man sagen: Einige Kinder von head
werden per Browserstylesheet auf display: none
gesetzt, andere nicht.
Wenn man also head { display: block }
setzt, tut man gut daran, erstmal alle Kinder head > * { display: none }
zu setzen und nur dasjenige/diejenigen auf display: block
(bzw. inline
, …), was man angezeigt bekommen möchte.
LLAP 🖖
@@Gunnar Bittersmann
Ich taufe head > *
auf den Namen Santa hat selector. 🎅
LLAP 🖖
@@Gunnar Bittersmann
Auch ein Link-Element innerhalb body wird nur im FF anklickbar. Laut spec ist link ja auch nicht interaktiv. Imho verhalten sich die anderen Browser also richtig.
Ah, da wären die Tickets (erstmal) nicht gegen die Browser zu erstellen, sondern gegen die Spec.
Oder auch nicht. Es ist ja nicht mehr so wie früher, dass gespecct wird, was sich jemand als sinnvoll ausdenkt, und das dann in Browsern implementiert wird. Es wird gespecct, was die Browserhersteller schon so implementiert haben.
Also doch Tickets gegen die Browser, dass sie link
als interaktives Element betrachten sollen.
LLAP 🖖
@@Gunnar Bittersmann
warum? Das head-Element ist für Meta-Daten und nicht Inhaltsdaten. Wenn Du einen anklickbaren Verweis willst, dann ist das kein Meta-Datum, sondern ein Teil des Inhalts
Nein, in meinem Fall nicht. Die Beziehung zur anderen Ressource gehört nicht zum Inhalt, sondern ist eine Metainformation. Diese soll aber für den Nutzer trotzdem als anclickbarer Link dargestellt werden.
Ich hab einen Anwendungsfall mal in den Pen u.a. Pens eingebaut: Ein Link soll zurückführen auf das Posting, zu dem der Pen erstellt wurde.
Der Zurücklink (samt zugehörigen Styles) gehört nicht zu der Bastelei dazu und ist deshalb nicht im Pen-Quelltext zu sehen – würde sonst auch nur verwirren.
Per Einstellungen wird
<link rev="help" href="https://forum.selfhtml.org/self/2016/dec/16/link-nicht-verlinkt/1682692#m1682692"/>
in den head
gesetzt, den Rest erledigt ein ebenfalls eingebundenes JavaScript, das auch das benötigte Stylesheet nachlädt.
Die Verwendung von help
ist vielleicht grenzwertig, war aber von den Keywords am nächsten dran.
Ich hatte auch ein JSON-LD im Sinn:
<script type="application/ld+json">
{
"@context": {
"schema": "http://schema.org/"
},
"@type": "SoftwareSourceCode",
"exampleOfWork": {
"@type": "Article",
"url": "https://forum.selfhtml.org/self/2016/dec/16/link-nicht-verlinkt/1682692#m1682692"
}
}
</script>
Das wäre aber umständlicher zu erstellen und zu parsen.
LLAP 🖖
Hallo Gunnar Bittersmann,
Ich hab einen Anwendungsfall mal in den Pen u.a. Pens eingebaut: Ein Link soll zurückführen auf das Posting, zu dem der Pen erstellt wurde.
nett.
Bis demnächst
Matthias
@@Gunnar Bittersmann
Ich hab einen Anwendungsfall mal in den Pen u.a. Pens eingebaut: Ein Link soll zurückführen auf das Posting, zu dem der Pen erstellt wurde.
Und noch einer: editable stylesheet (Spielwiese).
LLAP 🖖
Hallo Gunnar Bittersmann,
Ich hab einen Anwendungsfall mal in den Pen u.a. Pens eingebaut: Ein Link soll zurückführen auf das Posting, zu dem der Pen erstellt wurde.
Ich habe mich einfach angeschlossen (m1683484) und auch ganz frech dein Script eingebunden. Falls das nicht in Ordnung ist, sag Bescheid.
Bis demnächst
Matthias
@@Matthias Apsel
Ich habe mich einfach angeschlossen (m1683484) und auch ganz frech dein Script eingebunden. Falls das nicht in Ordnung ist, sag Bescheid.
Nur zu.
Änderungen (bspw. am Stylesheet) vorbehalten.
LLAP 🖖
Ich lasse ein
<link rel="foo" href="…"/>
-Element im Viewport anzeigen:head { display: block } head > * { display: none } head [rel="foo"] { display: inline } head [rel="foo"]::before { content: "Link" }
Der Gunnar visualisiert Head-Elemente und Hotti schickt Ajax-Aufrufe durch htauth. Langsam werde ich zu alt für das Zeugs!
Nicht nur Du. Die sind hier mittlerweile so senil, dass sie den Sinn einer Versionskontrolle in Frage stellen ;)
MfG
Hallo pl,
Nicht nur Du. Die sind hier mittlerweile so senil, dass sie den Sinn einer Versionskontrolle in Frage stellen ;)
Nicht den Sinn einer Versionskontrolle, sondern den Sinn dessen, was du unter einer Versionskontrolle verstehst.
Bis demnächst
Matthias
Nicht nur Du. Die sind hier mittlerweile so senil, dass sie den Sinn einer Versionskontrolle in Frage stellen ;)
Und Passworte in Globalen Variablen der Serverumgebung als Best Practice bezeichnen ;)
Nicht nur Du. Die sind hier mittlerweile so senil, dass sie den Sinn einer Versionskontrolle in Frage stellen ;)
Und Passworte in Globalen Variablen der Serverumgebung als Best Practice bezeichnen ;)
Es wäre nett, wenn du die Diskussionen in ihren jeweiligen Threads weiterführst. Ich sperre diesen Zweig zu diesem Zweck.