<li>-Bullet bei <ul> durch Pfeil ersetzen. Problem bei mehrzeiligen Listenelementen

[Bruno Thomann]

Problem: Ich möchte den Default-Bullet vor den <li> einer <ul> durch einen Pfeil ersetzen.

Das Problem scheint nicht ganz trivial zu sein. Pfeil als "::before"... geht nicht, Manuelles Einrücken der 2. Zeile müsste man mit Verzicht auf den automatischen Textumbruch erkaufen.

Ich habe mich bisher mit einer Tabelle mit einer 'Pfeilspalte' und einer 'Textspalte' statt einer <ul> beholfen …

Weiss jemand eine Lösung mit <ul>?

Herzlichen Dank!

[beatovich]

hallo

Problem: Ich möchte den Default-Bullet vor den <li> einer <ul> durch einen Pfeil ersetzen.

Das Problem scheint nicht ganz trivial zu sein. Pfeil als "::before"... geht nicht,

Komisch, bei mir geht's ;)

hast du https://wiki.selfhtml.org/wiki/CSS/Tutorials/Listen_mit_CSS_gestalten zur Kenntnis genommen?

[Bruno Thomann]

Danke Beat Habe natürlich als erstes wiki konsultiert. Die von Rolf (s.u.) angegebene Lösung ist dort allerdings nicht aufgeführt … Schönes Wochenende! Gruss Bruno

[Rolf B]

Hallo Bruno,

das mit dem ::before geht prinzipiell schon. Mit einem Unicode-Pfeil:

ul {
  padding-left: 3em;
}
li {
  position:relative;
  list-style-type: none;
}
li::before {
  content: "➞";
  position:absolute;
  left: -1em; top:0;
}

Das Problem ist, dass die meisten Pfeile zu hoch sind. Sind sie im <li> mit drin, wird es höher. Zieht man sie aus dem <li> heraus in ein ::before, stimmt die Ausrichtung nicht.

Du könntest einen Workaround mit Hilfe der text-indent Eigenschaft ausprobieren. Die kennt negative Werte und funktioniert sogar im IE11. Du musst den Pfeil dann nur in einen span setzen und dem ein display:inline-block verpassen.

Also so:

<ul>
<li><span>➞</span>Eins</li>
<li><span>➞</span>Eine lange Geschichte, das mit der Nummer zwei. 
Sie dauert und dauert und hat soviel Sinn wie ein Eiswürfel am Nordpol.</li>
</ul>

ul {
  padding-left: 2em;
}
li {
  list-style-type: none;
}
li span {
  display: inline-block;
  text-indent: -1.5em;
}

Ob das andere Nachteile hat, kann ich gerade nicht erkennen.

Es ist aber ein Workaround. Die richtige Lösung kommt erst noch und erlaubt die Angabe eines freien Listensymbols im CSS. Das kennt derzeit aber nur der Fuchs.

Rolf

[Bruno Thomann]

Herzlichen Dank, Rolf, für die ausführliche, ausgezeichnete und v.a. rasche Antwort! Schon die erste Version funktioniert tadellos. Von den Pfeilen geht der von Dir vorgeschlagene am besten. Ich habe es gar nicht mit Positionierungen und 'Content' versucht. Und Du hast sicher Recht. Da müsste mal etwas einfacheres kommen, die Frage stellen sich ja sicher viele. Und dass im CSS via Content Inhalte platziert werden statt im HTML, ist ja eigentlich unschön. Kann man eigentlich einen solchen Content auf einfache Weise einfärben, z.B. rot? Oder macht man zuerst die ganze Liste rot und die Listenelemente danach schwarz?

Nochmals herzlichen Dank! Bin immer wieder erfreut zu sehen, wie vorbehaltlos so viele 'Freiwilligenarbeit' für uns Gelegenheitsprogrammierer geleistet wird …

[Rolf B]

Hallo Bruno,

Du kannst dem ::before-Element eigentlich alle CSS Eigenschaften verpassen, die Du möchtest. Nicht alle sind sinnvoll, das ergibt sich dann aber von selbst. Z.B. wäre display:table Unfug, ein ::before::before würde auch nicht funktionieren.

color:red ist kein Problem. Farbverläufe als Background, Animationen, Schrift, Größe, Rahmen, geht alles.

Und dass im CSS via Content Inhalte platziert werden statt im HTML, ist ja eigentlich unschön.

Das kommt drauf an, danke dass Du das ansprichst. Inhalte gehören ins HTML. Aber diese Pfeile sind kein Inhalt (im Sinne von: Das vermittelt dem Leser Information), sondern Dekoration, und gehören deshalb ins CSS. D.h. die ::before-Lösung ist formal richtig, mit Formatierungsproblemen die ich nicht hinreichend universell gelöst bekommen habe. Für einen bestimmten Font könnte man die Pfeile wohl noch passend hinschieben, aber das kann man ja nicht voraussetzen.

Der Span-Workaround mit text-indent ist vom Prinzip her FALSCH! Eigentlich müsste der span noch ein aria-hidden="true" bekommen, damit ein Screen-Reader den Pfeil nicht vorzulesen versucht.

Eine bessere Lösung wäre vielleicht ein ::before mit leerem Content und einer gegebenen Breite, in der ein SVG-Pfeil steckt. Aber auch bei dem hat man das Problem, ihn sauber an der mittleren Orientierungslinie des für li verwendeten Font auszurichten.

Vielleicht hat ja einer der CSS Wizards hier noch eine bessere Idee (ein Teil davon sitzt gerade in Dortmund in der Mitgliederversammlung).

Rolf

[Bruno Thomann]

Nochmals vielen Dank! Natürlich, man muss dem ::before-Element die Farbe mitgeben, nicht dem content … Dann: Die Pfeile in einem Content als Hinweis, nicht als Inhalt, leuchtet ein, nur: Das ist eigentlich eine 'stillschweigende' (durchaus sinnvolle) Verabredung der Nutzer, oder? Zwischen die beiden " " kann ich ja auch die Bibel hineinschreiben, wenn ich wollte, oder zumindest einen wiederkehrenden Text. Schönes Wochenende! Bruno

[beatovich]

hallo

Hallo Bruno,

Du kannst dem ::before-Element eigentlich alle CSS Eigenschaften verpassen, die Du möchtest. Nicht alle sind sinnvoll, das ergibt sich dann aber von selbst. Z.B. wäre display:table Unfug, ein ::before::before würde auch nicht funktionieren.

es wurde mal ein ::before(2) vorgeschlagen.

Eine bessere Lösung wäre vielleicht ein ::before mit leerem Content und einer gegebenen Breite, in der ein SVG-Pfeil steckt. Aber auch bei dem hat man das Problem, ihn sauber an der mittleren Orientierungslinie des für li verwendeten Font auszurichten.

Es ist möglich:

https://beat-stoecklin.ch/pub/website_iconsets.html

Dateien dürfen frei benutzt werden.

[marctrix]

Hej Bruno,

Herzlichen Dank, Rolf, für die ausführliche, ausgezeichnete und v.a. rasche Antwort!

Schön, dass Rolf Dein Problem so schnell lösen konnte. Manchmal lässt sich ein Problem auch nicht so rasch oder gar nicht lösen. Daher wäre es nett, wenn du die hilfreiche Antwort als Lösung akzeptieren würdest (gibt dafür einen Button). Dann haben es andere mit einem ähnlichen Problem leichter die Antwort mit der Lösung zu finden. Auch du, wenn du die noch mal nachschlagen möchtest. 😉

Marc

[Gunnar Bittersmann]

@@Bruno Thomann

Weiss jemand eine Lösung mit <ul>?

Die Spec sieht vor, anstatt des Bulletzeichen auch Text verwenden zu können:

ul { list-style-type: '→ ' }

Im Firefox ist es implementiert, anderswo Fehlanzeige. [MDN]

