Perché i browser non implementano un selettore E:has(F)
Martedì 21 Luglio 2009 - 08:23
di Gabriele Romanato
A volte i produttori di browser ci fanno sentire come Alice nel paese delle meraviglie. Avevo recentemente proposto su www-style di implementare un selettore E:has(F) sulla scia di quanto avviene in JQuery per il metodo omonimo. In preda all’entusiasmo avevo anche azzardato un paragone tra C++ e JavaScript, dicendo che se era possibile farlo con quest’ultimo, perché non è possibile anche col primo?
La realtà è ben diversa. Dato per esempio un elemento h2 che contenga un elemento a, avremmo la seguente struttura DOM:
+--h2 #Element
+--a #Element
+-- #text
JavaScript riesce nel compito di selezionare l’elemento h2 in base alla presenza dell’elemento a al suo interno perché lavora sul DOM inteso come una serie di instantanee (snapshot) dotate di vita autonoma. Invece, il parsing CSS avviene in modo completamente diverso.
Per esempio, il parser CSS di Firefox (nsCSSScanner.cpp nel codice sorgente) lavora non su segmenti, ma su un flusso continuo di token forniti all’atto del parsing delle dipendenze della pagina. Il parsing CSS avviene quindi in modo incrementale. Implementare il selettore E:has(F) significherebbe bloccare questa “incrementalità” per operare una selezione inversa.
Dalle mie letture, infine, ho anche scoperto che un approccio di tipo DOM nel parsing è sempre molto “dispendioso”, cosa che i CSS non possono permettersi di essere.
Commenti
1
In realtà, correggimi se sbaglio, potrebbero se elaborassero XML e non html sporco.
# - postato da Andrea Paiola - 21 Luglio 2009 - 11:00
2
Non credo, correggete anche me, sia questione di XML valido o meno. Pima di poter usare DOM il documento deve essere comunque parsato per essere in grado di ricostruire la sua struttura (il “diagramma ad albero” utilizzato in DOM). Inoltre DOM è un meccanismo molto potente, ma è anche molto dispendioso in termini di memoria ed elaborazione.
Un browser per essere efficiente deve cercare di eseguire il parsing ed il rendering con il minor numero di passaggi sul documento, per cui DOM non gli serve a niente. Questo, se ho capito bene, è anche il motivo per cui non è possibile implementare la funzionalità E:has(F).
# - postato da Francesco Camarlinghi - 21 Luglio 2009 - 11:51
3
No, è per lo stesso motivo per cui in C++ per il parsing XML spesso viene usato SAX al posto del DOM: consuma meno memoria. Non è una questione di XML o HTML sporco, ma una questione di ottimizzazione della performance nel passaggio dalla fase di content sink al rendering finale. Il content sink, in sintesi, avviene dopo il parsing iniziale della risorsa da caricare.
# - postato da Gabriele Romanato - 21 Luglio 2009 - 12:08
4
boh, eppure via XPath avevo creato il selettore più veloce per Firefox 3.0 (3.5 ha querySelector/All) dove se non ho capito male E:has(F) è tradotto in //E//F … li come stiamo messi a C++?
5
… o era //E/F ? in entrambi i casi abbastanza veloce.