Vererbung

[franzsen]

Auf der Seite habe ich ein Beispiel bezgl. Tooltips. Dazu hätte ich folgende Fragen:

Mit der Klasse "quickinfo" spreche ich doch den gesamten Inhalt von "abbr" an? Warum ist der Rest nicht ebenso unterstrichen? "Color" wird später verändert.

Abgesehen von der Eigenschaft "strong" könnte ich die anderen Formatierungen in "dfn" formulieren?

Mit "margin-left: -9999em;" wird die Quickinfo aus dem sichtbaren Bereich geschoben. Nun habe ich schon einmal gelesen, daß man dies nicht machen soll. Es gibt dann noch "display: none;", "font: 0/0; z-index: -1;" und "visibility: hidden;". Welche davon ist nun die idealere Methode bzw. für welche Situation ist welche anzuwenden? Hier wird mit "Screenreader" argumentiert.

Wenn ich "outline: none;" lösche passiert überhaupt nichts.

Dfn bzw. abbr sind inline-Elemente ohne Auswirkungen. Könnte man dann nicht x-beliebige inline-Elemente nehmen?

Abbr wird im Zusammenhang mit "title="text"" verwendet. Wird es in diesem Beispiel nicht zweckentfremdet?

[MrMurphy1]

Hallo

Könnte man dann nicht x-beliebige inline-Elemente nehmen?

Du? Ja.

Um die Frage zu beantworten musst du erst mal entscheiden, ob du die Seiten für dich oder für deine Besucher oder nach den Regeln von HTML erstellen willst. Wobei die Regeln von HTML und Besucherfreundlichkeit fast identisch sind. Die Regeln von HTML sind die Grundlagen der Besucherfreundlichkeit.

Gruss

MrMurphy

[franzsen]

Hallo

Könnte man dann nicht x-beliebige inline-Elemente nehmen?

Du? Ja.

Um die Frage zu beantworten musst du erst mal entscheiden, ob du die Seiten für dich oder für deine Besucher oder nach den Regeln von HTML erstellen willst. Wobei die Regeln von HTML und Besucherfreundlichkeit fast identisch sind. Die Regeln von HTML sind die Grundlagen der Besucherfreundlichkeit.

Natürlich für Besucher. Die Seite soll ja einmal in's Internet gestellt werden.
Daher Tooltipps so wie gezeigt? Weiters wird noch geschrieben von Standard-Tooltipps. Wie sehen die dann aus bzw. wie sieht dieser Code aus?

[MrMurphy1]

Hallo

Natürlich für Besucher.

Dann ist die Antwort klar: Besucherfreundliche Seite verwenden korrektes HTML. Und in den HTML-Spezifikationen (= Vorschriften) ist festgeschrieben, das semantisch korrekte Elemente zu verwenden sind, also verwendet werden müssen. Nur wenn es keine passenden Elemente gibt sind neutrale Elemente wie div oder span zu verwenden.

Standard-Tooltips sind solche, die bei Verwendung des title-Elements unformatiert angezeigt werden. Einige Browser haben zeitweise auch das alt-Element als Tooltip angezeigt, aber das war wohl niemals korrekt.

Wie sehen die dann aus bzw. wie sieht dieser Code aus?

Zum Beispiel so:

<img src="http://lorempixel.com/500/200/transport" alt="alt transport" title="title transport">

Das title-Attribut kann in fast jedem Element verwendet werden. Allerdings werden Besucher die zum Beispiel in Texten kaum vermuten und aufrufen. Zumal es bei Touchscreens keinen hover-Effekt gibt.

Daher Tooltipps so wie gezeigt?

Auf der verlinken Seite? Nein. Die Elemente werden teilweise falsch verwendet beziehungsweise passen nur in diesem Beispiel. Korrekt wäre demnach eine Lösung mit span-Elementen. Die anderen Elemente dann wenn sie passen.

Gruss

MrMurphy

[Gunnar Bittersmann]

@@MrMurphy1

title-Elements […]
alt-Element […]
das war wohl niemals korrekt.

Stimmt. ;-)

LLAP 🖖

[Camping_RIDER]

Aloha ;)

Bei allem Respekt, aber das

Auf der verlinken Seite? Nein. Die Elemente werden teilweise falsch verwendet beziehungsweise passen nur in diesem Beispiel. Korrekt wäre demnach eine Lösung mit span-Elementen. Die anderen Elemente dann wenn sie passen.