Man kann auch ein Bild verwenden, das funktioniert browserübergreifend. Im Beispiel ein SVG als data-URL:

ul { list-style-image: url('data:image/svg+xml,%3Csvg%20viewBox%3D%220%200%20448%20512%22%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%3E%3Cpath%20d%3D%22m190.5%2066.9%2022.2-22.2c9.4-9.4%2024.6-9.4%2033.9%200l194.4%20194.3c9.4%209.4%209.4%2024.6%200%2033.9l-194.4%20194.4c-9.4%209.4-24.6%209.4-33.9%200l-22.2-22.2c-9.5-9.5-9.3-25%20.4-34.3l120.5-114.8h-287.4c-13.3%200-24-10.7-24-24v-32c0-13.3%2010.7-24%2024-24h287.4l-120.5-114.8c-9.8-9.3-10-24.8-.4-34.3z%22%2F%3E%3C%2Fsvg%3E') }

Pfeil von: Font Awesome Free 5.2.0 by @fontawesome - https://fontawesome.com
License - https://fontawesome.com/license (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License)

Die von Rolf gezeigte Möglichkeit ist aufwendig. Und auch eher ein Hack als eine Lösung.

LLAP 🖖

[Bruno Thomann]

Danke, Gunnar, für Deinen Alternativvorschlag. An ein list-style-image habe ich auch zuerst gedacht. Ich habe auch in einem anderen Projekt schon mal einen Pfeil.jpg selbst gemalt und verwendet, weil ich nie von einer externen Quelle abhängig sein möchte. Natürlich fällt damit alles mit ::before und positions weg, dafür bezahle ich mit zwei Nachteilen, wenn ich das richtig sehe: (1) Hintergrundfarbe des Pfeils bei Änderung der Seitenhintergrundfarbe (2) Verpixelung des Pfeils, wenn der Nutzer die Schriftgrösse vergrössert. Ich denke, man muss abwägen … Auch Dir ein schönes Wochenende! Bruno

[MudGuard]

Hi,

Danke, Gunnar, für Deinen Alternativvorschlag. An ein list-style-image habe ich auch zuerst gedacht. Ich habe auch in einem anderen Projekt schon mal einen Pfeil.jpg selbst gemalt und verwendet, weil ich nie von einer externen Quelle abhängig sein möchte. Natürlich fällt damit alles mit ::before und positions weg, dafür bezahle ich mit zwei Nachteilen, wenn ich das richtig sehe: (1) Hintergrundfarbe des Pfeils bei Änderung der Seitenhintergrundfarbe (2) Verpixelung des Pfeils, wenn der Nutzer die Schriftgrösse vergrössert.

Es hatte schon seinen Grund, daß Gunnar eine svg-Graphik verwendet hat, nicht ein jpeg.

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@Bruno Thomann

Danke, Gunnar, für Deinen Alternativvorschlag. An ein list-style-image habe ich auch zuerst gedacht. Ich habe auch in einem anderen Projekt schon mal einen Pfeil.jpg selbst gemalt und verwendet, weil ich nie von einer externen Quelle abhängig sein möchte. Natürlich fällt damit alles mit ::before und positions weg, dafür bezahle ich mit zwei Nachteilen, wenn ich das richtig sehe: (1) Hintergrundfarbe des Pfeils bei Änderung der Seitenhintergrundfarbe (2) Verpixelung des Pfeils, wenn der Nutzer die Schriftgrösse vergrössert.

Das zweite Problem löst sich bei Vektorgrafiken (SVG) in Luft auf. Der Pfeil skaliert mit der Schriftgröße und ist immer scharf.

In meinem naiven Glauben hatte ich gedacht, der Pfeil würde auch die Textfarbe annehmen. Dem ist aber nicht so; ein als Bild eingebundenes SVG lässt sich nicht von außen mit CSS stylen, auch fill="currentColor" beeindruckt das SVG nicht – alle Pfeile schwarz.

☞ Beispiel

Und Firefox scheint hier einen Bug zu haben: Mal sind die Pfeile zu sehen, dann wieder nicht …

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Und Firefox scheint hier einen Bug zu haben: Mal sind die Pfeile zu sehen, dann wieder nicht …

Bug-Ticket erstellt.

LLAP 🖖

[Rolf B]

Hallo Gunnar,

ich habe jetzt keine Lust, fontawesome zu studieren, um herauszufinden wie man von dort eine SVG Datei bekommt. Muss man da eine bezahltes Konto haben?

Und mein SVG ist wohl auch zu schwach belegt. Ich habe die URL mal in Chromes Adresszeile eingefügt und mir dann im Debugger das SVG Element angeschaut.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 448 512">
   <path d="m190.5 66.9 22.2-22.2c9.4-9.4 24.6-9.4 33.9 0l194.4 194.3c9.4 9.4 9.4 24.6 0 33.9l-194.4 194.4c-9.4 9.4-24.6 9.4-33.9 0l-22.2-22.2c-9.5-9.5-9.3-25 .4-34.3l120.5-114.8h-287.4c-13.3 0-24-10.7-24-24v-32c0-13.3 10.7-24 24-24h287.4l-120.5-114.8c-9.8-9.3-10-24.8-.4-34.3z"/>
</svg>

m190.5 66.9 - das verstehe ich noch. Ein relativer Move mit dx=190.5, dy=66.9. Aber was passiert dann? Es müsste ein neuer Path-Befehl kommen. Statt dessen kommt eine Art Subtraktion (die 0 ergibt) und dann erst ein Cubic-Befehl (c). Der braucht 3 Koordinatenpaare, durch Komma getrennt. Kommas sind keine zu sehen. Statt dessen wieder negative Zahlen, die ohne Space an anderen Zahlen dranhängen. Was ist das?

Und die zweite Frage: Wenn der Pfeil zu klein ist, wie skaliert man ihn?

Rolf

[beatovich]

hallo

etwas besser formatiert

m190.5 66.9 
l 22.2-22.2  // l ergänzt
c 9.4 -9.4 24.6 -9.4 33.9 0
l 194.4 194.3
c 9.4 9.4 9.4 24.6 0 33.9
l-194.4 194.4
c-9.4 9.4 -24.6 9.4 -33.9 0
l -22.2 -22.2
c-9.5 -9.5 -9.3 -25 .4 -34.3
l 120.5-114.8
h-287.4
c-13.3 0-24-10.7-24-24
v-32
c 0 -13.3 10.7 -24 24 -24
h 287.4
l-120.5 -114.8
c-9.8 -9.3 -10 -24.8 -.4 -34.3
z

Und die zweite Frage: Wenn der Pfeil zu klein ist, wie skaliert man ihn?

transform="scale(n,x0,y0)"

[Rolf B]

Hallo beatovich,

transform - aua. danke.

Ist l optional? Ist das Space vor einem Minus optional? Wusste ich bisher nicht.

Rolf

[beatovich]

hallo

Hallo beatovich,

transform - aua. danke.

Ist l optional? Ist das Space vor einem Minus optional? Wusste ich bisher nicht.

SVG beschreibt die Syntax Regeln, hab die Site aber nicht parat. Diese enthält einige Shorthand Regeln die einen Pfad unverständlich machen können.

eine Serie von lineto Folgen kann man etwa so schreiben.

l 10,2 -5,3 4,-5

Ich setze immer ein Komma zwischen x und y Komponenten.

[Gunnar Bittersmann]

@@Rolf B

§9.3 Path data in [SVG 2] und §8.3 Path data in [SVG 1.1] ist nun nicht so schwer zu finden.

Ist l optional?

In der Grammatik SVG 2 §9.3.9 bzw. SVG 1.1 §8.3.9:

moveto:
    ( "M" | "m" ) wsp* moveto-argument-sequence
moveto-argument-sequence:
    coordinate-pair
    | coordinate-pair comma-wsp? lineto-argument-sequence

