Frage zum Wiki-Artikel „Tooltips_mit_CSS“

[nix]

Ein Nachteil von „Tooltips“ (oder was man auch so nennen mag), die ohne Programmierung, also nur mittels HTML + CSS realisiert werden: sie liegen fast immer, gut, sehr oft, an der falschen Stelle. Also so, daß sich ihr Inhalt, ganz oder teilweise, nicht im Blickfeld des Betrachters darstellt. Egal, wo sie platziert werden, sie liegen zu weit oben, unten, links oder rechts und befinden sich dann außerhalb des Browser-Fensters. Wenn überhaupt ein Scrollbalken für ein Nachführen erscheint, so sind sie allemal lästig. Und scheitern dann oft, wie bei absoluten oder fixed Elementen, schon beim :hover. Abhilfe kann man nur schaffen, wenn man den Bereich, in dem sie erscheinen, an den Fensterrändern begrenzt. Genug, um das höchste/breiteste Tooltip im sichtbaren Bereich zu halten.

Das ist einer der Nachteile der HTML/CSS-Architektur: ob man nun top-down oder bottom-up baut, irgendwo fehlen immer die Informationen bzw. Möglichkeiten, solche Dinge zu berücksichtigen. Vmtl. der wesentliche Umstand für mein Gemecker hier in den letzten Wochen: immer wieder „sah eigentlich alles gut aus“ — bis auf irgend ein Detail, das sich letzendlich als tödliches Gift erwies. Nur ein Beispiel: anstelle von details (die auch ihre Probleme mit sich bringen: z. B. #marker findet da nicht jeder Browser) ein Konstrukt aus Blöcken, welche den „geheimen Inhalt“ von details als aufrollende „Fahne“ zeigen? Man versuche, ein passsend angepaßtes div mittels transition:height (geht eigentlich auch block-size? Mir lohnt der Versuch nicht) zu gestalten. Aber height: 0% / height: 100% (wären mathematisch durchgeführte Berechnunge doch nur etwas, das CSS könnte! Vor allem das Berücksichtigen von Einheiten. Aber … ###!) klappt ja nicht. Und eine feste Höhe paßt auch nur recht selten (wenn der Inhalt mal aus einem Wort, mal aus einem halben Roman bestehen darf … Scrollbars? Liegen irgendwo, vor allem unkontrollierbar, drüber und wollen sich nicht einpassen).

Ähnliches mit content-type und contains: egal, was man da vorzugeben versucht … 100cq-dingens sind mal irgend welche Elemente, dann doch wieder das Browser-Fenster (oder sogar mehr), max-height und max-width wird sehr gerne ignoriert, …

Der Eindruck, daß da von mehren Stellen aus nicht aufeinander zu sondern voneinander weg entwickelt wird, drängt sich deutlich auf. Scherze, wie das Bemängeln von z. B. `content-type˚ als Style-Element für body, das nur dann auftritt wenn bestimmter (nur: welcher?) Inhalt im body steckt, bringen dann nicht nur ein Faß zum überlaufen.

[Matthias Scharwies]

Guten Morgen Franz,

Du stellst keine Frage!

Bitte halte dich an die Verhaltensrichtlinien für alle Teilnehmer

Ein Nachteil von „Tooltips“ (oder was man auch so nennen mag), die ohne Programmierung, also nur mittels HTML + CSS realisiert werden: sie liegen fast immer, gut, sehr oft, an der falschen Stelle. Also so, daß sich ihr Inhalt, ganz oder teilweise, nicht im Blickfeld des Betrachters darstellt. Egal, wo sie platziert werden, sie liegen zu weit oben, unten, links oder rechts und befinden sich dann außerhalb des Browser-Fensters.

Das wird im Fazit: Tooltip, Touch und Zugänglichkeit auch erwähnt! Sollte das noch weiter nach oben?

Das ist einer der Nachteile der HTML/CSS-Architektur: ob man nun top-down oder bottom-up baut, irgendwo fehlen immer die Informationen bzw. Möglichkeiten, solche Dinge zu berücksichtigen. Vmtl. der wesentliche Umstand für mein Gemecker hier in den letzten Wochen: immer wieder „sah eigentlich alles gut aus“ — bis auf irgend ein Detail, das sich letzendlich als tödliches Gift erwies.

Im oben erwähnten Abschnitt werden Fußnoten mit CSS empfohlen. Die Komfort-Version ist nicht fertig, weil niemand dazu kommt.

Und das ist das Problem: Ein Handwerker hat die richtigen Werkzeuge und weiß, was er mit welchem Werkzeug erreichen kann. Oft wird er potentiellen Kunden aber auch sagen, dass sich diese Idee so nicht verwirklichen lässt

Nur ein Beispiel: anstelle von details (die auch ihre Probleme mit sich bringen: z. B. #marker findet da nicht jeder Browser)

Du meinst ::marker ?

• HTML/Tutorials/details#Gestaltung_mit_CSS

ein Konstrukt aus Blöcken, welche den „geheimen Inhalt“ von details als aufrollende „Fahne“ zeigen?

???

Man versuche, ein passsend angepaßtes div mittels transition:height (geht eigentlich auch block-size? Mir lohnt der Versuch nicht) zu gestalten. Aber height: 0% / height: 100% (wären mathematisch durchgeführte Berechnunge doch nur etwas, das CSS könnte! Vor allem das Berücksichtigen von Einheiten. Aber … ###!) klappt ja nicht. Und eine feste Höhe paßt auch nur recht selten (wenn der Inhalt mal aus einem Wort, mal aus einem halben Roman bestehen darf … Scrollbars? Liegen irgendwo, vor allem unkontrollierbar, drüber und wollen sich nicht einpassen).

Da gibt es ein Live-Beispiel unterhalb der verlinkten Stelle!

Ähnliches mit content-type und contains: egal, was man da vorzugeben versucht … 100cq-dingens sind mal irgend welche Elemente, dann doch wieder das Browser-Fenster (oder sogar mehr), max-height und max-width wird sehr gerne ignoriert, …

Das ist neu und ich würde das für Elemente nebeneinander, aber nicht zum Auf- und Zuklappen von details verwenden.

Der Eindruck, daß da von mehren Stellen aus nicht aufeinander zu sondern voneinander weg entwickelt wird, drängt sich deutlich auf. Scherze, wie das Bemängeln von z. B. `content-type˚ als Style-Element für body, das nur dann auftritt wenn bestimmter (nur: welcher?) Inhalt im body steckt, bringen dann nicht nur ein Faß zum überlaufen.

Du meinst container-type?

Nur weil man in SVG Präsentationsattribute wie font-size für alle Elemente setzen kann, heißt das nicht, dass ein circle auch Schrift enthalten darf. Genauso ist es in der HTML-Welt.

---

Und jetzt habe ich wieder 30min aufgewendet. Nicht für Deine Fragen, sondern um Dritten zu zeigen, dass die SELFHTML-Doku nicht etwa fehlerhaft sei und dass wir gerechtfertigte Kritik aufnehmen.

Herzliche Grüße

Matthias Scharwies

[nix]

„Das wird im Fazit: Tooltip, Touch und Zugänglichkeit auch erwähnt!“

„Fazit“ finde ich da öfter. Aber keinen Hinweis darauf, daß so ein Tooltip nicht (ganz) sichtbar sein kann, weil es auf irgend einer Seite aus dem sichtbaren Bereich liegt. Das, meine ich, gehört zu den allgemeinen Hinweisen, neben Screenreader usw.

„Im oben erwähnten Abschnitt werden Fußnoten mit CSS empfohlen.“

Fußnoten? Ja, die könnte man auch verwenden. Aber sie passen nicht so gut zu einer Seite, die sich wenig an einer Gestaltug „wie auf Papier“ festmachen lassen möchte. „Suppe ißt man auch nicht so gut mit einer Gabel“.

„Du meinst ::marker ?“

::marker würde dem Zugriff dienen, würde der eine oder andere Browser im Inspektor ein #marker anzeigen. Also: sowohl als auch. Und: details wäre etwas, das meiner Idee immerhin, von der Gestaltung her, nahe kommt. Gemischt mit Effekten wie in Menüs mit automatischem Auf- und Zuklappen, nur eben mit dem Zusatzangebot an Infos anstelle von Menüpunkten. Die Idee war also ungefähr

<info-box>
  <header>Teaser</header>
  <info-area>„da guggst du!“</info-area>
</info-box>

Und info-area rollt sich, über dem anderen Seiteninhalt liegend, auf wenn man auf den header zeigt. Aber height verträgt sich nicht mit transition, wenn die Höhe der Box nicht festgenagelt wird. Ja, es gibt da ein Beispiel. Aber … na, das wird jetzt doch zu kompliziert.

Das mit den cq-Einheiten hat damit aber nicht viel zu tun. Gut, damit herumgespielt habe ich. Nur kriege ich einfach nicht heraus, wann da „100cqb“ nicht mit „100vb“ identisch ist. Meist ist es nämlich so (wenn nicht gar „mit 110vb“?). Egal, wie ich da container-type und/oder contain, mit und ohne Grid oder Flexbox, gesetzt und kombiniert habe. Meist, also manchmal waren „100cqi“ doch wieder „nur“ die Breite des Elements, in das eingebettet wurde.

„Du meinst container-type?“

Ja, natürlich.

[Matthias Scharwies]

Servus!

„Das wird im Fazit: Tooltip, Touch und Zugänglichkeit auch erwähnt!“

„Fazit“ finde ich da öfter. Aber keinen Hinweis darauf, daß so ein Tooltip nicht (ganz) sichtbar sein kann, weil es auf irgend einer Seite aus dem sichtbaren Bereich liegt. Das, meine ich, gehört zu den allgemeinen Hinweisen, neben Screenreader usw.

Das gilt ja erst beim #Ein-_und_Ausblenden:

Fazit: Durch ein zusätzliches Element haben Sie einen Tooltip, den Sie nach eigenen Wünschen frei gestalten können. Nur in der Platzierung müssen Sie beachten, dass der Tooltip auch direkt am Rand platziert sein könnte und sich deshalb (teilweise) außerhalb des Viewports befindet.

Information

Nach heutigem Stand kann man nur mit HTML und CSS nicht steuern, ob ein Tooltip außerhalb des Viewport - und damit nicht sichtbar - dargestellt wird. Mit JavaScript und der Intersection Observer API könnte man berechnen, ob sich ein Element im sichtbaren Bereich befindet.

Das W3C entwickelt dafür derzeit das CSS Anchor Positioning Module, mit dem für diesen Fall alternative Formatierungen angegeben werden können.

„Im oben erwähnten Abschnitt werden Fußnoten mit CSS empfohlen.“

Fußnoten? Ja, die könnte man auch verwenden. Aber sie passen nicht so gut zu einer Seite, die sich wenig an einer Gestaltug „wie auf Papier“ festmachen lassen möchte. „Suppe ißt man auch nicht so gut mit einer Gabel“.

Ja, das ist Geschmackssache.

„Du meinst ::marker ?“

::marker würde dem Zugriff dienen, würde der eine oder andere Browser im Inspektor ein #marker anzeigen. Also: sowohl als auch.

Ich weiß immer noch nicht, was dein #marker ist. Bezogen auf details gibt es eben den Text-Inhalt, um den man leider ein div legen muss; ein summary und den marker, der als Pseudoelement angezeigt, aber eben nur über den ::marker-Selektor in manchen Browsern gestylt werden kann.

Und: details wäre etwas, das meiner Idee immerhin, von der Gestaltung her, nahe kommt. Gemischt mit Effekten wie in Menüs mit automatischem Auf- und Zuklappen, nur eben mit dem Zusatzangebot an Infos anstelle von Menüpunkten. Die Idee war also ungefähr

<info-box>
  <header>Teaser</header>
  <info-area>„da guggst du!“</info-area>
</info-box>

Und info-area rollt sich, über dem anderen Seiteninhalt liegend, auf wenn man auf den header zeigt. Aber height verträgt sich nicht mit transition, wenn die Höhe der Box nicht festgenagelt wird. Ja, es gibt da ein Beispiel. Aber … na, das wird jetzt doch zu kompliziert.

Jetzt habe ich deinen Plan verstanden. Und gaube, dass mehrere dieser „Akkordeons“ die Aufgabe erfüllen würden. Gib ihnen eine feste Höhe und veränder' die beim Aufklappen:

details  {
 height: 5em;
}

details[open]  {
  height: 100%
  z-index: 99;
}

ungetestet.

---

Das mit den cq-Einheiten hat damit aber nicht viel zu tun.

Genau!

Gut, damit herumgespielt habe ich. Nur kriege ich einfach nicht heraus, wann da „100cqb“ nicht mit „100vb“ identisch ist. Meist ist es nämlich so (wenn nicht gar „mit 110vb“?).

Ich verspreche dir, dass ich Anfang August ein Tutorial zu Container Queries schreibe.

Egal, wie ich da container-type und/oder contain, mit und ohne Grid oder Flexbox, gesetzt und kombiniert habe. Meist, also manchmal waren „100cqi“ doch wieder „nur“ die Breite des Elements, in das eingebettet wurde.

Nein, nicht kombinieren!

Da gibt es eine klare Trennung von Technologien:

1. media Queries fragen Features ab; z.B. die Bildschirmbreite

@media (min-width: 30em) and (max-width: 60em) { 
  body {
    width: 100%
    padding: 1em;
  }
}
@media print and (min-width: 60em) { 
    max-width: 60em;
    margin: 1em auto;
}

2. Mit Grid Layout kannst du beliebig viele Elemente einer Ebene flexibel positionieren, ohne dich mit Pixeln und festen Breiten etc. beschäftigen zu müssen.

@media (min-width: 40em) {
  body {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(20em, 1fr));
  }
}

