Frage zum Wiki-Artikel „@-Regeln“

[Kopfkissen!]

Die Idee hinter den @media scheint ja nicht schlecht zu sein. Aber man weiß ja, gut gemeint …

Jedenfalls nerven mich die praktisch jedes Mal, sobald ich wieder so ein „Kopfkissen“ zu sehen bekomme. Vielen Dank für die (tollkirsch)tolle Idee mit dem ‘mobile first’!, denn zumindest gefühlt weiß der Rest der Welt längst nicht mehr, daß das Kram ist, der ‘last’ kam und obendrein auch noch ettliche Features in die Browser gepackt bekam, um diesen Ansatz möglichst sinnfrei zu machen.

Jedenfalls scheitert der Versuch, dise Pillarbox-Seiten mittels User-CSS zu zähmen, meist recht schnell an @media (widh > 1234567dong){…} … @media (width < 1234567dings){…} … @media (with > 1234566dings){…} @media (width < 123456dong){… @media(width > dings){…} …} @media(widht < 9384388dings and width > 1dong) {…} …

Die Abhilfe

(function() {
	'use strict';

	[].slice.call(document.styleSheets).forEach(function(sheet) {
		[].slice.call(sheet.cssRules).forEach(function(rule) {
			if (rule.media) rule.cssText = '';
		});
	});
})();

als User-Script ("@match *.*"?) wirkt leider nur kurzfristig. Was aber öfter mal doch genügt: „fire and forget“ …

Jedenfalls fürchte ich, daß ich die Antwort schon kenne: wie bekommt man diese (manche davon?) Regeln mundtot gemacht?

┉┉┉┉┉┉┉┉┉┉┉┉
Ding und Dong? Fragt mal den etwas krümeligen und recht kastigen Bernd (nicht in Bielefeld) …

[Gunnar Bittersmann]

@@Kopfkissen!

[mal wieder unverständliches Rumgekotze]

Jedenfalls fürchte ich, daß ich die Antwort schon kenne: wie bekommt man diese (manche davon?) Regeln mundtot gemacht?

Deine Furcht scheint mir unbegründet zu sein. Wegen deinen lückenhaften CSS-Kenntnissen kennst du die Antwort vielleicht doch noch nicht: revert.

🖖 Live long and prosper

[Kopfkissen!]

revert ist doch ein alter Hut. Aber woher käme ein for (const r of document.queryAll@Regel) { all: revert; }?

„Witzigerweise“ sind da ja auch innhalb der @-Blöcke viele, sehr viele Styles immer wieder, redundant, angegeben. Ein „ungeregelter Default-Bereich“ fehlt aber oft/meist. Also ungefähr

@media(X) { regel1 regel3 regel4 regel5 regel6 regel7 }
@media(Y) { regel1 regel2 regel3 regel4 regel5 regel6 }
@media(Z) { regel1 regel2 regel3 regel5 regel6 }

nicht

regel1
regel3
regel5
regel6

@(X) { regel4 regel7}
@(Y) { regel2 regel4 }
@(Z) { regel2 }

oder aber

regel1
regel3
regel5
regel6

@(X) { regel4 regel7}
@(Y or Z) { regel2 }
@(Y) { regel4 }

Dabei werden dann auch gerne „Elemente zerrissen“, so daß man, will man sie pflegen, jeden einzelnen Regelsatz abgrasen und aufpolieren muß/müßte.

Das dann noch über mehrere Stylesheet(dateien) verteilt — kein Wunder, daß die Datenmenge fürs CSS nicht selten mehr, auch merkbar mehr, als die Hälfte vom anfallenden gesamten Datenvolumen abknappst: wenn da bei jedem Auftreten von "regel[1…n]" alles* erneut hingeschrieben steht …\

┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ *: viel Spaß bei der Problemsuche — oder „nur 17 Meldungen mit ‚manchmal‘ und beim ‚wann?‘ nur 🤷“? Weg damit!

[Auge]

Hallo

„Witzigerweise“ sind da ja auch innhalb der @-Blöcke viele, sehr viele Styles immer wieder, redundant, angegeben. Ein „ungeregelter Default-Bereich“ fehlt aber oft/meist. Also ungefähr

@media(X) { regel1 regel3 regel4 regel5 regel6 regel7 }
@media(Y) { regel1 regel2 regel3 regel4 regel5 regel6 }
@media(Z) { regel1 regel2 regel3 regel5 regel6 }

nicht

regel1
regel3
regel5
regel6