ist mMn so irgendwie nicht hilfreich. Zumindest, wenn du das so ohne weitere Erläuterungen und Differenzierung hinstellst. Zielführender wäre es hier, konkret zu sagen, an welcher Stelle Elemente falsch verwendet werden und wie eine (gleichwertige) Alternative aussehen kann. Die Verwendung des title-Attribut, die du vorschlägst, dient zwar einem ähnlichen Zweck, ist aber sicher nicht gleichwertig - weder kann der Tooltip mittels title optisch an die Bedürfnisse der Seite angepasst werden, noch kann etwas anderes als Plain Text verwendet werden. Selbstverständlich kann man beim Bau einer Seite, trotz der Existenz von title, auch selbst eine Tooltip-Funktion einbauen, sofern dabei sinnvolles, semantisches Markup gewahrt bleibt - und das, ohne Benutzerfreundlichkeit zu verlieren. Tatsächlich gewinnt man hier sogar an Benutzerfreundlichkeit, da dieser Tooltip notfalls auch per Klick (bzw. Touch) geöffnet werden kann, und damit mobile-friendly ist (wie du ja auch schon sagtest) - ganz im Gegensatz zum title-Attribut, das nur auf Desktop-Browsern effektiv nutzbar ist.

Tatsächlich verwendet sogar die HTML-Spec ein Beispiel, in dem die Elemente ganz ähnlich verwendet werden.

Prinzipiell ist nichts dagegen einzuwenden, <dfn> für einen Tooltip zu verwenden - immerhin liefert ein Tooltip grundsätzlich weitere Informationen zu einem Wort, stellt also eine Art Definition dar. Die Verwendung von <abbr> ist vielleicht etwas kritischer. Einerseits sollte <abbr> nicht, wie auf der verlinkten Seite, das <dfn> beinhalten - das ist semantisch nicht sinnvoll. Andererseits ist, wenn wir nicht gerade CSS oder WHATWG (also tatsächliche Abkürzungen) als Vorkommen im Text haben, auch nicht wirklich eine Abkürzung beteiligt - nicht bei jedem denkbaren, tooltip-fähigen Wort handelt es sich zwangsläufig um eine Abkürzung. Hier hast du also nicht unrecht, wenn du zu einer Verwendung des generischen span rätst (wobei wir sehen werden, dass wir dafür gar kein Element brauchen). Es ist allerdings dann trotzdem eine gute Idee, die Semantik mittels der zur Verfügung stehenden Werkzeuge in HTML5 aufrecht zu erhalten.

Als Alternative, die gleichwertig eingesetzt werden kann, aber semantisch fehlerfreier ist, stelle ich mal folgendes Markup (auf der Grundlage der verlinkten Seite) zur Diskussion:

<p>
  Mit
    <dfn tabindex="0"  class="quickinfo"> 
      CSS 
      <span role="tooltip">
        Cascading Stylescheets <br>
        dienen zum Formatieren von Webseiten und sind der Schlüssel zum Erfolg.
      </span>
    </dfn>
  lassen sich sehr einfach Tooltipps oder auch Quickinfos erstellen.
</p> 

Wir haben also ein alles gruppierendes <dnf>-Element - das ist sinnvoll, denn sowohl die Definition als Text als auch das zu definierende Wort sind Teil einer Definition (und dass Tooltips immer eine Art der Definition im Sinne einer näheren Bestimmung sind, hatte ich schon dargelegt). Der Text der Definition, der später als Tooltip erscheinen soll, wird durch ein <span> umfasst, welches zum Ausgleich der semantischen Bedeutungslosigkeit über den dafür vorgesehenen role-Attributwert wieder Bedeutung erhält.

Die CSS-Formatierung kann dann geschehen wie auf der verlinkten Seite gezeigt; einfach attr.quickinfo durch dfn.quickinfo ersetzen und statt
abbr.quickinfo:hover dfn, abbr.quickinfo:focus dfn ein
dfn.quickinfo:hover span[role=tooltip], dfn.quickinfo:focus span[role=tooltip]
einsetzen.

Grüße,

RIDER

[Matthias Apsel]

Hallo Camping_RIDER,

Der Inhalt eines Tooltips ist unter Umständen, schwer bis gar nicht erreichbar. Darum sollte man wichtige Sachen vielleicht nicht unbedingt in einem Tooltip verstecken. Unwichtige Sachen brauchen allerdings auch nicht im Markup zu erscheinen, deshalb könnte man auch ::before- oder ::after-Pseudolelemente verwenden. Siehe auch http://selfhtml.apsel-mv.de/tooltipp/tooltipp.html