article {
  grid-column: 1 / -1; 
  grid-row: span 2; 
}

#news {
  grid-column: span 2;
}

Kindeskinder sind davon nicht betroffen; da müsst du ein neues Grid aufmachen. Und hier kommt die Nr. 3 ins Spiel:

3. Container Queries Wenn die Kindeemente keine Bilder, sondern eben „cards“ mit h3, Bild und Text sind, kannst du diese Kindeskindelemente jetzt formatieren, ohne den Umweg über die Media queries zu gehen.

Mehr im August!

Herzliche Grüße

Matthias Scharwies

[nix]

Wird erwähnt

Ja, da wird es erwähnt. Aber man muß schon einen Grund haben, auch genau da nachzusehen. Obendrein: das mit den Tooltips ist ja nur ein, allerdings leicht zugängliches, Beispiel dafür, daß die Elemente nicht nur einander recht wenig ansehen, sondern nicht wissen, wo sie sich aufhalten. Ein anderes wäre beispielsweise eine Bildergallerie ähnlich einem Gemisch aus dieser Polaroid-Bildergallerie und dem Bilderzoom mit Grid Layout: die Bilder (in annähernd quadratischer Anordnung) an die Wand nageln, da hängen lassen, beim hoovern mit einer scheinbaren Lupe heranzoomen … und wenn die dann auch ungefähr in der Mitte des Viewports / Bildschirms landen würden …