Also: ja. (Dass lineto-argument-sequence dann als l und nicht als L gewertet wird, steht sicher auch noch irgendwo geschrieben.)

Ist das Space vor einem Minus optional?

“The processing of the BNF must consume as much of a given BNF production as possible, stopping at the point when a character is encountered which no longer satisfies the production. Thus, in the string "M 100-200", the first coordinate for the "moveto" consumes the characters "100" and stops upon encountering the minus sign because the minus sign cannot follow a digit in the production of a "coordinate". The result is that the first coordinate will be "100" and the second coordinate will be "-200".”

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

In der Grammatik SVG 2 §9.3.9 bzw. SVG 1.1 §8.3.9:

moveto:
    ( "M" | "m" ) wsp* moveto-argument-sequence
moveto-argument-sequence:
    coordinate-pair
    | coordinate-pair comma-wsp? lineto-argument-sequence

Das war aus [SVG 1.1]; in [SVG 2] steht’s etwas anders, kommt aber letzendlich auf das Gleiche hinaus.

Also: ja. (Dass lineto-argument-sequence dann als l und nicht als L gewertet wird, steht sicher auch noch irgendwo geschrieben.)

Da ha’m wa’s ja: “If a moveto is followed by multiple pairs of coordinates, the subsequent pairs are treated as implicit lineto commands. Hence, implicit lineto commands will be relative if the moveto is relative, and absolute if the moveto is absolute.”

LLAP 🖖

[Rolf B]

Hallo Gunnar,

hmpf, wenn man es weiß, findet man das sogar im Self Wiki

Rolf

[Matthias Scharwies]

Servus!

Und die zweite Frage: Wenn der Pfeil zu klein ist, wie skaliert man ihn?

transform="scale(n,x0,y0)"