@(X) { regel4 regel7}
@(Y) { regel2 regel4 }
@(Z) { regel2 }

Wenn sich die Werte einzelner Eigenschaften über die Media-Queries hinweg ändern, dann müssen die Eigenschaften halt immer wieder mit den jeweils anderen Werten aufgeführt werden. Prinzipiell hast du aber damit recht, dass – ausgehend von der Mobile-First- oder jeglicher anderen konsequent angewandten Regel – vor den Blöcken mit den Änderungen alles notiert gehört, das speziell für die als generell geltende Ansicht^[1] benötigt wird und/oder unveränderlich bleibt. Alles in Media-Queries einzuschließen, ist mMn alles andere als sinnvoll.

Das dann noch über mehrere Stylesheet(dateien) verteilt — kein Wunder, daß die Datenmenge fürs CSS nicht selten mehr, auch merkbar mehr, als die Hälfte vom anfallenden gesamten Datenvolumen abknappst: wenn da bei jedem Auftreten von "regel[1…n]" alles* erneut hingeschrieben steht …\

Auch wenn es Seiten mit gut aufgeblähtem CSS geben mag, sind es doch üblicherweise die gerne auch mal mehrfach eingebundenen JavaScript-Bibliotheken^[2] oder direkt aus der 24-Megapixel-Kamera eingebundene Fotos, die Webseiten aufblähen.

Tschö, Auge

---

1. Was auch immer der zugrundeleigenden Regel als Basis angenommen wird ↩︎

2. Binde JQuery allgemein ein, binde es noch einmal für Plugin A in einer speziellen, in der Anleitung des Plugins benannten Version ein und wiederhole das mit weiteren Versionen oder Bibliotheken für jegliches andere, schick erscheindene Plugin, dass man finden kann. ↩︎

[Rolf B]

Hallo Kopfkissen,

je nach Seite kann es zielführend sein, alle @media-Regeln zu töten.

Bei einer korrekt erstellten mobile-first Seite ohne Legacy-Zeugs drin sind es aber die @media-Regeln, die aus Pillarbox die Letterbox machen, deswegen ist es alles andere als zielführend, alle @media-Regeln mit ihren Inhalte zu töten.

Beachte auch, dass einige dieser Operationen am offenen Herzen auch mit @container durchgeführt werden könnten.

An deiner Stelle würde ich die Seite hinnehmen, wie der Server sie liefert, und nicht mit User-CSS oder Script-Gehacke eingreifen. Das spart eine Menge Nerven. CSS ist immer seitenspezifisch, und das heißt: Du musst für jede Seite, deren Layout Dir missfällt, eigenes User-CSS vorhalten und pflegen, sobald der Autor die Seite anpasst.

Rolf

[Kopfkissen]

Ich will ja nicht „die ganze Welt“ ändern. Nur ein paar Seiten, bei denen Inhalte, die mich an sich „wiederholt interessieren“ ob deren Gestaltung wenig(er) gefallen.

Jedoch: „jede Seite“ die mir mißfällt? Schon ob der Ähnlichkeiten, sowohl „optischer“ als auch welcher beim Aufbau des HTML (CSS sehe ich mir erst in letzter Zeit genauer an, denn „früher™“ einmal genügten für solche Dinge meist zwei, drei kleine Regeln), scheint mir die Wahrscheinlichkeit hoch, daß im Kopf der User-Styles öfter mal etwas wie

@match site1
@match site2
@match site3

stehen kann.

[Rolf B]

Hallo Kopfkissen,

da wirst Du dann wohl mit @match fleißig sein müssen und maßgenau Styles der „unschönen“ Seite überklatschen.

Mit User-Styles ist das aber gar nicht so einfach, denn die haben Nachrang gegenüber Autorenstyles (außer !important, da dreht sich die Prio um).

Tampermonkey kann nur Scripte laufen lassen, soweit ich weiß. Damit kannst Du neues CSS auf Autorenlevel nachladen, und du könntest Dir mal @layer anschauen, wenn Du mit der Spezifität nicht hinkommst. Hülft natürlich nüx, wenn die hässliche Seite selbst schon layert und deren Layer-Angaben Dir in die Quere kommen.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Mit User-Styles ist das aber gar nicht so einfach, denn die haben Nachrang gegenüber Autorenstyles (außer !important, da dreht sich die Prio um).

[…] du könntest Dir mal @layer anschauen, wenn Du mit der Spezifität nicht hinkommst.

Regeln in Layern haben Nachrang gegenüber Regeln nicht in Layern (außer !important, da dreht sich die Prio um).

