Rolf B: Frage zum Wiki-Artikel „@-Regeln“

Beitrag lesen

problematische Seite

Hallo nix,

"die da" verlieren ab hier eine Menge Worte über not, and und or. Inclusive Beispielen. Das Whitespace hinter dem not ist dort nicht erwähnt, richtig, aber immerhin steht es in allen Beispielen.

:not() ist auch kein CSS Operator. Sondern eine Pseudoklasse in Funktionsnotation, und bei denen muss die Klammer direkt dahinter stehen. Ich nehme an, dass der not-Operator in den @-Bedingungen das Space braucht, um den CSS Parser nicht zu komplex werden zu lassen. Das ist auch bei den + und - Operatoren in der calc() Funktion so.

Die formale Syntaxbeschreibung sagt übrigens, dass

@supports not block-size:1lh {}

falsch ist, da steht nämlich <supports-in-parens> als Syntaxelement. Und das ist eins von diesen:

  • ( <supports-condition> )
  • <supports-feature>
  • <general-enclosed>

In Option 1 stecken die Klammern explizit drin, das ist auch nur der rekursive Rückbezug, dass Bedingungen Teil einer größeren Bedingung sein können.

Option 2 ist ein Forward zu <supports-decl>, warum auch immer, und <supports-decl> ist als ( <declaration> ) definiert. Also: Klammern.

Option 3 ist entweder ( <any-value>? ) - also ein beliebiger Wert in Klammern, oder <function-token> <any-value>? ). Hier ist der einzige Punkt, wo ein "<support-in-parens>` nicht mit einer Klammer beginnt. Es muss aber ein function token sein, und dessen Definition endet mit einer linken Klammer. Im übrigen schreibt die Spec, dass Option 3 in Stylesheets nicht zu verwenden ist, sondern für die Zukunft reserviert sei. Diese Zukunft tritt mit @supports selector() ein - das ist ein function token und wird in Level 4 der Spec beschrieben.

block-size:1lh ist dagegen eine "Declaration", auch wenn die Spec das nicht zu einer weiteren Syntaxdefinition verlinkt. In MDN steht's. Wir sind also bei Option 2, und demnach braucht es Klammern.

Wenn Du den Artikel verbessern möchtest, bist Du herzlich willkommen, dich im Wiki zu anzumelden (unangemeldete Edits haben wir abgeschaltet, weil zuviel Müll reinkam) und dich ans Werk zu machen. Matthias oder ich sehen das dann als "unkontrollierte Änderung" und segnen das entweder ab, verbessern es oder schmeißen es wieder raus 😉. Heißt: Wenn Du Dir unsicher bist, ob dein Werk was taugt, erstelle erstmal eine Kopie des Artikels oder Artikelteils in einer Unterseite deines Benutzer-Raums (zum Beispiel /wiki/Benutzer:nix/@supports) und bitte um Peer Review.

Rolf

--
sumpsi - posui - obstruxi