Du kannst aber neben Transform (da gibt's sowohl was bei SVG: SVG/Transformationen als auch bei CSS: CSS/Eigenschaften/äußere Gestaltung/Transformationen auch die viewBox verändern:

• SVG/Tutorials/Einstieg/Grundformen

Hier wird eine 3x2 Pixel (besser: unitless numbers) große Grafik auf jede gewünschte Größe skaliert.

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Rolf B

ich habe jetzt keine Lust, fontawesome zu studieren, um herauszufinden wie man von dort eine SVG Datei bekommt. Muss man da eine bezahltes Konto haben?

Nein.

Font Awesome > Free > Github > advanced-options

Unter raw-svg findest du die Icons als einzelne SVGs. Die kannst du zu einer Sammlung zusammenstellen, indem du <svg> in <symbol> änderst.

Unter svg-sprites findest du fertige Sammlungen. Die haben aber ihre Dateigröße – da bietet sich auch an, nur diejenigen Icons herauszupicken, die man wirklich verwendet.

Und die zweite Frage: Wenn der Pfeil zu klein ist, wie skaliert man ihn?

So (in Safari).

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

… ein SVG als data-URL:

Und wenn man außen doppelte und innen einfache Anführungszeichen verwendet, muss man weniger escapen. Leerzeichen nicht, was den Quellcode deutlich lesbarer macht.

Optimizing SVGs in data URIs (Taylor Hunt)

LLAP 🖖

[Matthias Scharwies]

Servus!

@@Gunnar Bittersmann

… ein SVG als data-URL:

Und wenn man außen doppelte und innen einfache Anführungszeichen verwendet, muss man weniger escapen. Leerzeichen nicht, was den Quellcode deutlich lesbarer macht.

Optimizing SVGs in data URIs (Taylor Hunt)

Cool! Es gibt ja einige SVG-Encoder.

Das wäre aber der Anlass einen eigenen mit diesen Parametern zu entwickeln und unter den Helferlein zu posten.

Herzliche Grüße

Matthias Scharwies

[Bruno Thomann]

Danke an alle, die sich mit meinem Problem beschäftigen! Habe offensichtlich eine Mini-Lawine losgetreten, die sich in fundamentalere Gefilde zu bewegen scheint. Gefällt mir an sich, und das kommt in meiner Branche fast noch häufiger vor … Dennoch benötige ich jetzt eine kleine Bilanz. Wenn ich alles richtig verstanden haben, gibt es (aktuell) zwei Wege: (a) Rolf und sein 'Hack' (falls das einer wäre, wäre das eigentlich 'schlimm'?), relativ aufwendig, funktioniert aber. (b) Gunnar und sein SVG als Bullet-Ersatz. Strukturell einfacher und elegant, aber - wie mir scheint - mit einem noch immer ungelösten Problem, was die zu wählende Hintergrundfarbe des Pfeils innerhalb der Grafik betrifft (z.B. bei einem Farbverlauf im <body> …)

Daher also doch: ::before und Co. und warten, bis man den Bullet 'offiziell' frei ersetzen darf?

Nochmals Dank und noch schöner Sonntagabend.

[Rolf B]

Hallo Bruno,

die Hintergrundfarbe ist nicht das Problem, weil das SVG transparent ist.

die Vordergrundfarbe schaffe ich dagegen nicht zu setzen. Die Object URL scheint wie ein externes SVG behandelt zu werden, und das kann man nicht stylen.

Das Thema Größe ist mir trotz des Hinweises auf Transform auch immer noch unklar. Wie transformiere ich ein list-style-image?

Rolf

[beatovich]

hallo

Hallo Bruno,

die Hintergrundfarbe ist nicht das Problem, weil das SVG transparent ist.

die Vordergrundfarbe schaffe ich dagegen nicht zu setzen. Die Object URL scheint wie ein externes SVG behandelt zu werden, und das kann man nicht stylen.

Das Thema Größe ist mir trotz des Hinweises auf Transform auch immer noch unklar. Wie transformiere ich ein list-style-image?

you don't!

Ein list-style-image ist kein Element das du separat selektieren könntst.

Alle Transformationen haben wenn schon im SVG zu geschehen, relativ zu der eigenen svg viewBox

Mein eigener Versuch über

<view id="view1" viewBox="0 0 96 96"><use xlink:href="#p2"/></view>

und

list-style-image: url("../images/gui.svg#view1");

versagt aber kläglich (falsches Symbol), falsche Grösse.

Fazit: unbrauchbar.

[Gunnar Bittersmann]

@@Rolf B

Das Thema Größe ist mir trotz des Hinweises auf Transform auch immer noch unklar. Wie transformiere ich ein list-style-image?

::marker { font-size: 3em }

Demnächst vielleicht auch in Ihrem Browser.

LLAP 🖖

[Gunnar Bittersmann]

@@Bruno Thomann

(a) Rolf und sein 'Hack' (falls das einer wäre, wäre das eigentlich 'schlimm'?), relativ aufwendig, funktioniert aber.

Wenn du ein Unicode-Zeichen wie ➞ als Aufzählungszeichen verwenden möchtest, bist du mit Rolfs Hack wohl gegenwärtig noch am besten dran – solange, bis Browser list-style-type: <string> unterstützen. Für dieses Zeichen kannst du natürlich auch eine eigene Schriftart angeben.

Wenn du ein eigenes Icon verwenden willst, dann nicht PNG oder GIF, schon gar nicht JPEG, sondern dann ist SVG Mittel der Wahl.

(b) Gunnar und sein SVG als Bullet-Ersatz. Strukturell einfacher und elegant, aber - wie mir scheint - mit einem noch immer ungelösten Problem, was die zu wählende Hintergrundfarbe des Pfeils innerhalb der Grafik betrifft (z.B. bei einem Farbverlauf im <body> …)

Wie Rolf schon sagte, ist der Hintergrund gar kein Problem – der ist transparent.

Wenn du gar nichts angibst, ist die Vordergrundfarbe schwarz. fill="currentColor" war in meinem Beispiel zu Testzwecken drin; das bewirkt nichts, kann also weg.

Wenn du die Aufzählungszeichen in einer anderen Farbe haben möchtest, kannst du diese im SVG angeben, statt currentColor bspw. rebeccapurple oder eine HSL-, HSB- oder RGB-Angabe.

Problemtatisch wird’s erst, wenn das Aufzählungszeichen in verschieden Farben haben möchtest. Dann müsstest du für jede Farbe jeweils ein eigenes SVG angeben – obwohl doch die Kontur immer wieder dieselbe ist. Der Kompressionsalgorithmus holt bei der Übertragung des Stylesheets da zwar einiges raus, aber schön ist trotzdem anders.

LLAP 🖖

[Bruno Thomann]

Nochmals herzlichen Dank! Komisch: Ich habe das Gefühl, 'meine' Lösung mit einer Tabelle von vor 8 Jahren sei eigentlich gar nicht so schlecht gewesen … Gibt es unterdessen etwas Grundsätzliches, das dagegen spricht? Ich meine mitbekommen zu haben, dass Tabellen nicht mehr so 'in' seien, deshalb meine ursprüngliche Frage nach Listen.

HTML

<table class="menu">

     <tr><td>⭢</td><td>Kurzer Titel</td></tr>
     <tr><td>⭢</td><td>Ein langer Titel, braucht zwei Zeilen</td></tr>
     <tr><td>⭢</td><td>Das ist ein ganz besonders langer Titel, braucht drei Zeilen</td></tr>
     <tr><td>⭢</td><td>Titel mit Untertitel:
        <table>
           <tr><td>⭢</td><td>kurzer Untertitel</td></tr>
           <tr><td>⭢</td><td>ein sehr langer Untertitel</td></tr>
        </table>
     </td></tr>
</table>

CSS (Breite als Beispiel)

   .menu {width: 250px;}

   .menu td {vertical-align: top; padding: 0.3em;}

[Gunnar Bittersmann]

@@Bruno Thomann

Ich meine mitbekommen zu haben, dass Tabellen nicht mehr so 'in' seien

Und wenn sie doch Verwendung finden sollten, dann sollten sie zumindest als Layouttabellen gekennzeichnet sein:

<table role="none presentation">

deshalb meine ursprüngliche Frage nach Listen.

Wenn du vorhast, den Pfeil mit ins Markup zu bringen, kannst das auch mit Listen tun: <ul> anstatt <table>; <li> anstatt <tr>; <span class="marker"> anstatt <td>.

<ul class="menu">
	<li><span class="marker">→</span> Kurzer Titel</li>
	<li><span class="marker">→</span> Ein langer Titel, braucht zwei Zeilen</li>
	<li><span class="marker">→</span> Das ist ein ganz besonders langer Titel, braucht drei Zeilen</li>
	<li><span class="marker">→</span> Titel mit Untertitel:
		<ul>
			<li><span class="marker">→</span> kurzer Untertitel</li>
			<li><span class="marker">→</span> ein sehr langer Untertitel</li>
		</ul>
	</li>
</ul>

Die Bullets machst du mit .menu, .menu ul { list-style: none } weg. Das Tabellenlayout könntest du umsetzen mit

.menu, .menu ul { display: table }
.menu li { display: table-row }
.marker {display: table-cell }

Die Pfeile sind in der Textfarbe ihres jeweiligen Listenitems, siehe Beispiel 1

Wenn du vorhast, den Pfeil mit ins Markup zu bringen, dann kannst auch SVG so verwenden, wie ich unlängt schrieb: ein SVG (intern oder extern) mit <symbol>s und anstelle von <span class="marker">→</span> steht dann <svg><use xlink:href="#arrow-right"/></svg>.

<ul class="menu">
	<li><svg><use xlink:href="#arrow-right"/></svg>Kurzer Titel</li>
	<li><svg><use xlink:href="#arrow-right"/></svg>Ein langer Titel, braucht zwei Zeilen</li>
	<li><svg><use xlink:href="#arrow-right"/></svg>Das ist ein ganz besonders langer Titel, braucht drei Zeilen</li>
		<ul>
			<li><svg><use xlink:href="#arrow-right"/></svg>kurzer Untertitel</li>
			<li><svg><use xlink:href="#arrow-right"/></svg>ein sehr langer Untertitel</li>
		</ul>
	</li>
</ul>

Auch dann sind die Pfeile in der Textfarbe ihres jeweiligen Listenitems, siehe Beispiel 2

LLAP 🖖

[Bruno Thomann]

Danke, Gunnar, für diese geniale Version. Hab's erst jetzt gesehen. Auf so etwas käme ich nie. Aber das ist wohl der Unterschied zwischen den Profis und uns Gelegenheitsprogrammierern …

Noch etwas: Du hat auch ein Talent, dich in unser beschränktes Wissen und Können einzudenken und die Dinge entsprechend verständlich zu erklären. Das ist nicht immer so. Oftmals sieht man, wie eine für den 'Verzweifelten' dunkle Sache schlicht mit einer noch dunkleren erklärt wird …

Letzte Frage, nicht dringlich, nur aus prinzipiellem Interesse: Warum sind Tabellen so in Verruf geraten, wie es scheint?

[marctrix]

Hej Bruno,

Letzte Frage, nicht dringlich, nur aus prinzipiellem Interesse: Warum sind Tabellen so in Verruf geraten, wie es scheint?

Sie sind schlciht umständlicher zu handeln als moderne Techniken wie flexbox oder Grid. Selbst Layouts mit float waren leichter responsiv umsetzbar als Tabellen-Layouts.

Außerdem blähen Tabellen den Quellcode auf, sind semantisch nicht das an der Stelle benötigte Element (wenn sie aus Layout-Gründen verwendet werden) und bedürfen der extra-Behandlung um im barrierefreien Umfeld nicht zu stören (role="presentation").

Man muss auch darauf achten, dass die in Tabellen dargestellten Inhalte linearisierbar sind, das heißt sie müssen linear gelesen (von links nach rechts, Zeile für Zeile) sinn ergeben, weil das genau die Reihenfolge ist, die Screenreader ausgeben.

Beispiel für Öffnungszeiten:

| Montag | Dienstag | Mittwoch | Donnerstag | Freitag | |vorm. | nachm. | vor- und nachm.| vorm.|nachm. |

würde wie folgt vorgelesen:

Montag, Dienstag, Mittwoch, Donnerstag, Freitag, vorm., nachm., vor- und nachm., vorm., nachm.

Das ist natürlich vollkommen unverständlich…

Marc

[Bruno Thomann]

Danke! Leuchtet sehr ein.

[Auge]

Hallo

Letzte Frage, nicht dringlich, nur aus prinzipiellem Interesse: Warum sind Tabellen so in Verruf geraten, wie es scheint?

Tabellen wurden über Jahr(zehnt)e hinweg für das Layout von Webseiten benutzt [edit]um Seitenelemente in einem Raster anzuordnen[/edit], weil [edit]dafür[/edit] keine andere Technik verfügbar war. Nun sind andere Techniken da, in der neueren Zeit mit Grid auch eine explizit dafür vorgesehene, aber viele Seiten benutzen immer noch Tabellen zu diesem Zweck. Das wird an vielen Stellen gebetsmühlenartig bemängelt. Dass Tabellen immer noch als Layoutmittel gefunden und verwendet werden, mag daran liegen, dass viele Seiten seit Jahr und Tag nicht überarbeitet wurden und auch daran, dass sich viele Ersteller von Webseiten nur schwerfällig von eingefahrenen Gleisen herunterbegeben.

Aber, um zu verhindern, dass das Kind mit dem Bade ausgeschüttet wird, sei gesagt, dass Tabellen keineswegs per se verteufelt werden. Für die Darstellung tabellarischer Daten sind und bleiben sie nämlich das einzig geeignete Werkzeug.

Tschö, Auge

[Bruno Thomann]

Danke! Sehr informativ!

[Gunnar Bittersmann]

@@Bruno Thomann

Danke, Gunnar, für diese geniale Version. Hab's erst jetzt gesehen. Auf so etwas käme ich nie. Aber das ist wohl der Unterschied zwischen den Profis und uns Gelegenheitsprogrammierern …

Zum Unterschied zwischen Anfänger, Fortgeschrittenem und Profi hier entlang. 😄

Noch etwas: Du hat auch ein Talent, dich in unser beschränktes Wissen und Können einzudenken und die Dinge entsprechend verständlich zu erklären.

Vielen Dank für die Blumen … wie lieb von dir.

Letzte Frage, nicht dringlich, nur aus prinzipiellem Interesse: Warum sind Tabellen so in Verruf geraten, wie es scheint?

Vom Unfug der falschen Semantik bei der Auszeichnung (was man mit role="none presentation" entkräften könnte) abgesehen, wird es schwer, mit Layouttabellen responsives Design hinzubekommen. Es ist möglich, Tabellenzellen auf schmalen Viewports anders anzuordnen (Beispiel: responsive table), aber besser ist schon, unpassende CSS-Eigenschaften gar nicht erst zu setzen als sie hinterher wieder zurückzusetzen.

LLAP 🖖

[marctrix]

Hej Bruno,

Danke an alle, die sich mit meinem Problem beschäftigen! Habe offensichtlich eine Mini-Lawine losgetreten, die sich in fundamentalere Gefilde zu bewegen scheint.

Und noch ist nciht alles bedacht 😂

Sorry, sehe das jetzt erst. Die Hintergrundfarbe ist ein Problem, gerade wegen der Transparenz. Was passiert denn mit einem schwarzen Pfeil auf schwarzem Hintergrund? - Eben: er wird unsichtbar. Nutzer mit Blendempfindlichkeit machen sich die Hintergründe von Webseiten dunkel.

Grafiken verschwinden dann in zwei Fällen:

1. es handelt sich um eine Hintergrundgrafik. Da diese die gewählte Hintergrundfarbe überlagern würden, werden Hintergrundgrafiken bei eigenen Farben ignoriert (also schlicht nicht angezeigt)
2. Grafiken sind transparent und die eingestellte Hintergrundfarbe ist ähnlich oder identisch mit dem Symbol

Man sollte also gerade keine Transparenz in seinen Bildern verwenden oder dafür sorgen, dass sich mit der Hintergrundfarbe auch die Farbe des Icons ändert. Das lässt sich nicht machen, aber ich gehe mal davon aus, dass jemand, der eine eigene Hintergrundfarbe verwendet, auch eine eigene Schriftfarbe verwendet. Sondern wären ja alle Texte schwarz auf schwarz und damit unsichtbar.

Wenn er sich nun eine hellere Schriftfarbe einstellt, sollte sich die auch auf das Icon auswirken. So wird das wieder sichtbar.

Also ist die Lösung von Rolf hier eine der besseren, trotz Hack-Charakter — anders geht es IMHO nur folgendermaßen: man könnte ein inline-SVG nehmen und im CSS mit fill: currentColor; sicherstellen, dass das Symbol dieselbe Farbe hat wie der Text.

Marc

[beatovich]

hallo

Hej Bruno,

Danke an alle, die sich mit meinem Problem beschäftigen! Habe offensichtlich eine Mini-Lawine losgetreten, die sich in fundamentalere Gefilde zu bewegen scheint.

Und noch ist nciht alles bedacht 😂

Sorry, sehe das jetzt erst. Die Hintergrundfarbe ist ein Problem, gerade wegen der Transparenz. Was passiert denn mit einem schwarzen Pfeil auf schwarzem Hintergrund? - Eben: er wird unsichtbar. Nutzer mit Blendempfindlichkeit machen sich die Hintergründe von Webseiten dunkel.

Hast du das mal schwarz auf weiss?

Es wäre nämlich ein ziemlich disparates Unternehmen, Farb-Sichtprobleme dadurch zu lösen, dass man einzelne Componenten einer Website manipuliert.

Aber die Essenz deines Einwands ist: Wann immer man eine Vordergrundfarbe definiert, soll man auch den Hintergrund kontrollieren. Das ist kein Argument gegen transparente Hintergründe, solange man den übergeordneten Hintergrund kontrolliert.

[marctrix]

Hej beatovich,

hallo

Hej Bruno,

Danke an alle, die sich mit meinem Problem beschäftigen! Habe offensichtlich eine Mini-Lawine losgetreten, die sich in fundamentalere Gefilde zu bewegen scheint.

Und noch ist nciht alles bedacht 😂

Sorry, sehe das jetzt erst. Die Hintergrundfarbe ist ein Problem, gerade wegen der Transparenz. Was passiert denn mit einem schwarzen Pfeil auf schwarzem Hintergrund? - Eben: er wird unsichtbar. Nutzer mit Blendempfindlichkeit machen sich die Hintergründe von Webseiten dunkel.

Hast du das mal schwarz auf weiss?

Du meinst als Link?

Es wäre nämlich ein ziemlich disparates Unternehmen, Farb-Sichtprobleme dadurch zu lösen, dass man einzelne Componenten einer Website manipuliert.

Ist dennoch recht weit verbreitet Hintergrund und Schriftfarbe anzupassen. Ist schließlich eine der einfachsten Anpassungen, da Browser so was von haus aus anbieten.

Aber die Essenz deines Einwands ist: Wann immer man eine Vordergrundfarbe definiert, soll man auch den Hintergrund kontrollieren. Das ist kein Argument gegen transparente Hintergründe, solange man den übergeordneten Hintergrund kontrolliert.

Du meinst damit den dahinterliegenden? Dem Argument liegt die irrige Annahme zugrunde, dass ein Autoren-Stylesheet mehr ist als eine Empfehlung. Das hat was mit der Kaskade zu tun.

Die Reihenfolge ist

1. Browser-Styles
2. Autoren-Styles
3. Nutzer-Styles

Je höher die Nummer, desto eher setzen sich die Angaben durch. Sonst würden Nutzer-Stylesheets nicht funktionieren (es gab mal eine Zeit, da hat !important im Autoren-Stylesheet das verhindert, aber das ist glücklicherweise Schnee von gestern).

Marc

[Gunnar Bittersmann]

@@marctrix

Die Reihenfolge ist

1. Browser-Styles
2. Autoren-Styles
3. Nutzer-Styles

Nein.

Je höher die Nummer, desto eher setzen sich die Angaben durch. Sonst würden Nutzer-Stylesheets nicht funktionieren (es gab mal eine Zeit, da hat !important im Autoren-Stylesheet das verhindert, aber das ist glücklicherweise Schnee von gestern).

Da irrst du. Eine !important-Deklaration im Autorenstylesheet überschreibt eine normale Deklation aus dem Nutzerstylesheet.

CSS 2.2 §6.4.1 Cascading order:

1. user agent declarations
2. user normal declarations
3. author normal declarations
4. author important declarations
5. user important declarations

In Level 3 ist da noch einiges hinzugekommen:

1. Normal user agent declarations
2. Normal user declarations
3. Normal author declarations
4. Animation declarations
5. Important author declarations
6. Important user declarations
7. Important user agent declarations
8. Transition declarations

(in die vorher verwendete Reihenfolge gebracht)

LLAP 🖖

[marctrix]

Hej Gunnar,

@@marctrix

Die Reihenfolge ist

1. Browser-Styles
2. Autoren-Styles
3. Nutzer-Styles

Nein.

Na ja, es ist nicht vollständig…

Je höher die Nummer, desto eher setzen sich die Angaben durch. Sonst würden Nutzer-Stylesheets nicht funktionieren (es gab mal eine Zeit, da hat !important im Autoren-Stylesheet das verhindert, aber das ist glücklicherweise Schnee von gestern).

Da irrst du. Eine !important-Deklaration im Autorenstylesheet überschreibt eine normale Deklation aus dem Nutzerstylesheet.

Echt? - Das ist komisch, ich dachte immer die in den Einstellungen gemachten Angaben würden als User-CSS realisiert. Ist das dann vielleicht gar nicht so?

Habe einen Test-Pen für Farben mit !important erstellt, in dem das mir bekannte und oben beschriebene Verhalten bestätigt wird…

In Level 3 ist da noch einiges hinzugekommen:

1. Normal user agent declarations
2. Normal user declarations
3. Normal author declarations
4. Animation declarations
5. Important author declarations
6. Important user declarations
7. Important user agent declarations
8. Transition declarations

Ich sehe, das muss ich mir noch mal anschauen und rausfinden, welche Browser das so umsetzen und wieso sich Farbangaben in Browsern (welchen?) dann nicht daran halten (offenbar ist das dann eben kein User-Stylesheet?!?)…

Hier noch etwas zu den Transparenzen: man stelle sich vor, das weiß in Gunnars Icon wäre nicht weiß, sondern transparent (in der annahme, dass der Hintergrund weiß ist). Oder überlegt mal, wie beat auf einem grauen Hintergrund aussähe. es bliebe nur ein Kreis, der ohne das darunter wohl niemanden an einen Kopf erinnern würde…

Icons sollten keine Transparenzen haben.

Es sei denn, sie verhalten sich wie Schrift. Siehe das Codepen-Icon (Codepen baut dann allerdings bei den Buttons unten Mist).

Funfact: FF bekommt es selber ausgerechnet da nicht hin, wo man eigenen Farben einstellen kann…

Ich sach ja immer: schlecht sehende Menschen zu unterstützen ist viel schwieriger, als blinde Menschen zu unterstützen!

Schaut euch auch mal die alt-Texte zu den hier geposteten Bildern an… 😉

Marc

[beatovich]

hallo

Icons sollten keine Transparenzen haben.

Icons sollten für zwei Szenarien vorliegen:

• dunkel auf hell
• hell auf dunkel

Man kann die grauen Körper des Profil-Icons bemängeln. Da fehlt ein klarer Stroke im SVG.

[marctrix]

Hej beatovich,

hallo

Icons sollten keine Transparenzen haben.

Icons sollten für zwei Szenarien vorliegen:

• dunkel auf hell
• hell auf dunkel

Warum? Heydon Pickering beispielsweise bittet ausdrücklich um leicht abgedunkelte (also graue bis hellgraue) Hintergründe, weil es ihn dann bereits nicht mehr so unangenehm blendet wie reines weiß.

So etwas kann sich ja auch entwicklen und am Beginn so einer Entwicklung steht nicht, sich in einen schwarzen Raum einzuschließen, sondern eine sonnebrille mit leichter Tönung zu nutzen.

Wir können und dürfen Nutzern nicht vorschreiben, dass sie nur zwischen zwei Optionen zu wählen haben, wenn eine Webseite für alle bedienbar sein soll (und das sollte sie - warum freiwillig auf einen teil der Besucher verzichten oder ihnen ein unangenehmes Erlebnis liefern. sie sollen ja gerne wieder kommen aufgrund positiver Erfahrunegn — wo wir wieder mal bei den wirtschaftliche nAspekten von inklusivem Design wären)…

Man kann die grauen Körper des Profil-Icons bemängeln. Da fehlt ein klarer Stroke im SVG.

Finde ich persönlich hässlicher als ein weißer Hintergrund für die normal-Darstellung auf weißem Hintergrund. Bei umgekehrten Farben mag es dann weniger ästhetisch aussehen, das betrifft aber nciht nur viel weniger Leute, es ist auch praktisch unmöglich bei den 16,8 Millionen Möglichkeiten für hintergrundfarben immer ein ästhetisch einwandfreies Ergebnis sicherzustellen. Darauf kommt es ja bei so einer Darstellung auch nicht mehr so sehr an, sondern auf gute Erkennbarkeit. Und der Stroke würde es auch in der Darstellung mit eigenen Farben IMHO hässlicher machen.

Aber über Geschmack lässt sich cniht streiten. In einem Flat-Design-konzept würden die allerdings das gesamte Konzept kaputt machen…

Marc

[beatovich]

hallo

Hej beatovich,

hallo

Icons sollten keine Transparenzen haben.

Icons sollten für zwei Szenarien vorliegen:

• dunkel auf hell
• hell auf dunkel

Warum? Heydon Pickering

der auch nur eine subjektive unausgegorene Meinung verbreitet.

... beispielsweise bittet ausdrücklich um leicht abgedunkelte (also graue bis hellgraue) Hintergründe, weil es ihn dann bereits nicht mehr so unangenehm blendet wie reines weiß.

Lass ihn die Helligkeitstaste seines Bildschirms entdecken. Kontrast einschränken ist leicht möglich. Einen bereits eingeschränkten Kontrast wieder zu erweitern, nicht so leicht.

Aber du darfst natürlich auch grau auf grau... ;)