🖖 Live long and prosper

[Kopfkissen]

a) es gibt ja nicht nur Tampermonkey „und Konsorten“. Mir fällt da gleich Stylus ein, da wird rein aufs CSS geschossen. (Allerdings scheinen mir die verwandt zu sein.)

b) So einem (User-)Script steht es ja auch frei, etwas wie

{
	const s = document.createElement('style');
	const css = [
		':where(h3, h5) {',
		'	position: static;',
		'	&::after {',
		'		position: absolute;',
		'		inset: 0 0 0 65%;',
		'		font-size: 1rem;',
		'	}',
		'}',
		'',
		'h5 {',
		'	background-color: red;',
		'	&::after { content: "h5"; background-color: yellow; display: inline-block; }',
		'}',
		'h3 {',
		'	background-color: green;',
		'	&::after { content: "h3"; color: yellow; background-color: purple; display: inline-block; }',
		'}',
…
	];
	s.append(css.join('\n'));
	document.body.append(s);
}

zu machen. (Wobei das hier ein Ausschnitt aus einem “laßt mich die Struktur sehen”, einem “Debugg-Style” ist. Sogar „mit Quelltext-Formatierung drin“.)

[Rolf B]

Hallo Kopfkissen,

dieses Script ist (a) ungeschickt und (b) falsch.