Vor und Nachteile sind in diesem Thread schon hinreichend beleuchtet.

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

Der Inhalt eines Tooltips ist unter Umständen, schwer bis gar nicht erreichbar. Darum sollte man wichtige Sachen vielleicht nicht unbedingt in einem Tooltip verstecken. Unwichtige Sachen brauchen allerdings auch nicht im Markup zu erscheinen, deshalb könnte man auch ::before- oder ::after-Pseudolelemente verwenden. Siehe auch http://selfhtml.apsel-mv.de/tooltipp/tooltipp.html

Meh. Ich bin im Allgemeinen für strikte separation of concerns - und dazu gehört, dass ich mit CSS-Mitteln (Pseudoelementen) nur Dinge nachschiebe, die strikt darstellungsbezogen sind. Das ist ein Tooltip nicht, in einem Tooltip steht Inhalt. Außerdem limitieren auch Pseudoelemente die Möglichkeiten, Inhalt im Tooltip unterzubringen.

Du hast vollkommen Recht mit

Darum sollte man wichtige Sachen vielleicht nicht unbedingt in einem Tooltip verstecken.

Trotzdem sind die Inhalte eines Tooltips für mich Inhalt, und der hat gefälligst im Markup zu stehen, selbst wenn er unwichtig genug ist, um bloß in einem Tooltip präsentiert zu werden.

Diese Aussage

Unwichtige Sachen brauchen allerdings auch nicht im Markup zu erscheinen

würde ich anzweifeln, dafür fehlt mir die Begründung. Information ist Information, und Information gehört ins Markup.

Grüße,

RIDER

[Matthias Scharwies]

Servus!

Tatsächlich verwendet sogar die HTML-Spec ein Beispiel, in dem die Elemente ganz ähnlich verwendet werden.

Ich habe mich mal ein bisschen umgeschaut und gemerkt, dass alle Tooltips mit :hover arbeiten und deshalb nicht auf Touch-Geräten, bzw Screenreadern gehen.

Welche Alternativen schlagt ihr vor?

• Doch einen internen Link mit :target?

• Popup-Boxen mit JS?

Herzliche Grüße

Matthias Scharwies

[MrMurphy1]

Hallo

Welche Alternativen schlagt ihr vor?

Informationen zu verstecken ist eine Unart von Webseiten. Die einzigen Hochgefühle bekommen damit unfähige Webseitenersteller.

Am benutzerfreundlichsten ist es alle Informationen anzuzeigen. Das mag sich langweilig anhören, zeigt im Endeffekt aber das wirkliche Können von Webseitenerstellern.

Damit der Fließtext nicht gestört wird können ganz klassisch Fuß- oder Endnoten oder sogar eine zusätzliche leicht erreichbare Seite mit Erklärungen angelegt werden.

Jedes Verstecken von Informationen aller Art ist eine Barriere und damit Sch...rott. Damit sind auch Aufklappnavigationen oder Icons ohne Text oder ... gemeint.

Gruss

MrMurphy

[Matthias Apsel]

Hallo MrMurphy1,

Damit der Fließtext nicht gestört wird können ganz klassisch Fuß- oder Endnoten oder sogar eine zusätzliche leicht erreichbare Seite mit Erklärungen angelegt werden.

die man auch neben den Fließtext schreiben kann.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Matthias Apsel,

Damit der Fließtext nicht gestört wird können ganz klassisch Fuß- oder Endnoten oder sogar eine zusätzliche leicht erreichbare Seite mit Erklärungen angelegt werden.

die man auch neben den Fließtext schreiben kann.

etwa so (W3C) oder so (SELFHTML-Wiki)

@Gunnar Bittersmann: Die W3C-Seite ist übrigens auf schmalen Viewports schlecht benutzbar.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

@Gunnar Bittersmann: Die W3C-Seite ist übrigens auf schmalen Viewports schlecht benutzbar.

Auf breiten auch nicht wirklich gut. Die Links im Fließtext sind nicht unterstrichen und unterscheiden sich auch in der Farbe nicht so dolle vom übrigen Text. Besonders seit die Helvetica im Light-Schnitt daherkommt, braucht man da schon Adleraugen.

Können Vögel überhaupt Farben sehen?

LLAP 🖖

[Der Martin]

Hi,