::marker

werden in den Inspektoren-Anschten mit #marker dargestellt. Oder eben nicht. Safari sagt da bei details: wasndas? Und weil Firefox an anderen, mehr, Stellen Ärger bereitet, sind details, auch „welche ohne hoover-Komfort“, jetzt hier raus aus dem Geschäft.

Akkordeons

Nun, meine Idee würde ja auch schon richtig schön funktionieren. Aber die hat mit „deinen“ Akkordeons eines gemeinsam: da der darzustellende Inhalt doch mal mehr, mal weniger umfangreich ist, gibt es da jetzt eine aufgeklappte Box mit oft viel freiem Platz, dann aber wieder mit einem Scrollbalken, der sich nicht um den so schön passend gestalteten border kümmert, den einfach satt überdeckt.

Das Versprechen

Danke dafür! Ich werde mir aber trotzdem erlauben, da ein inoffizielles Rennen mitzumachen! Welche Etappen kann ich gewinnen, was finde ich doch noch so heraus? 😏

to combine or not combine?

Das mit dem Kombinieren war „großflächig“ gemeint. Mal das Eine bei Vorfahren, mal das Andere bei Nachkommen, dann wieder so … einfach um Reaktionen zu provozieren, die man zu interpretieren versuchen kann.

So, und nun, „zum guten Schluß“, wenigstens einmal was Erfolgreiches. Nur ein kleiner Ausschnitt draraus, aber ich denke, das ist einigermaßen selbsterklärend. Bin gespannt, ob’s gefällt. Also die Idee fürs „sprachumschalten“. (BTW: kommt man irgendwie an das, was der Browser gerade bevorzugt? Sozusagen ein :root:lang()?)

			:lang(en) x-episode hgroup[lang=de], :lang(de) x-episode hgroup[lang=en] { grid-row: fremdsprachig / span 1; }
			:lang(en) x-episode hgroup[lang=en], :lang(de) x-episode hgroup[lang=de] { grid-row: sprachkonform / span 1; }
