Hi,

Wieso sollte ein Parent Selector die Performance beeinträchtigen? Ab und zu wird von einem Aufwand O(n*n) gesprochen, ich jedoch erkenne nur ein O(1), zumal die maximale Zahl von Eltern eines Elements recht statisch ist. Ein Vorfahren-Selektor benötigt IMHO O(n), wobei dieses n tendenziell eher klein ist, wenn man es mit dem Nachfahren-Selektor vergleicht. Auch finde ich das o.g. "CSS processing model" nirgendwo - möglicherweise werden meine Fragen dort geklärt, daher wäre ich über einen Link dankbar.

Es kommt immer drauf an, von welcher Seite man das betrachtet.

Nimmt man einen Selektor und sucht dazu die passenden Elemente?
Oder hat man ein Element und sucht dazu die passenden Rulesets/Selektoren?

Wenn ich einen Browser implementieren würde, würde ich eher nach der zweiten Version vorgehen:
Um die Elemente darzustellen, durchlaufe ich den DOM-Baum.
Bei jedem Knoten == Element gucke ich, welche Selektoren darauf zutreffen, um die Darstellung des Elements zu regeln.
Mit den bisherigen Selektoren brauche ich dazu nur das Wissen über das Element selbst sowie dessen Vorfahren bis zum Root-Element *).
Diese Information liegt mir bereits vor, da ich ja im DOM-Baum über diese Vorfahren-Elemente gewandert bin, um zum aktuellen Element zu gelangen.
Mit einem Vorfahren-Selektor würde sich das ändern - ich bräuchte auch Informationen über die Kinder, Enkel, Urenkel, sprich: alle Elemente unterhalb des aktuellen Knotens.

*) sowie ggf. noch die Geschwister auf den Ebenen vom aktuellen Element bis hoch zum Root-Element.

cu,
Andreas

Hallo Cheatah,

ich weiss nicht, wie aktuell die inoffizielle www-style FAQ ist, aber die dort genannten Einschränkungen dürften wie von Andreas erklärt das www-style-Abschmettern erklären. Insbesondere der Vorzug für inkrementelles Rendering.

"E <  F" -- Vaterselektor

„Selektiert E, wenn F ein Kindknoten von E ist“

"E << F" -- Vorfahrenselektor

„Selektiert E, wenn der F-Knoten irgendwo ein Nachfahre von E ist“

Nehmen wir mal ein XML:

~~~xml <E attr="value">
    <n1/>
    <n2>
      <n3>
      <n4>
    </n2>
    <n5/>
    <F/>
  </E>

  
Als Browser hat man <e attr="value"> geparst, hat daraufhin ein E-DOMElement-Knoten erstellt, alle anderen Selektoren darauf überprüft, ob sie darauf zutreffen, und weil man inkrementell rendert eine (oder ::mehrere Boxen) in den Viewport eingefügt, die nun mit Inhalt befüllt werden.  
  
Man weiss aber noch nicht, ob nun die Regeln mit Vorfahrenselektoren zutreffen. Dazu muss man erst <n1>, <n2>, <n3>, <n4>, <n5> und <F> parsen und in DOM-Knoten verwandeln und Selektoren darauf anwenden und in das Dokument einfügen, ehe man weiss, dass "E << F { font-size:10em; }" hier wieder alles bislang gerenderte zunichte macht und man neu rendern muss.  
  
  
Tim

In der W3C-Mailingliste zu CSS wird öfter angefragt, ob dem Selectors-Modul ein Eltern- oder Vorfahrenselektor hinzugefügt werden könne […] Dies wird immer wieder abgelehnt mit der Behauptung, derlei Selektoren verursachten Performance-Probleme, oder "it doesn't fit the CSS processing model". Belegt werden diese Behauptungen nirgendwo, soweit ich es sehen konnte.

P.S.: Besonders schade finde ich, dass auf ähnliche Artikel in der Mailingliste keine Reaktion erfolgt ...

Recht viele Antworten erhielt http://lists.w3.org/Archives/Public/www-style/2006Sep/thread.html#msg211. Die Argumentation gegen Elternselektoren läuft dort stets auf die Verunmöglichung inkrementellen Renderings hinaus. Unmöglich im Sinne von adäquat schnell. Stelle ich mir ein wirklich großes Dokument mit tiefer Verschachtelung vor, dürften die meisten CSS-Implementierungen schnell überfordert sein.

Björn Höhrmann lieferte allerdings bereits 2004 ein meines Erachtens weit stichhaltigeres Argument: Besser geeignetere Sprachen existieren.

Roland