Eindeutige Identifizierung mit Marker von verschachtelten Selektorern sinnvoll???

[MB]

moin,

Frage
Ist eine eindeutige Markierung in Form von einer einmaligen Klassenkonstellation als Identifier für den Cascade-Algorithmus in einer extrem von div & span-Tags verschachtelten HTML Struktur sinnvoll? Der Algorithmus muss sich ja zusätzlich zur GUI mit meine duzende CSS-Snippets auseinandersetzten oder ist für ihr unerheblich und nur für die CSS Entwickler wichtig?

Background
Das GUI der Obsidian App ist ausschließlich in HTML entwickelt und insofern auch extrem verschachtelt.

View Beispiel
Schema der Views im Code (zur Verdeutlichung vereinfacht)

…
  <div class="view">
    …
      <div class="markdown is-source-view">
        …
          <div class="header header-1">
            Lorem Ipsum…
    …
      <div class="markdown is-pre-view">
        …
          <div class="header header-1">
            Lorem Ipsum…
      <div class="markdown is-read-view"> 
        …
          <h1>
            Lorem Ipsum…

.is-source-view, .is-pre-view und .is-read-view kommen selten in der GUI vor aber in Kombination mit .markdown sind sie eindeutig identifizierbar (z.B.:is( .markdown.is-source-view * ) {}).

Identifier Beispiel
Beispiel mit dem View Identifier in einem externen CSS Snippet

.view { 
  & :is( .markdown.is-source-view * ),
  :is( .markdown.is-pre-view * ) {
    .header { color: red }
  } 
   /* Identifier ist hier unnötig */
  & :is( .markdown.is-read-view * ) {
    h1 { color: green }
  } 
}

Bitte schreibt mich an, fals etwas unklar erscheint. Ich tu mein möglichstes.

Ich freue mich aus AWs 😀

lgmb

[Rolf B]

Hallo MB,

schön, dass Du CSS-Nesting aufgegriffen hast 😀

Grundsätzlich gilt: Mach Selektoren so spezifisch wie nötig, aber nicht spezifischer. Wenn Du zu spezifisch bist, dann hast Du (a) mehr Schreibarbeit und (b) unnötige Abhängigkeiten zwischen HTML und CSS. Dem CSS Parser wird es egal sein. Ob die Layout-Engine durch überspezifische Selektoren gebremst wird, weiß ich nicht.

Dies hier ist aber - unabhängig von deiner Frage - nicht sinnvoll oder müsste anders formuliert werden.

.view { 
  & :is( .markdown.is-source-view * ),
  :is( .markdown.is-pre-view * ) {
    .header { color: red }
  } 
  ...
}

Das & im geschachtelten Selektor gilt nur für den Teil der Selektorliste, in dem es steht (also bis zum Komma). Im zweiten Teil gilt es nicht.

Es ist aber in beiden Teilen der Selektorliste nicht nötig. Die Selektoren der Liste beginnen nicht mit einem Typselektor (also einem Elementnamen), deswegen funktioniert es auch ohne &, selbst in Chrome.

Und dann hast Du ein :is(), das keine Selektorliste, sondern nur einen einzelnen Selektor enthält. Das ist kein Fehler, aber unnötig. Das :is() kannst Du weglassen. Anders wäre es in dieser Formulierung:

.view {
   .markdown {
      &:is(.is-source-view, .is-pre-view) * {
         .header { color: red }
      }
      &.is-read-view * {
         h1 { color: green; }
      }
   }
}

Wichtig ist hier, dass zwischen & und dem Rest des Selektors keine Leerstelle steht, damit .markdown und .is-...-view auf das gleiche Element zielen.

Ob das Sternchen nötig ist, muss Du wissen. Es verlangt, dass das .markdown-Element kein direktes Elternelement des .header oder h1 Elements sein darf. Also:

<div class="markdown is-source-view">
   <div class="header">DIRECT HEADER</div>
   <div class="sep">
      <div class="header">INDIRECT HEADER</div>
   </div>
</div>

DIRECT HEADER bliebe ungefärbt, INDIRECT HEADER würde rot. Ist diese Unterscheidung für Dich wichtig? Dann lass das * drin. Andernfalls kann es weg.

Wenn Du in .view { ... } weiter nichts steht als .markdown { ... }, kannst Du die Schachtelung auch reduzieren.

.view .markdown {
   &:is(.is-source-view, .is-pre-view) * {
      .header { color: red }
   }
   &.is-read-view {
      h1 { color: green; }
   }
}

Rolf

[MB]

moin,

schön, dass Du CSS-Nesting aufgegriffen hast 😀

🤨? 😬🙏 Sry, mir fehlt der Kontext zu der Bejubelung 😅?

Grundsätzlich gilt: Mach Selektoren so spezifisch wie nötig, aber nicht spezifischer. […]

Danke für den Rat!! Klingt einleutend

[…] Ob die Layout-Engine durch überspezifische Selektoren gebremst wird, weiß ich nicht.

Leihenhaft gesprochen schätze ich, dass der Parser durch mein übermäßiges spezifizieren der Selektoren nur >ms mehr bräuchte um zu rendern

Das & im geschachtelten Selektor gilt nur für den Teil der Selektorliste, in dem es steht (also bis zum Komma). Im zweiten Teil gilt es nicht. […]

[…] Anders wäre es in dieser Formulierung.

Verstehe. Danke das du das anmerkst 👍. Mein kleines-großes Problemchen ist mir untergegangen hier im Forum zu Fragen. Jetzt wird mir einiges Klar, warum an manchen Stellen ein & stehen muss und bei anderen kann.

Danke für die Auskunft 😀.

Ob das Sternchen nötig ist, muss Du wissen. Es verlangt, dass das .markdown-Element kein direktes Elternelement des .header oder h1 Elements sein darf.

Muss nicht aber allein für meine Struktur ist es besser

DIRECT HEADER bliebe ungefärbt, INDIRECT HEADER würde rot. Ist diese Unterscheidung für Dich wichtig? Dann lass das * drin. Andernfalls kann es weg.

Nur n Beispiel.

Wenn Du in .view { ... } weiter nichts steht als .markdown { ... }, kannst Du die Schachtelung auch reduzieren. […]

Habe ich tatsächlich in einem anderen Kontext im notwendigen Übermaß verwendet, hier jedoch nicht aber werde ich tun. Danke dafür 😀.

Schönen Abend

lgmb