…
			x-actor {
				position: relative;
				display: inline-block;
			}
			x-person {
				position: absolute;
				bottom: 0; left: 0;
				width: max-content;
				padding: 0.5lh 2ch;
				background-color: white;
				border: 1pt inset gray;
			}
			x-role { display: inline-block; }
			x-actor x-role, x-actor:hover x-role, x-actor x-person, x-actor:hover x-person { transition: opacity 1s linear; }
			x-actor:hover x-role { opacity: 0; }
			x-person { opacity: 0; }
			x-actor:hover x-person { opacity: 1; }
…

			<header>Erste Staffel</header>
			<x-episode>
				<header>
					<hgroup lang="en">
						<header>Robin Hood and the Sorcerer</header>
						<p>Part 1</p>
					</hgroup>
					<hgroup lang="de">
						<header>Der Magische Pfeil</header>
						<p>Teil 1</p>
					</hgroup>
				</header>
				<section>
					<p>Robin von Loxley und sein <x-actor><x-role>Cousin Much</x-role><x-person>Peter Llewellyn Williams</x-person></x-actor> werden wegen Wilderei verhaftet und in den Kerker gesperrt. Mit einer List gelingt die Flucht aus der Burg.</p>
					<p>Neben treuen Verbündeten - darunter Little John - lernt Robin zudem die bezaubernde <x-actor><x-role>Lady Marion</x-role><x-person>Judi Trott</x-person></x-actor> kennen.</p>
					<p class="XX…">Tief in den Wäldern trifft Robin später auf eine mystische Gestalt, die ihm seine wahre Bestimmung offenbart: Als Robin Hood, der Rächer der Unterdrückten, soll er fortan für die Armen und Schwachen kämpfen</p>
				</section>
				<footer>
					<p class="author">Richard Carpenter</p>
					<p class="director">Ian Sharp</p>
					<p>DEU 1984</p>
				</footer>
			</x-episode>

