Es gibt jetzt einen Arbeitsentwurf für CSS-Scoping. Abgesehen von einer seltsamen Periode, in der <style scoped> veröffentlicht wurde und dann anschließend aus dem Entwurf (und Browsern) entfernt wurde, ist dies das am weitesten fortgeschrittene Scoping-Vorschlag, der bisher gemacht wurde (die Level 1-Spezifikation kam nie voran).
Dieser kommt von Miriam Suzanne.
Die Grundlagen
<div class="media">
<img alt="Proper alt." src="...">
<div class="content">
<p>...</p>
</div>
</div>
Wenn ich dieses HTML-Fragment als „Komponente“ betrachte, ist es schön, dafür Styles schreiben zu können, die explizit nur für sie gelten. Dafür ist @scope da, also…
@scope (.media) {
:scope {
display: grid;
grid-template-columns: 50px 1fr;
}
img {
filter: grayscale(100%);
border-radius: 50%;
}
.content { ... }
}
Was mir daran gefällt ist
- Dieser CSS-Teil ist ganz explizit für diese Medienkomponente gedacht. Er liest sich so und kann so gepflegt werden.
- Ich musste mir keinen Namen und keine Klasse für das
<img>ausdenken. Ich wende dort Styling an, ohne dass es auf andere Bilder „ausläuft“.
Aber Moment mal, ist das nicht dasselbe, als würde man Selektoren mit der Elternklasse präfixen?
Das ist es irgendwie… so als könnten wir auch schreiben
.media {
}
.media img {
}
.media .content {
}
Und jetzt haben wir die Dinge innerhalb der Medienkomponente eingegrenzt. Das ist ziemlich repetitiv, aber mit nativem CSS-Verschachteln auf dem Weg ist es nur dieses
.media {
& img {
}
& .content {
}
}
Ja, ich würde sagen, Verschachtelung deckt einige grundlegende Arten von Scoping ab, aber es gibt einige Dinge, die für diesen neuen Scope-Vorschlag einzigartig sind.
Eine einzigartige Funktion ist das „Donut-Scope“, was bedeutet, dass ich das Scoping dort stoppe, wo ich will. Vielleicht möchte ich, dass mein Scoping an einer bestimmten Klasse endet
@scope (.media) to (.content) {
p { }
}
Jetzt kann ich Styles schreiben, die Bereiche, die ich nicht beeinträchtigen möchte, nicht durcheinanderbringen. Vielleicht
<div class="media">
<img alt="Proper alt." src="...">
<p>This is stylable in scope.</p>
<div class="content">
<p>This is NOT styleable in scope.</p>
</div>
</div>
Aber das ist nicht das einzige einzigartige Problem, das dieser neue Entwurf löst. Ich denke, die „nächstgelegene Vorfahrsituation“, die Miriam darlegt, ist vielleicht das Interessanteste. Ich verweise Sie auf den Blogbeitrag, um das zu lesen – es ist ziemlich wild, dass wir dafür noch kein gutes Werkzeug haben.
Hier gibt es viel zu verdauen, besonders wenn man an komplexere Situationen denkt, wie mehrere überlappende Scopes und wie die Verschachtelungssyntax mit Scoping interagieren könnte. Glücklicherweise bloggt Miriam diese Dinge sehr klar.
Das 4. Beispiel ist SCSS/Less, keine gültigen nativen verschachtelten direkten Selektoren. Letzteres muss (wie vorgeschlagen) mit
&beginnenAch, ich dachte, es wäre so, als ob man bei einem einfachen verschachtelten Selektor das & weglassen könnte. Ich liege wahrscheinlich falsch
Warum sollte ein Browser dumm sein, um damit ohne notwendiges &-?! umgehen zu können?
Ich wünschte, es wäre so, aber das wird nicht der Fall sein, um einen unendlichen Look-Ahead zu vermeiden und zwischen einer Deklaration und einem verschachtelten Selektor zu unterscheiden.
Spezifikation), siehe „Warum kann nicht alles direkt verschachtelt werden?“ direkt darüber.
Zu meiner großen Trauer wird dies den Refactoring-Schritt des Umwickelns (Verschachtelns) einer Gruppe von Regelblöcken mit einem zusätzlichen Selektor nicht-trivial und mühsam machen, aber die Begründung ergibt aus Sicht der Parserleistung Sinn: Jede Deklaration müsste zweimal verarbeitet werden, zuerst um das Ende
;oder{zu finden, dann um als Deklaration/Selektor (jeweils) geparst zu werden.Ein Ansatz wurde versucht, um das Verschachtelungspräfix optional zu machen, aber nicht im Detail untersucht: #5746
Es gab eine ähnliche Frage für @nest (nicht direkte Verschachtelung): #5738
Ihre vorgeschlagene
to-Klausel, wie im Beispiel von@scope (.media) to (.content)zu sehen, kann sich als nützlich erweisen.Wenn das Wort „to“ in „until“ geändert werden könnte, wäre es weniger verwirrend.
Widerspruch, wenn ich von meinem .home zum .stopsign renne, dann ist dort, wo ich aufhöre, ich gehe nicht darüber hinaus. Ergibt für mich Sinn.
Wow. Wir warten seit Jahren darauf….
Ich kehre immer wieder hierher zurück und hoffe, dass die vorgeschlagene Syntax weniger seltsam erscheint. Ich verstehe sie gut, aber ich sehe wirklich, wie ihre Verwendung zu völligem Chaos in großen Projekten führen kann.
Das Vermischen der @-Syntax, die hauptsächlich für Umgebungstests (Media Query, Supports etc.) verwendet wird, mit dem Selektorprozess erinnert mich an Last-Minute-Browser-Targeting-Hacks. Das Ganze wirkt einfach etwas unschön im Vergleich zu den verschachtelten Vorschlägen, die sich mehr dem CSS treu fühlen.