Revenge.css

[TS]

Hello Gunnar,

Na siehste! Geht doch. :-)

Was auch geht:

ul > *:not(li), ol > *:not(li)
{
  outline: 0.5em solid red;
  ERROR: ul/ol darf nur li-Kindelemente enthalten;
}

ins Stylesheet^[1] schreiben und schon wird der Fehler sichtbar.[^2]

keine schlechte Idee!

Sollten wir mal sammeln und zu einer "Display-Errors-Collection" zusammenstellen, die man dann wäherend der Entwicklung einbinden kann.

Liebe Grüße
Tom S.

---

1. in eins, das man nur während der Entwicklung einbindet ↩︎

[Gunnar Bittersmann]

@@TS

keine schlechte Idee!

Ich habe schon die eine oder andere gute Tat vollbracht.

Sollten wir mal sammeln und zu einer "Display-Errors-Collection" zusammenstellen, die man dann wäherend der Entwicklung einbinden kann.

Wieso wir? Heydon hat schon gesammelt: Revenge.css

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Wieso wir? Heydon hat schon gesammelt: Revenge.css

Hast du ihn schon darauf hingewiesen, dass sein Selektor u.U. ins Leere läuft, weil img keinen generierten Inhalt haben darf?

a:not([aria-label]):not([aria-labelledby]) img:only-child:not([alt]):after, 
img:not([alt]):after, 
img[alt]:not([alt=""]):after, 
img:not([src]):after, 

Und eine Klasse button finde ich auch ziemlich merkwürdig.

.button:not(a):not(button):not(input):after, 
.btn:not(a):not(button):not(input):after, 

aber offenbar scheint es verbreitet zu sein, buttons nachzubauen.

Nicht, dass noch jemand auf die Idee kommt .picture:not(img):not(picture) oder .paragraph:not(p) mit aufzunehmen.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Hast du ihn schon darauf hingewiesen, dass sein Selektor u.U. ins Leere läuft, weil img keinen generierten Inhalt haben darf?

Nö, hab ich nicht.

Ich finde die Idee, die Fehlermeldungen per ERROR-„Eigenschaft“ im Entwicklertool anzuzeigen, auch besser als mit ::after etwaige vorhandene Pseudoelemente zu überschreiben.

Und eine Klasse button finde ich auch ziemlich merkwürdig.

Sei froh!

Wenn du mit sowas wie Bootcrap arbeiten müsstest … – da wird sowas wie <button class="btn"> gemacht. 😰 Und die im Framwork getätigten Regeln sind mit Klassenselektoren.

Da hat man dann halt präsentationsbezogenes Markup vom „Feinsten“.

Da sage nochmal jemand, es gäbe keine CSS-Klassen.

Und es gibt Stimmen, die sagen, man solle in CSS nur mit Klassenselektoren arbeiten. Und es gibt Entwickler, die auf die Sirenen hereinfallen.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Ich finde die Idee, die Fehlermeldungen per ERROR-„Eigenschaft“ im Entwicklertool anzuzeigen

Wo kann man denn dazu eine Spezifikation finden? In Jens Meierts ständig aktuell gehaltener Liste aller CSS-Eigenschaften gibt es sie auch nicht.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Ich finde die Idee, die Fehlermeldungen per ERROR-„Eigenschaft“ im Entwicklertool anzuzeigen

Wo kann man denn dazu eine Spezifikation finden?

Na nirgendwo.

“There is no such thing as the ERROR property in CSS and there are no plans for one – let me make that clear right away!”
—Heydon Pickering in seinem Buch “Inclusive Design Pattern”

Es geht überhaupt nicht daraum, für das Test-Stylesheet grünes Licht von einem Validator zu erhalten. Es soll eine Fehlermeldung ausgegeben werden – nicht mehr und nicht weniger.

Und da ERROR keine standardisierte CSS-Eigenschaft ist, bekommt die Fehlermeldung in Entwicklertools auch ein ⚠️ spendiert. Unschön dabei ist, dass die Meldung durchgestrichen wird. Für Chrome gibt’s da eine Erweiterung.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Es geht überhaupt nicht daraum, für das Test-Stylesheet grünes Licht von einem Validator zu erhalten. Es soll eine Fehlermeldung ausgegeben werden – nicht mehr und nicht weniger.

Das ließe sich ja trotzdem in eine Spezifikation packen.