[marctrix]

Hej beatovich,

Icons sollten keine Transparenzen haben.

Icons sollten für zwei Szenarien vorliegen:

• dunkel auf hell
• hell auf dunkel

Warum? Heydon Pickering

der auch nur eine subjektive unausgegorene Meinung verbreitet.

Selbst wenn du dich in der Materie, in der er ein ausgewiesener Fachmann ist, ebenso gut auskennen würdest wie er, wäre ein Begründung dieser Aussage nötig.

allerdings spielt das für meine Argumentation keine rolle. Bitte lies doch noch mal meinen letzten Beitrag und verstehe ihn, statt hier auf Nebensächlichkeiten rumzureiten.

Pickering ist nur ein (prominentes) Beispiel für eine Persona…

... beispielsweise bittet ausdrücklich um leicht abgedunkelte (also graue bis hellgraue) Hintergründe, weil es ihn dann bereits nicht mehr so unangenehm blendet wie reines weiß.

Lass ihn die Helligkeitstaste seines Bildschirms entdecken.

Oder CSS lernen oder die n Einstellungen seines Browsers konfigurieren oder was auch immer.

Seine Entscheidung.

Du baust Webseiten in in jedem Fall funktionieren oder eben schlechte.

Deine Entscheidung!

Aber du darfst natürlich auch grau auf grau... ;)