Informationen zu verstecken ist eine Unart von Webseiten. Die einzigen Hochgefühle bekommen damit unfähige Webseitenersteller.

*fg*
Das ist wohl wahr, aber nicht nur auf Webseiten beschränkt. Wenn ich nur dran denke, wie versteckt manchmal das Impressum einer Zeitschrift ist, oder die Legende einer (gedruckten) Landkarte, wird mir schon wieder ganz anders.

Am benutzerfreundlichsten ist es alle Informationen anzuzeigen. Das mag sich langweilig anhören, zeigt im Endeffekt aber das wirkliche Können von Webseitenerstellern.

D'accord. Das erfordert aber eine wohlüberlegte Darstellung dieser Informationen, damit dadurch nicht die Übersichtlichkeit flöten geht.
Du erwähnst Fußnoten als Beispiel. Die kennen die Leute von den Printmedien, das sollte also halbwegs intuitiv funktionieren. Aber wenn nun das Dokument länger ist als das Browserfenster, muss ich zur Fußnote scrollen. Und wieder zurück. Das ist umständlich, auch wenn ich voraussetze, dass das durch klickbare Elemente und die Zurück-Navigation des Browsers unterstützt wird. Aber ich muss die momentane Leseposition für einen Moment verlassen. Beim Print-Medium würde man die Position mit einem Finger markieren und mit den Augen kurz den unteren Seitenrand anvisieren, dann zurück zum Finger. Beim Web-Dokument ist es trotz aller Unterstützung umständlicher. Also vielleicht irgendeine Split-Screen-Methode? Frames? Nein, nicht wirklich.

Jedes Verstecken von Informationen aller Art ist eine Barriere und damit Sch...rott. Damit sind auch Aufklappnavigationen oder Icons ohne Text oder ... gemeint.

Unbedingt.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

D'accord. Das erfordert aber eine wohlüberlegte Darstellung dieser Informationen, damit dadurch nicht die Übersichtlichkeit flöten geht.
Du erwähnst Fußnoten als Beispiel. Die kennen die Leute von den Printmedien

Wobei die in Büchern auch manchmal ein Ärgernis sind, wenn sie nicht auf derselben Seite stehen, sondern am Ende des Kapitels oder am Ende des Buches.

Aber wenn nun das Dokument länger ist als das Browserfenster, muss ich zur Fußnote scrollen. Und wieder zurück. Das ist umständlich

Ja, Fußnoten sind im Web nicht besonders schlau.^[1]

Anstatt unter dem Text könnten solche Ergänzungen auch gleich neben dem Text stehen, besonders bei breiten Viewports, wo der Text nicht die gesamte Breite ausfüllen sollte, sondern die Zeilenlänge auf etwa 60 Zeichen beschränkt sein sollte. Matthias hat die W3C-i18n-Seiten schon als Beispiel angeführt.

Für schmale Viewports müsste man sich allerdings was anderes überlegen: bspw. Ergänzungstext nach dem jeweilen Absatz eingeschoben oder ein sichtbarer Indikator, bei dem auf Click oder Wischgeste der Ergänzungstext von der Seite reinfährt.

LLAP 🖖

---

1. Hier im Forum mag das noch gehen, weil die Postings üblicherweise nicht so lang sind. ↩︎

[Camping_RIDER]

Aloha ;)

Für schmale Viewports müsste man sich allerdings was anderes überlegen: bspw. Ergänzungstext nach dem jeweilen Absatz eingeschoben oder ein sichtbarer Indikator, bei dem auf Click oder Wischgeste der Ergänzungstext von der Seite reinfährt.

In die Richtung ging auch meine Intuition - ich stimme MrMurphy zu, dass es besser ist, den gesamten Inhalt textuell darzustellen, ohne ihn zu verstecken, kann mir sowas wie Tooltips^[1] zusätzlich gut vorstellen - wenn der Link zur Fußnote (o.ä.) einen Tooltip mit "seinem" Text anzeigen kann, sparen sich diejenigen, die den Tooltip aufrufen können bzw. wollen den Sprung auf der Seite, während für diejenigen, die das nicht können oder wollen, die Fußnote ganz klassisch mit ihrem Inhalt daherkommt.

Grüße,

RIDER

---

1. Tooltips meint hier nicht zwangsläufig Tooltips in ihrer klassischen Erscheinung, sondern auch die Form, die Gunnar angesprochen hat, oder auch weitere denkbare Darstellungsformen. ↩︎