Und da ERROR keine standardisierte CSS-Eigenschaft ist, bekommt die Fehlermeldung in Entwicklertools auch ein ⚠️ spendiert. Unschön dabei ist, dass die Meldung durchgestrichen wird. Für Chrome gibt’s da eine Erweiterung.

Unschön ist auch, dass ich die Meldung nur dann sehe, wenn ich (mehr oder weniger zufällig) das Element untersuche.

Die Hervorhebung mit dem roten Rahmen gibts ja trotzdem, also werde ich mit der Nase drauf gestoßen.

Bis demnächst
Matthias

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Ich habe einen Wiki-Artikel gebastelt.

Was gibts zu kritisieren?

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Ich habe einen Wiki-Artikel gebastelt.

Was gibts zu kritisieren?

Ja. Schon den Anfang: „… können sich leicht Fehler einschleichen, die zu einem invaliden Markup führen. Ein Validierungs-Stylesheet hilft, diese Fehler sichtbar zu machen.“

Das ist nicht das alleinige Ziel, schon gar nicht das Hauptziel.

„Ein solches Validierungs-Stylesheet erspart in der Entwicklungszeit die ständige Konsultation eines Validators“

Formale Fehler aufzudecken kann ein Validator besser. So ein Test-Stylesheet ist vor allem dazu da, Fehler aufzudecken, die ein Validator nicht findet.

Eine Tabelle mit einer Zeile und einer Spalte bspw. ist kein formaler Fehler, aber unsinniges Markup. Das kann man sichtbar machen.

Das Hauptaugenmerk liegt eher auf Accessibility-Sünden. Wie bspw. Click-Events für nicht fokussierbare Elemente.

img:not([alt]) ist da ein Anfang, aber ausbaufähig. Jemand könnte auf die Idee kommen, im Markup alt="" zu ergänzen, womit der Fehler natürlich nicht behoben ist. Also auch img[alt=""] kennzeichnen?

Nö, das liefert false positives. Es gibt ja durchaus Fälle wie diesen, wo alt="" angebracht ist. In dem Fall sollte das aria-labelledby-Attribut angeben, wo die Beschriftung des Bildes zu finden ist. Ein anderer Fall wäre ein Schmuckbild (das aus irgendeinem Grund nicht als Hintergrundbild realisiert ist), als solches markiert mit role="none" oder/und "presentation". Eine passende Gruppe von Selektoren wäre also img:not([alt]), img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby]).

---

Es ist auch problematisch, die Farbe der Umrandung hartcodiert auf rot zu setzen. Was, wenn man das Farbschema ändert und nun Rot als Akzentfarbe auf den Seiten auftritt? Dann muss man die Fehlerfarbe schnell ändern können, z.B. auf orange. Dateiweites Suchen und Ersetzen kann das zwar, es geht aber besser, wenn man sich die Fehlerfarbe in eine Variable packt. Die Rahmendicke dann auch gleich:

:root
{
	--error-color: red;
	--error-outline: 0.5rem solid var(--error-color);
}

img:not([alt]),
img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby])
{
	ERROR: 'Alternativtext fürs Bild fehlt';
	outline: var(--error-outline) !important;
}

Das funktioniert noch nicht im Edge; aber benutzt den wer als Browser zum Entwickeln?

LLAP 🖖

PS: Kaputte Syntax-Highlighter sind kaputt.

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Ein passender Selektor wäre also img[alt=""], img[alt=""]:not(…)

ERROR: 'falschen Kram kopiert';

Muss natürlich img:not([alt]), img[alt=""]:not(…) heißen. Ich berichtige das gleich mal im vorigen Posting.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Danke für deine Ausführungen. Leider werde ich in den nächsten 14 Tagen wohl etwas weniger Zeit haben, das umzusetzen.

Ja. Schon den Anfang: „… können sich leicht Fehler einschleichen, die zu einem invaliden Markup führen. Ein Validierungs-Stylesheet hilft, diese Fehler sichtbar zu machen.“

Das ist nicht das alleinige Ziel, schon gar nicht das Hauptziel.

So ein Test-Stylesheet ist vor allem dazu da, Fehler aufzudecken, die ein Validator nicht findet.

Das Hauptaugenmerk liegt eher auf Accessibility-Sünden.

Ok. Also heißt es die Prioritäten umzudrehen.

