Hi,

meine Frage richtet sich an alle jene, die in die Aktivitäten des W3C etwas mehr involviert sind als ich. Genauer gesagt habe ich ein Verständnisproblem zu den Begründungen, die zu folgendem Anliegen regelmäßig gegeben werden.

In der W3C-Mailingliste zu CSS wird öfter angefragt, ob dem Selectors-Modul ein Eltern- oder Vorfahrenselektor hinzugefügt werden könne (sinnvolle Suchbegriffe sind z.B. "selector" ;-), "parent", "predecessor" und ":matches"). 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.

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.

Hat sich jemand mit der Thematik bereits beschäftigt und kann mich erhellen? Gleichwohl würde ich mich über eine Diskussion über den Vorschlag folgender Selektoren freuen:

"E    F" -- Nachfahrenselektor (CSS/1.0)
"E >  F" -- Kindselektor (CSS/2.0)
"E >> F" -- Synonym zu "E F"
"E <  F" -- Vaterselektor
"E << F" -- Vorfahrenselektor

Das "E >> F" dient der Symmetrie zu "E << F" und sollte "E F" ablösen, ähnlich der "::xyz"-Syntax bei Pseudoelementen. Meiner Ansicht nach ist dieser Vorschlag kompatibel und unproblematisch; es sei denn, man rechnet mit fehlerhafter(?) Implementierung bestehender Engines, die z.B. ">>" als ">*>" ansehen.

Meinungen?

Cheatah

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