— [Das Daten-Orignal sei erwähnt](https://de.wikipedia.org/wiki/Robin_Hood_(Fernsehserie,_1984), soweit das mölich ist. Sprich. „der Rest“ stammt aus dem TV-EPG.

[nix]

Hoppla, da wollte / sollte, gleich vorne dran, noch etwas mehr mit:

			x-staffel, x-episode { display: grid list-item; }
			x-staffel {
				grid:
				"Überschrift" 1fr
				"Artikel" minmax(min-content, 1fr)
				/ 1fr;
			}
			x-staffel > header { grid-area: Überschrift; }
			x-staffel > x-episode { grid-area: Artikel; }
			x-episode {
				grid:
					"Titel" 1fr
					"Text" minmax(min-content, 3fr)
					"Details" minmax(min-content, 1fr)
					/ 1fr;
			}
			x-episode > header {
				grid-area: Titel;
				display: grid;
				grid:
					[sprachkonform] 1fr
					[fremdsprachig] 1fr
					/ 1fr;
			}

[Gunnar Bittersmann]

@@nix

Ein Nachteil von „Tooltips“ (oder was man auch so nennen mag), die ohne Programmierung, also nur mittels HTML + CSS realisiert werden: sie liegen fast immer, gut, sehr oft, an der falschen Stelle. Also so, daß sich ihr Inhalt, ganz oder teilweise, nicht im Blickfeld des Betrachters darstellt.

Du tust doch immer so, als wärst du auf dem allerneusten Stand. Bist du wohl doch nicht‽

Dann hab ich was für dich. Bzw. Una Kravets hat: Anchor positioning (ab 26:12)

Das ist einer der Nachteile der HTML/CSS-Architektur: ob man nun top-down oder bottom-up baut, irgendwo fehlen immer die Informationen bzw. Möglichkeiten, solche Dinge zu berücksichtigen.

Nö. Worüber du hier rumnölst, ist längst schon in Entwicklung.

🖖 Живіть довго і процвітайте

[Matthias Scharwies]

Servus!

Dann hab ich was für dich. Bzw. Una Kravets hat: Anchor positioning (ab 26:21)

Ja Wahnsinn!

Ich habe das Tutorial mal ergänzt: CSS/Tutorials/Tooltips_mit_CSS

Herzliche Grüße

Matthias Scharwies

[nix]

„Dann hab ich was für dich. Bzw. Una Kravets hat: Anchor positioning (ab 26:12)“ — Hmmm…

Fehler: Gesicherte Verbindung fehlgeschlagen

Beim Verbinden mit www.youtube.com trat ein Fehler auf. PR_END_OF_FILE_ERROR

Fehlercode: PR_END_OF_FILE_ERROR

    Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
    Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren.

?

[Rolf B]

Hallo nix,

das muss temporär gewesen sein oder dein Safari blockt das aus irgendeinem Grund ab. Ich habe den Link gerade noch einmal getestet, grundsätzlich funktioniert er.

Ansonsten such in YT mal nach "Una Kravets CSS Day 2023".

Rolf

[nix]

Od, der Fehler ist a) alt und b) eigentlich kein Fehler. Sondern nur ein eher sinnfreier Versuch, Google den einen oder anderen Datenkanal abzuzwicken. Und es ist (wegen dem sinnfreien des Versuchs) auch eine Leiche, die lange unbemerkt blieb: der Router mag manche Seiten nicht. — Und da die Reaktion nicht die eigentlich vorgesehene Sperr-Seite des Routers war, ist’s mir erst später aufgefallen

Die Fehlermeldung paßt nicht dazu? Ich denke: doch. Denn: trotz der Sperre im Router hatte ich bisher überhaupt kein Problem damit, Youtube-Coocies zu sammeln. Oder auch welche von ähnlich „begrabenen“ URLs: warum „letztens“ https so dringend „empfohlen“ wurde, hat mich nur kurz gewundert: SPI in Routern ist nur noch ein Werbeargument für „Doofe“. Mittlerweile noch weniger wert als die da oft erwähnte „Firewall“. Aka NAT.

[Rolf B]

Hallo nix,

uff, ich hoffe, du konntest die Leiche unauffällig und umweltgerecht entsorgen 😉…

Rolf