Irgendwie stellst du dich dumm um zu trollen oder ich weiß auch nicht, was das soll. Es ist vollkommen ok und kein bisschen lächerlich, wenn ich schwarz auf grau möchte. Der Webseitenbetreiber bzw. Entwickler (also im Zweifelsfall du) muss dafür sorgen, dass die Icons dann nicht grau auf grau sind. Hatte ich das nicht deutlich genug gesagt? Wo ist Dein Verständnis-Problem?

Marc

[Auge]

Hallo

Icons sollten für zwei Szenarien vorliegen:

• dunkel auf hell
• hell auf dunkel

Lass ihn die Helligkeitstaste seines Bildschirms entdecken.

Dann dunkelt er eine Seite ab und hat graue Schrift (und Icons) auf dunklem Grund oder dunkelgraue/schwarze Schrift (und Icons) auf grauem Grund ^[1]. In jedem Fall hat er ein kontrastärmeres Ergebnis als es das Original hergibt. Es wird ja schließlich alles auf dem Bildschirm heller beziehungsweise dunkler.

Kontrast einschränken ist leicht möglich. Einen bereits eingeschränkten Kontrast wieder zu erweitern, nicht so leicht.

Was machst du denn anderes, als den Kontrast einzuschränken, wenn du am Bildschirm Helligkeit wegnimmst?

Aber du darfst natürlich auch grau auf grau... ;)