[Matthias Scharwies]

Servus!

Welche Alternativen schlagt ihr vor?

Informationen zu verstecken ist eine Unart von Webseiten. Die einzigen Hochgefühle bekommen damit unfähige Webseitenersteller.

Danke für eure Rückmeldungen, ich werde es in den nächsten Tagen ins Wiki integrieren. Im Wiki gab es alle Einzelinformationen, aber auf viele Orte verteilt und nicht verlinkt.

Das mit den Fußnoten ist auch in Arbeit.

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Servus!

Das Tultip-Tootorial ist jetzt online.

Grad zum Schluss hab ich noch ein bestehendes Beispiel im Wiki gefunden:

• Tooltip durch Auslesen des Data-Attributes

Das mit den Fußnoten ist auch in Arbeit.

Ich bin dran.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@franzsen

Mit der Klasse "quickinfo" spreche ich doch den gesamten Inhalt von "abbr" an? Warum ist der Rest nicht ebenso unterstrichen? "Color" wird später verändert.

Was genau meinst du?

Mit "margin-left: -9999em;" wird die Quickinfo aus dem sichtbaren Bereich geschoben. Nun habe ich schon einmal gelesen, daß man dies nicht machen soll. Es gibt dann noch "display: none;", "font: 0/0; z-index: -1;" und "visibility: hidden;". Welche davon ist nun die idealere Methode

Keine, denn es gibt keine Steigerung von ideal.

bzw. für welche Situation ist welche anzuwenden?

Die erste ist für gar keine Situation anzuwenden; die zweite für Situationen, wo du Inhalt visuell verstecken möchtest.

Wenn ich "outline: none;" lösche passiert überhaupt nichts.

Vermutlich doch: Das Element, das den Fokus hat, wird nicht hervorgehoben. Navigation per Tastatur dann wohl schwierig bis unmöglich.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Wenn ich "outline: none;" lösche passiert überhaupt nichts.

Vermutlich doch: Das Element, das den Fokus hat, wird nicht hervorgehoben. Navigation per Tastatur dann wohl schwierig bis unmöglich.

Doch gerade jetzt wird es hervorgehoben. ;-)

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Wenn ich "outline: none;" lösche passiert überhaupt nichts.

Vermutlich doch: Das Element, das den Fokus hat, wird nicht hervorgehoben. Navigation per Tastatur dann wohl schwierig bis unmöglich.

Doch gerade jetzt wird es hervorgehoben. ;-)

Da hat mich der MrMurphy ganz durcheinander gebracht mit seinen Elementen und Attributen … ;-) Schnell die Grafik dazu her, um hiervon abzulenken!

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Da hat mich der MrMurphy ganz durcheinander gebracht mit seinen Elementen und Attributen … ;-) Schnell die Grafik dazu her, um hiervon abzulenken!

Gern doch. Wobei ich sicher bin, das MrMurphy ziemlich genau weiß, was ein Element und was ein Attribut ist. Möglicherweise hat er einfach nur aus der Seite zitiert?

Bis demnächst
Matthias

[franzsen]

@@franzsen

Mit der Klasse "quickinfo" spreche ich doch den gesamten Inhalt von "abbr" an? Warum ist der Rest nicht ebenso unterstrichen? "Color" wird später verändert.

Was genau meinst du?

Wenn ich beispielsweise habe:

<div class="beispiel">
  ...
</div>  

dann wird doch mit CSS "style {.beispiel...}" der gesamte Inhalt mit CSS angesprochen.

Dann müßte doch im gegebenen Fall alles innerhalb von <abbr> ("CSS" sowie der Inhalt von <dfn>) angesprochen werden also unterstrichen werden? Damit meinte ich die Frage "Vererbung".
Unterbrechen bestimmte HTML-Elemente die Vererbung von bestimmten Selektoren?

[Matthias Apsel]

Hallo franzsen,

Unterbrechen bestimmte HTML-Elemente die Vererbung von bestimmten Selektoren?

Nein.

Manche Selektoren sind spezifischer als andere.

Selektoren werden nicht vererbt, Eigenschaften können vererbt werden. Informiere dich etwa in unserem Wiki.

Bis demnächst
Matthias

[Camping_RIDER]

Aloha ;)

Auf der Seite habe ich ein Beispiel bezgl. Tooltips.

Ergänzungen semantischer Art habe ich an anderer Stelle schon ausreichend thematisiert.