• Schau Dir gelegentlich Template-Strings an, die ersparen das Array.
• Wenn Du schon ein style-Element hinzufakest, dann bitte an den head und nicht an den body. style im body war mal ein Spec-Versuch für lokalisierte style-Regeln, hat sich aber nicht durchgesetzt.
• :where() hat Spezifität 0, d.h. diese Regel wird allen anderen Regeln zu h3 und h5 hintenangestellt. Das eingeschachtelte ::after hat immerhin die Klassen-Spezifität (0,1,0). Aber falls deine Regeln nicht greifen, kann das der Grund sein. Mit :is() bekommst Du mehr Spezifität, nämlich die des spezfischsten Teilselektors. Mit :is(#fakeId, h3, h5) bekommst Du ID-Spezifität (1,0,0), auch wenn nur h3 oder h5 matcht (was Spezifität (0,0,1) wäre).
• Die display-Eigenschaft könntest Du noch "ausklammern". Und für ein absolut-positioniertes Element bietet sich eher display:block als inline-block an, denn es ist nie in seinem Elternkontext inline.

Und jetzt zu den gravierenden Fehlern:

• position:static ist der falsche Positionierungsmodus für ein absolut positioniertes Kindelement. Nimm position:relative. static ist der Default und position:absolute orientiert sich nicht daran. Die inset-Eigenscahft der ::after-Elemente orientiert sich am nächstgelegenen non-static Elternelement. Schlimmstenfalls ist das der body.
• inset: 0 0 0 65% ist überspezifiziert. Das ist zusammen mit dem falschen position-Modus der h3/h5 Elemente der Grund, weshalb diese ::after-Elemente sich viel zu weit ausdehnen. Wenn Du möchtest, dass das ::after-Element sich am rechten Rand der Überschrift orientiert, würde ich insert: 0 0 0 auto empfehlen. Ggf. noch etwas Padding.

:is(h3, h5) {
  position: relative;
  &::after {
    position: absolute;
    inset: -0.5em 0 auto auto;
    padding: 0.2em;
    border-radius: 30%;
    align-content: center;
    font-size: 1rem;
  }
}
h3 {
  background-color: green;
  &::after {
    content: "h3";
    color: yellow;
    background-color: purple;
    display: block;
  }
}

Rolf

[Gunnar Bittersmann]

@@Rolf B

Wenn Du schon ein style-Element hinzufakest, dann bitte an den head und nicht an den body.

Ja, wenn man die Wahl hat, sollte man das tun.

style im body war mal ein Spec-Versuch für lokalisierte style-Regeln, hat sich aber nicht durchgesetzt.

Funktioniert aber trotzdem.

Ich mache davon rege Gebrauch bei einer Komponente eines Drittanbierters, wo ich über ein Formular mit textareas HTML und CSS einhängen kann. Allerdings haben die da einen CSS-Validator eingebaut – der wohl als Hilfe gedacht war, damit man keinen fehlerhaften CSS-Code hinterlegen kann. Dieser ist nun hoffnungslos veraltet; wenn man da mit modernem CSS ankommt, was über den Kenntnisstand eines durchschnittlichen JavaScript-Entwicklers hinausgeht, sagt das Ding: falsch, das nehme ich nicht an. Ich bin also gezwungen, deren Validator zu umgehen und meine Styles in einem style-Element im HTML anzugeben, und dann landet das halt im Root-Element der Komponente irgendwo im body.

---

position:static ist der falsche Positionierungsmodus für ein absolut positioniertes Kindelement. Nimm position:relative.

Nö! static (da default also keine Angabe) ist schon richtig. Konstrukte mit position: relative fürs Containerelement sollten doch nun mit der allgemeinen Verfügbarkeit von anchor positioning^[1] der Vergangenheit angehören.

🖖 Live long and prosper

---

1. TIL about anchor positioning^[2] ↩︎

2. Wie oft muss ich mich noch darüber beschweren, dass Notist auf der Blacklist steht? Ich sollte mich wohl an CK wenden, damit dieses Spielzeug für Admins aus der Forensoftware verschwindet. ↩︎

[Rolf B]

Hallo Gunnar Bittersmann,

Wie oft muss ich mich noch darüber beschweren, dass Notist auf der Blacklist steht? Ich sollte mich wohl an CK wenden, damit dieses Spielzeug für Admins aus der Forensoftware verschwindet.

Jetzt nicht mehr. Da auf meinen internen Nachfrage-Thread dazu keiner eine erhellende Antwort hatte, nehme ich an, dass der Blacklist-Eintrag ein Irrtum war. Oder Bösartigkeit meinerseits, weil mich Präsentationen ohne zugehörige Beschreibung grundsätzlich aufregen.

Wer anderer Meinung ist, möge jetzt meckern, damit wir ihn für immer zum Schweigen bringen können ⚔️ 😉

Rolf

[Gunnar Bittersmann]

@@Rolf B

Jetzt nicht mehr.

Danke.

weil mich Präsentationen ohne zugehörige Beschreibung grundsätzlich aufregen.

Aus den Slides allein lässt sich oft nicht rekonstruieren, was dazu gesagt wurde, ja. Aber die sind auch nicht das Entscheidende, sondern die dazu angegebenen Codepens und Links zu Artikeln, Videos o.a. Quellen.

🖖 Live long and prosper

[Kopfkissen]

Danke für die Tipps! Aber: das war jetzt wirklich „schnelles Gefrickel“, das da, wo ich es gebraucht habe, seinen Dienst tat und … na, der Mohr hat …

Es ging mir da nur um eine schnelle Demonstration dafür, daß einem da auch CSS keine verschlossene Türe ist. Und mag vielleicht auch als kleine Anregung für Gelegenheiten sein, bei dem Durchblick gesucht wird.

Hmmm… Template-Strings. Na ja, kamm man natürlich. Aber leider fehlt denen eine Priese Swift: “„A multiline string can be indented to match the surrounding code. The whitespace before the closing quotation marks (""") tells Swift what whitespace to ignore before all of the other lines. However, if you write whitespace at the beginning of a line in addition to what’s before the closing quotation marks, that whitespace is included.“ … “The value of an expression can be inserted into a string literal by placing the expression in parentheses after a backslash ().“ — Auszug aus “The Swift Programming Language (Swift 5.7)”

Ein Grund fürs Array(??? Das sind doch „erweiterte C-Strings“ und keine Arrays?) war mir ja, daß ich die Formatierung einfach mitnehmen, sie auch im so erquälten HTML, sehen konnte.

Was mich „heute“ ärgert ist aber url(). Weil da url(var(…))˚ kaum und var(url(…))` nicht funktioniert. Ich wollte ein paar kleine(re) SVGs als Data-URL unterbringen. Und weil die schnell „quelltextunschön“ werden: ab damit in eine sog. Variable …

Pustekuchen! Denn wegen der “legacy” arbeitet url() nicht als CSS-Funktion sondern „tut nur so“. Wenn der Paramter nicht in Anfürhungszeichen steht. Und wenn man den so einpackt, dann könnte man schon, aber var() mag nicht mehr mitspielen und Zeichenketten verarbeiten bzw. als solche verarbeitet werden …

Süß: schon vor längerer Zeit gab es da mal den Vorschlag, ein src() als “legacy-free” Verson von url() einzubauen. Aber … WFM muß doch allen genügen! Oder?

[Rolf B]

Hallo Kopfkissen,

Weil da url(var(…))˚ kaum und var(url(…))`

Ja, var kann keine Teile einer atomaren Einheit ersetzen. url() ohne Anführungszeichen ist eine, aus historischen Gründen. Dieses Github-Issue führt das genauer aus.

Aus meiner Sicht ist das ein großer Käse, es ist eine unwillige Suche nach Entschuldigungen, statt nach Lösungen. Wenn man WOLLTE, würde man die Specs und den CSS Parser anpassen können. Aber „man“ will nicht. Weil url() ohne Anführungszeichen nicht aktuell ist, sondern historische Kompatibilität. Genauso wollte „man“ jahrelang :has() nicht, und die CSS Autoren mussten sich mit Würgherums quälen.

Das Problem dürfte auch sein, dass der CSS Parser auf Tempo statt auf Flexibilität getrimmt ist.

Die Folge ist, dass wir lediglich

.foo {
  --bild: url(...);
}
.bar {
   background-image: var(--foo);
}

verwenden können. Die URL als solches kann nicht aus Teilen zusammengesetzt werden (was oft schick wäre). Geht das so bei dir nicht?

Rolf

[Kopfkissen]

Ob es beim mir funktioniert ist nocht nicht ganz raus. Denn ich wollte ja nicht „Strings addieren“ oder so. Sondern eine Handvoll SVGs, als Data-URL getarnt, so im Quelltext unterbringen, daß die Zeichenwüste, die dabei entsteht, überall dem Auge im Wege ist.

Also ungefähr so etwas:

@media (width < 0) or (width >= 0) {
	:root {
		--Icon_Foo: url(data:svg/xml,\
				'<path d="…\
						…\
						…"\
		);
	}
}
…

…::after {
	content: '';
	mask-image: var(--Icon_Foo);
…

Da in den Strings mit den Zeichenanweisungen Anfürhungszeichen, Klammern und auch '#' vorkommen, weiß ich nocht nicht, ob ich das in den Griff bekomme. Eigentlich sollte ich es mir nicht antun, aber gerade solche Fragen reizen mich. Da „will ich gewinnen …“🤓

Und: das an sich sinnfreie @media ist für den Editor aus gleichem Grunde praktisch: ein Klick und die Sicht ist frei — zum Schluß darf das natürlich weg.

[Rolf B]

Hallo Kopfkissen,

eine Handvoll SVGs, als Data-URL getarnt, so im Quelltext unterbringen, daß die Zeichenwüste, die dabei entsteht, überall dem Auge im Wege ist.

Was mir sinnfrei vorkommt, aber du hast sicherlich einen Grund.

Statt einer tautologischen Bedingung könntest du auch einfach @media all schreiben.

Dein data:-SVG wird so nicht funktionieren, es ist ein SVG-Fragment, kein -Dokument. Glaub ich...

Rolf

[Kopfkissen]

Stimm ja, dieses all gibt’s auch. Aber „wer weiß denn sowas“? Oder denkt daran, ob es womölglich, beispielsweise, in JS auch noch ein “shorthand” für Dinge wie if(true) … oder while(false) …? 🥳

Aber ausschließen würde ich das Funktionieren solcher Data-URLs nicht. Nicht grundsätzlich. Es hängt vmtl. davon ab, ob sonst noch wo solche Automatismen (hier: „automatische Anführungszeichen“, welche eigentlich? — noch so ein Fall von quasi automatischer Typkonvertierung), legacy oder nicht, sich einmischen.

Und zum „Was mir sinnfrei vorkommt“ meine ich, daß das so ein Fall von “think different” (™[RIP Steve?] oder so) ist. Mir kommt’s bei dem, was ich da gerade so treibe, einfach entgegen. Natürlich könnte ich das auch anders lösen, aber zumindest in diesem Fall erscheint es mir bequemer.

[Rolf B]

Hallo Kopfkissen,

Natürlich könnte ich das auch anders lösen, aber...

ich weiß zu wenig von deinem Grundproblem, das Du lösen willst, als dass ich dein Unterfangen als rundheraus sinnfrei bezeichnen könnte. Ich erkenne den Sinn nur nicht. Mehr wollte ich nicht sagen.

Es wäre nett, wenn ich ihn erkennen könnte, aber das muss nicht unbedingt sein, um auf deine Fragen eingehen zu können.

Aber ausschließen würde ich das Funktionieren solcher Data-URLs nicht.

Solche, wie im verlinkten Artikel stehen, schließe ich auch nicht aus. Ich bezweifle nur, dass ein inline-SVG als als data-URL funktioniert, wenn es nicht in <svg></svg> eingeschlossen ist und die Anforderungen an standalone-SVG erfüllt.

Rolf