img:not([alt]) ist da ein Anfang, aber ausbaufähig. Jemand könnte auf die Idee kommen, im Markup alt="" zu ergänzen, womit der Fehler natürlich nicht behoben ist. Also auch img[alt=""] kennzeichnen?

Es geht in dem Artikel nicht darum, dass man sich selbst ein solches Stylesheet schreibt, sondern dass man Heydons verwenden oder anpassen soll.

Die Diskussion um alt wurde auch geführt.

Es ist auch problematisch, die Farbe der Umrandung hartcodiert auf rot zu setzen. Was, wenn man das Farbschema ändert und nun Rot als Akzentfarbe auf den Seiten auftritt? Dann muss man die Fehlerfarbe schnell ändern können, z.B. auf orange. Dateiweites Suchen und Ersetzen kann das zwar, es geht aber besser, wenn man sich die Fehlerfarbe in eine Variable packt. Die Rahmendicke dann auch gleich:

:root
{
	--error-color: red;
	--error-outline: 0.5rem solid var(--error-color);
}

img:not([alt]),
img[alt=""]:not([role="none"]):not([role="presentation"]):not([aria-labelledby])
{
	ERROR: 'Alternativtext fürs Bild fehlt';
	outline: var(--error-outline) !important;
}

gute Idee.

PS: Kaputte Syntax-Highlighter sind kaputt.

Auch da kann man ein Ticket aufmachen, Rouge heißt der glaub ich. @Christian Kruse kann dir die Adresse nennen. Und da du besser englisch kannst als ich, solltest besser du das tun.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

Auch da kann man ein Ticket aufmachen, Rouge heißt der glaub ich.

Pygments.

LG,
CK

[Gunnar Bittersmann]

@@Matthias Apsel

Es geht in dem Artikel nicht darum, dass man sich selbst ein solches Stylesheet schreibt, sondern dass man Heydons verwenden oder anpassen soll.

Ich würde das Revenge.css erstmal von den Meldungen per Inhalt in ::after-Pseudoelementen zu Meldungen per ERROR-Eigenschaft umschreiben wollen. Ich werd Heydon mal fragen, was er davon hält.

LLAP 🖖

[beatovich]

hallo

Folgende Idee: Fehlerhafte URIs können oft getestet werden (server error.log). Das trifft aber nicht mehr zu, wenn ein Protokollwechsel stattfindet.

Ziel: Ich möchte fehlerhafte Maillinks vermeiden.

Frage, wie müsste der Selektor aussehen, der alle email-adressen markiert, die nicht "@example.org" enthalten?

Ich habe den folgenden Selektor gefunden:

a[href*="mailto"]:not([href*="@example.org"]) {color:red !important;}

[Gunnar Bittersmann]

@@beatovich

Frage, wie müsste der Selektor aussehen, der alle email-adressen markiert, die nicht "@example.org" enthalten?

Ich habe den folgenden Selektor gefunden:

a[href*="mailto"]:not([href*="@example.org"]) {color:red !important;}

Sieht doch gar nicht so schlecht aus. Ich würde aber nicht auf irgendwo, sondern auf Anfang bzw. Ende gehen:

a[href^="mailto:"]:not([href$="@example.org"])

Ob dir color: red genügt, musst du wissen. outline ist auffälliger.

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Sieht doch gar nicht so schlecht aus. Ich würde aber nicht auf irgendwo, sondern auf Anfang bzw. Ende gehen:

a[href^="mailto:"]:not([href$="@example.org"])

Das Ende geht aber schief, wenn man etwa den Betreff vorausfüllen möchte. Deshalb

[href^="mailto:"]:not([href*="@example.org"])

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Das Ende geht aber schief, wenn man etwa den Betreff vorausfüllen möchte. Deshalb

[href^="mailto:"]:not([href*="@example.org"])

Dann erkennt man aber <a href="mailto:pö[e-mail]ösen.example"> nicht.

Dann schon eher sowas wie

[href^="mailto:"]:not([href$="@example.org"]), [href^="mailto:"]:not([href*="@example.org?"])

LLAP 🖖

[beatovich]

hallo

Sieht doch gar nicht so schlecht aus. Ich würde aber nicht auf irgendwo, sondern auf Anfang bzw. Ende gehen:

a[href^="mailto:"]:not([href$="@example.org"])

Der Startanker ist gut. Ich möchte jedoch auch berücksichtigen, dass example.org?subject=etc möglich ist.