Mit der Klasse "quickinfo" spreche ich doch den gesamten Inhalt von "abbr" an? Warum ist der Rest nicht ebenso unterstrichen? "Color" wird später verändert.

Das liegt daran, dass die Unterstreichung nicht mittels tatsächlicher Unterstreichung erreicht wird, sondern (afais) durch ein border-bottom - und der Rest ist nicht betroffen, weil er mit position:absolute aus dem Kontext genommen wurde.

Abgesehen von der Eigenschaft "strong" könnte ich die anderen Formatierungen in "dfn" formulieren?

Das <strong> ist an der Stelle quatsch (damit soll wichtiges hervorgehoben werden, was irgendwie witzlos ist, wenn der gesamte Kontext innerhalb <strong> steht) - folgerichtig habe ich das aus meinem Markup-Vorschlag auch entfernt. Ansonsten kannst du die anderen Formatierungen im inneren Element formulieren wie du lustig bist, ja.

Mit "margin-left: -9999em;" wird die Quickinfo aus dem sichtbaren Bereich geschoben. Nun habe ich schon einmal gelesen, daß man dies nicht machen soll. Es gibt dann noch "display: none;", "font: 0/0; z-index: -1;" und "visibility: hidden;". Welche davon ist nun die idealere Methode bzw. für welche Situation ist welche anzuwenden? Hier wird mit "Screenreader" argumentiert.

Mit Screenreader zu argumentieren ist meiner Meinung nach in dem Fall irgendwie daneben. display: none; oder - speziell in diesem Fall, wo der Tooltip sowieso aus dem Kontext entfernt wird - visibility:hidden sollte schon in Ordnung sein - ich würde wahrscheinlich in dem Fall zu zweiterem greifen.

Wenn ich "outline: none;" lösche passiert überhaupt nichts.

Ich sehe auch keinen Grund, warum da was passieren sollte.

Dfn bzw. abbr sind inline-Elemente ohne Auswirkungen. Könnte man dann nicht x-beliebige inline-Elemente nehmen?

Nein. Semantik ist wichtig, es ist sinnvoll, möglichst bedeutungsvolle Elemente zu wählen. Mehr zur konkreten Umsetzung in diesem Fall aber im bereits von mir verlinkten Posting.

Abbr wird im Zusammenhang mit "title="text"" verwendet. Wird es in diesem Beispiel nicht zweckentfremdet?

Je nachdem, wie man es nimmt. Generell ja, im konkreten Beispiel "CSS" nein, aber auch nur, wenn der Tooltip nicht in <abbr> enthalten ist. Also in der verlinkten Seite ja ;)

Grüße,

RIDER

[franzsen]

Das liegt daran, dass die Unterstreichung nicht mittels tatsächlicher Unterstreichung erreicht wird, sondern (afais) durch ein border-bottom - und der Rest ist nicht betroffen, weil er mit position:absolute aus dem Kontext genommen wurde.

Also "dfn" erhält "position: absolute". Dann müßte eigentlich alles zwischen <abbr> (Rahmen bekommen) unterstrichen sein, wenn ich das raus nehme, tut es aber nicht.

Tut mir leid aber den Ausdruck (afais) kenne ich nicht.

[Der Martin]

Hallo,

Tut mir leid aber den Ausdruck (afais) kenne ich nicht.

eine im heutigen Jargon gängige Abkürzung aus dem Englischen:
as far as I see - soweit ich es sehe

So long,
 Martin

[MrMurphy1]

Hallo

Mit position:absolute hat die Unterstreichung (border-bottom) nichts zu tun.

Dann müßte eigentlich alles zwischen <abbr> (Rahmen bekommen) unterstrichen sein

Du meinst den border-bottom mit zwei Strichen (double)?

Wird es doch auch. Und zwar solange, bis die border-bottom-Anweisung überschrieben wird. Also die ganz normale Cascade im C von CSS.

Dies geschieht in dem Beispiel direkt hinter dem Wort CSS durch

abbr.quickinfo strong {
   ...
   border: 1px solid #000;
   ...
}

Gruss

MrMurphy

[franzsen]

Wird es doch auch. Und zwar solange, bis die border-bottom-Anweisung überschrieben wird. Also die ganz normale Cascade im C von CSS.

Dies geschieht in dem Beispiel direkt hinter dem Wort CSS durch

abbr.quickinfo strong {
   ...
   border: 1px solid #000;
   ...
}

Eigentlich logisch. Waren wieder einmal zu viele Bäume im weg.