… sagt der, der genau das empfiehlt.

Tschö, Auge

---

1. Du darfst die angegebenen Farben aus gegen andere austauschen. ↩︎

[beatovich]

hallo

Was machst du denn anderes, als den Kontrast einzuschränken, wenn du am Bildschirm Helligkeit wegnimmst?

Das entscheidende ist, dass du dir selber Kontrast/Helligkeit anpassen kannst, und nicht einen von mir vorsätzlich eingeschränkten Kontrast im CSS bekommst.

[marctrix]

Hej beatovich,

Was machst du denn anderes, als den Kontrast einzuschränken, wenn du am Bildschirm Helligkeit wegnimmst?

Das entscheidende ist, dass du dir selber Kontrast/Helligkeit anpassen kannst, und nicht einen von mir vorsätzlich eingeschränkten Kontrast im CSS bekommst.

Das bedeutet, du propagierst, dass Webseiten nur schwarze Texte auf weißem Grund anbieten dürfen? Hast du eine einzige Website als Beispiel, bei der du dich selber an diese Regel gehalten hast?

Es gibt objektive Kriterien für ausreichende Kontraste, die dem deiner Meinung nach subjektiv und unausgegoren argumentierenden Heydon Pickering bekannt sind und an die er sich in all seinen Artikeln und Empfehlungen hält.

Marc

[beatovich]

hallo

Hej beatovich,

Was machst du denn anderes, als den Kontrast einzuschränken, wenn du am Bildschirm Helligkeit wegnimmst?

Das entscheidende ist, dass du dir selber Kontrast/Helligkeit anpassen kannst, und nicht einen von mir vorsätzlich eingeschränkten Kontrast im CSS bekommst.

Das bedeutet, du propagierst, dass Webseiten nur schwarze Texte auf weißem Grund anbieten dürfen? Hast du eine einzige Website als Beispiel, bei der du dich selber an diese Regel gehalten hast?

Nein, ich propagiere eben nicht, dass #fff eine verbotene Background-Farbe ist.

[Auge]

Hallo

Nein, ich propagiere eben nicht, dass #fff eine verbotene Background-Farbe ist.

Das tut auch niemand anderes. Also warum stellst du hier eine solch hanebüchene Behauptung in den Raum?

Tschö, Auge

[beatovich]

hallo

Hallo

Nein, ich propagiere eben nicht, dass #fff eine verbotene Background-Farbe ist.

Das tut auch niemand anderes. Also warum stellst du hier eine solch hanebüchene Behauptung in den Raum

Zitat marctrix

Warum? Heydon Pickering beispielsweise bittet ausdrücklich um leicht abgedunkelte (also graue bis hellgraue) Hintergründe,

[Auge]

Hallo

Nein, ich propagiere eben nicht, dass #fff eine verbotene Background-Farbe ist.

Das tut auch niemand anderes. Also warum stellst du hier eine solch hanebüchene Behauptung in den Raum

Zitat marctrix

Warum? Heydon Pickering beispielsweise bittet ausdrücklich um leicht abgedunkelte (also graue bis hellgraue) Hintergründe,

Meine Güte! Ist dir der Unterschied zwischen einer Bitte und einem Verbot nicht geläufig?

Tschö, Auge

[Auge]

Hallo

Was machst du denn anderes, als den Kontrast einzuschränken, wenn du am Bildschirm Helligkeit wegnimmst?

Das entscheidende ist, dass du dir selber Kontrast/Helligkeit anpassen kannst, und nicht einen von mir vorsätzlich eingeschränkten Kontrast im CSS bekommst.

Das kann ich mit einem User-CSS auch und zudem sehr viel besser und feiner granuliert.

Wenn ich den Bildschirm dunkler mache, weil mich der weiße Hintergrund einer Seite/eines Fensers blendet, wird eben nicht nur der Hintergrund dunkler, sondern, soweit es geht, auch Schrift und Bilder. Ist mir eine Seite/ein Fenster zu dunkel und ich erhöhe ich die Helligkeit des Bildschirms wird nicht nur der Hintergrund heller, sondern auch die Schrift und die Bilder. In jedem Fall sinkt der Kontrast und in vielen Fällen ist das nicht erwünscht.

Die Fälle von eingeschränkter Farbwahrnehmung sind mit deinem Vorschlag gleich garnicht sinnvoll zu lösen.

Tschö, Auge

[beatovich]

hallo

Die Fälle von eingeschränkter Farbwahrnehmung sind mit deinem Vorschlag gleich garnicht sinnvoll zu lösen.

Welche Einschränkung soll ich präferieren?

[Auge]

Hallo

Die Fälle von eingeschränkter Farbwahrnehmung sind mit deinem Vorschlag gleich garnicht sinnvoll zu lösen.

Welche Einschränkung soll ich präferieren?

Du sollst keine Einschränkung präferieren oder gar auf eine hin optimieren. Der sinngemäß zitierte Spruch eine Optimierung auf ein Ziel hin ist eine Verschlechterung für alle Anderen ist hier ja wohl bekannt.

Es war dein Vorschlag, die Helligkeit des Bildschirms zu verändern, das wäre quasi die Lösung „für alles“™️. Das ist es aber nicht. Wenn ich bestimmte Teile einer Website farblich verändern muss, damit ich sie wahrnehmen kann, nützt mir eine Helligkeitsänderng mit der damit einhergehenden Kontrastverringerung nullkommanix. Dass das auch mit einem User-CSS alles andere als trivial ist, sei mal dahingestellt. Jedenfalls ist deine Lösung keine Lösung.

Tschö, Auge

[beatovich]

hallo

Hallo

Die Fälle von eingeschränkter Farbwahrnehmung sind mit deinem Vorschlag gleich garnicht sinnvoll zu lösen.

Welche Einschränkung soll ich präferieren?

Du sollst keine Einschränkung präferieren oder gar auf eine hin optimieren. Der sinngemäß zitierte Spruch eine Optimierung auf ein Ziel hin ist eine Verschlechterung für alle Anderen ist hier ja wohl bekannt.

einverstanden.

Also zurück zum Urprung, bovor Pickerings Schatten aufgekreuzt ist.

Ich habe gesagt, man sollte am besten 2 iconsets vorplanen.

Das bringt mich übrigens zum Gedanken, dass ich diese einfach austauschen kann, wenn sie nicht über svg/use eingebunden sind.

Darf man sich auch mal Gedanken dazu machen.

[Gunnar Bittersmann]

@@beatovich

Warum? Heydon Pickering

der auch nur eine subjektive unausgegorene Meinung verbreitet.

Auf das Getrolle haben Marc und Auge schon genug gesagt.

Lass ihn die Helligkeitstaste seines Bildschirms entdecken.

Schwarz auf grau (wenig Kontrast, aber viel Licht) ist was anderes als weiß auf schwarz/dunkelgrau (hoher Kontrast, wenig Licht), wie ich es bei dunkler Umgebung wünsche.

Wo das helle Licht andere stören würde, zum Beispiel beim Twittern im Theater, beim Konzert o.ä. Das macht man doch nicht, könnte jetzt jemand einwerfen. Doch, manchmal schon: #ElisabethMusical, #TIPIcabaret #tweetup

LLAP 🖖

[beatovich]

hallo

@@beatovich

Warum? Heydon Pickering

der auch nur eine subjektive unausgegorene Meinung verbreitet.

Auf das Getrolle haben Marc und Auge schon genug gesagt.

Lass ihn die Helligkeitstaste seines Bildschirms entdecken.

Schwarz auf grau (wenig Kontrast, aber viel Licht) ist was anderes als weiß auf schwarz/dunkelgrau (hoher Kontrast, wenig Licht), wie ich es bei dunkler Umgebung wünsche.

Wo das helle Licht andere stören würde, zum Beispiel beim Twittern im Theater, beim Konzert o.ä. Das macht man doch nicht, könnte jetzt jemand einwerfen. Doch, manchmal schon: #ElisabethMusical, #TIPIcabaret #tweetup

Ich kann dir das anbieten

		<style>
		.browsercolors {background-color:initial !important; color: initial !important;}
		.browsercolors *:not(a) { color: inherit !important;}
		.browsercolors * { background-color:inherit !important; border-color:#666 !important;}
		</style>
		<button onclick="document.documentElement.classList.contains('browsercolors') 
			? document.documentElement.classList.remove('browsercolors')

Hoffentlich macht's dein Browser besser als Firefox, Und hoffentlich bist du für die dunkle Twitterstunde vorbereitet.

[beatovich]

hallo

Hej beatovich,

hallo

Hej Bruno,

Danke an alle, die sich mit meinem Problem beschäftigen! Habe offensichtlich eine Mini-Lawine losgetreten, die sich in fundamentalere Gefilde zu bewegen scheint.

Und noch ist nciht alles bedacht 😂

Sorry, sehe das jetzt erst. Die Hintergrundfarbe ist ein Problem, gerade wegen der Transparenz. Was passiert denn mit einem schwarzen Pfeil auf schwarzem Hintergrund? - Eben: er wird unsichtbar. Nutzer mit Blendempfindlichkeit machen sich die Hintergründe von Webseiten dunkel.

Hast du das mal schwarz auf weiss?

Du meinst als Link?

Nein, ich meinen einen Beleg für

Nutzer mit Blendempfindlichkeit machen sich die Hintergründe von Webseiten dunkel.

Du musst ja verstehen, jemand mit so einem Problem hat ein generelles problem, für welches man besser eine Grafikkarte manipuliert.

Ist dennoch recht weit verbreitet Hintergrund und Schriftfarbe anzupassen. Ist schließlich eine der einfachsten Anpassungen, da Browser so was von haus aus anbieten.

Ja, immer mehr über die Leseansicht, und da brauch mich mein CSS gar nicht mehr zu kümmern.

[Gunnar Bittersmann]

@@beatovich

Nutzer mit Blendempfindlichkeit machen sich die Hintergründe von Webseiten dunkel.

Du musst ja verstehen, jemand mit so einem Problem hat ein generelles problem,

Nein, die Beeinträchtigung kann auch situationsbedingt sein. (Folie 7)

Bei geringer Umgebungshelligkeit möchte ich ein dunkles UI – helle Schrift auf dunklem Grund. Meine Twitter-App stelle ich ständig um; wünsche mir das auch für SELFHTML.

für welches man besser eine Grafikkarte manipuliert.

?? Wenn ich ich helle Schrift auf dunklem Grund haben will, heißt das nicht, dass ich Fotos als Negativ zu sehen bekommen möchte.

LLAP 🖖

[beatovich]

hallo

Bei geringer Umgebungshelligkeit möchte ich ein dunkles UI – helle Schrift auf dunklem Grund. Meine Twitter-App stelle ich ständig um; wünsche mir das auch für SELFHTML.

Gibt es kein User-CSS mehr?

[Matthias Apsel]

Hallo beatovich,

Bei geringer Umgebungshelligkeit möchte ich ein dunkles UI – helle Schrift auf dunklem Grund. Meine Twitter-App stelle ich ständig um; wünsche mir das auch für SELFHTML.

Gibt es kein User-CSS mehr?

Das wäre aber nicht benutzerfreundlich. Für edge auf Laptops ginge light-level. Ob das wirklich klug ist, die Kamera immer eingeschaltet zu haben, ist eine ganz andere Frage.

Bis demnächst
Matthias

[beatovich]

hallo

Hallo beatovich,

Bei geringer Umgebungshelligkeit möchte ich ein dunkles UI – helle Schrift auf dunklem Grund. Meine Twitter-App stelle ich ständig um; wünsche mir das auch für SELFHTML.

Gibt es kein User-CSS mehr?

Das wäre aber nicht benutzerfreundlich. Für edge auf Laptops ginge light-level. Ob das wirklich klug ist, die Kamera immer eingeschaltet zu haben, ist eine ganz andere Frage.

Noch viel Benutzerfreundlicher ist die Taste die die Helligkeit meines Bildschirms reguliert.

[marctrix]

Hej beatovich,

Bei geringer Umgebungshelligkeit möchte ich ein dunkles UI – helle Schrift auf dunklem Grund. Meine Twitter-App stelle ich ständig um; wünsche mir das auch für SELFHTML.

Gibt es kein User-CSS mehr?

Das wäre aber nicht benutzerfreundlich. Für edge auf Laptops ginge light-level. Ob das wirklich klug ist, die Kamera immer eingeschaltet zu haben, ist eine ganz andere Frage.

Noch viel Benutzerfreundlicher ist die Taste die die Helligkeit meines Bildschirms reguliert.

Wie du siehst, gibt es zahlreiche Möglichkeiten. Auf einer barrierefreien Website hat jeder die Möglichkeit, die zu nutzen, die für ihn am bequemsten ist. Denn da sollten alle diese Möglichkeiten funktionieren.

Selbst wenn man sie miteinander (und mit anderen Maßnahmen wie Zoomen) kombiniert.

Was nicht heißt, dass man als Autor noch etwas machen kann, wenn sich jemand absichtlich weiß auf weiß einstellt. Ich gehe mal von sinnvollen Einstellungen aus. Barrierefreiheit kann Sabotage nicht verhindern.

Marc

[Gunnar Bittersmann]

@@beatovich

Bei geringer Umgebungshelligkeit möchte ich ein dunkles UI – helle Schrift auf dunklem Grund. Meine Twitter-App stelle ich ständig um; wünsche mir das auch für SELFHTML.

Gibt es kein User-CSS mehr?

Wie sollte das behilflich sein? Ich will – wie ich ja sagte – nicht immer hell auf dunkel, sondern nur manchmal.

Was hilfreich wäre: verschiedene Profile für einunddenselben Nutzer. Und das gibt es (noch) nicht.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Was hilfreich wäre: verschiedene Profile für einunddenselben Nutzer. Und das gibt es (noch) nicht.

Ja. Weil es offensichtlich nicht so einfach zu programmieren ist. Denn mit einem einfachen CSS-Umschaltknopf ist es ja nicht getan.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Was hilfreich wäre: verschiedene Profile für einunddenselben Nutzer. Und das gibt es (noch) nicht.

Ja. Weil es offensichtlich nicht so einfach zu programmieren ist.

Nicht?

Möglicherweise ist nicht so einfach, Nutzeraccounts (so wie es sie jetzt gibt) in mehrere Profile aufzuteilen; aber doch nicht so schwierig, mehrere Profile (so wie es sie jetzt gibt) zu einem Nutzeraccount zusammenzufassen.

Aber das weiß @Christian Kruse besser als ich.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

der Hauptgrund, warum es noch keine unterschiedlichen Konfigurationen gibt, ist Zeit.

LG,
CK

[marctrix]

Hej beatovich,

Ist dennoch recht weit verbreitet Hintergrund und Schriftfarbe anzupassen. Ist schließlich eine der einfachsten Anpassungen, da Browser so was von haus aus anbieten.

Ja, immer mehr über die Leseansicht, und da brauch mich mein CSS gar nicht mehr zu kümmern.

Mag sein, aber als Forderer von Belegen: woher weißt du das? Hast du das mal schwarz auf weiß? - In meinen Kursen ernte ich immer ziemlich viele Aaaah und Ooooh wenn ich die Lesefunktion zeige. Die scheint noch längst nciht jedem bekannt, geschweige denn, dass die von denen, die sie kennen, ständig genutzt wird.

Aber ja, sinnvoll wäre das. Leider funktioniert die aber auch gar nicht auf allen Seiten, da kommt wieder Semantik ins Spiel…

Marc