È una cattiva idea allontanarsi dalla sintassi del selettore CSS in un motore di selezione JavaScript?

Naviga le tue risposte
1

Sto progettando un motore di selezione JavaScript, e al momento sono concentrato sull'analisi della stringa del selettore. In particolare, combinatori.

I combinatori CSS3 che conosco sono:

  • > (figli)
  • space (discendenti)
  • + (prossimo fratello)
  • ~ (tutti i prossimi fratelli)

Che va bene per come funziona il CSS (come vengono applicate le regole di stile). Tuttavia, ora sto realizzando (ora che sto esaminando questo paradigma più da vicino) che questo sembra un po 'limitante in un'impostazione JavaScript.

Di seguito ho creato un elenco alternativo di combinatori. Quello che vorrei sapere è:

  1. I motori di selezione attuali si allontanano dai metodi di selezione CSS standard? (Conosco Sizzle e Sly, ma nessuno degli altri)
  2. Vedi qualche motivo per cui nessuno dei combinatori che ho elencato non funzionerebbe bene?
  3. Pensi che avere più opzioni per le stringhe di selettore (più combinatori, più filtri, ecc.) sia vantaggioso o solo un rifiuto / confuso / stupido / etc?

Grazie in anticipo per i tuoi pensieri!

  • > (figli)
  • >> (discendenti) (anche, lo spazio funzionerebbe ancora)
  • + (prossimo fratello)
  • ++ (tutti i prossimi fratelli) (anche, tilde avrebbe comunque funzionato)
  • - (fratello precedente)
  • -- (tutti i fratelli precedenti)
  • * (fratelli precedenti e successivi)
  • ** (tutti i fratelli)
  • ^ (genitore)

Esempio 1: div ^ span - ottieni tutti gli spazi con un figlio div

Esempio 2: div ** span - ottieni tutti i fratelli di span di div

Esempio 3: .lastListItem -- li - tutti li precedenti al li con la classe .lastListItem

Esempio 4: #thing ^ div ** .error - tutti gli elementi con classe .error che sono fratelli di genitore di # thing (supponendo che il genitore di # thing sia un div)

P.S. Oh, e ho anche pensato di avere un personaggio segnaposto che potesse rappresentare un semplice selettore. Quindi, l'Esempio 4 potrebbe apparire come questo (con un carattere di sottolineatura come segnaposto):

Esempio 4 alt: #thing ^ _ ** .error - tutti gli elementi con classe ".error" che sono i fratelli di genitore di # thing (non importa che tipo di elemento # il genitore della cosa sia)

    
posta encoder 14.12.2011 - 22:54
fonte

4 risposte

6

YES! È una pessima idea. Sizzle usa la sintassi CSS e le rocce per questo. Perché creare qualcosa fuori dal tuo standard, usa gli standard là fuori. Chi lo userà se non standard? La mania di HTML 5 è qui ed è su di essa per ottenere la maggior parte della base di utenti.

Fai sfrigolare il nucleo del motore di selezione di jQuery. Prendi questo e aggiungilo. Puoi anche imparare qualcosa da John Resig in termini di scorciatoie e tecniche di analisi. Quel ragazzo è una leggenda. Ho studiato il suo codice e sono diventato più saggio oltre a guardare tutti i video di Douglass Crockford.

    
risposta data 15.12.2011 - 00:29
fonte
4

Invece di inventare le cose, vorrei esaminare le funzionalità di CSS Selectors 4 Spec

E usa ! per contrassegnare l'oggetto di un selettore

Quindi, anziché div ^ span per selezionare le estensioni con un figlio div, puoi usare span! > div

EDIT: mi dispiace, le specifiche sono cambiate, non è un $ anteposto, è un ! aggiunto

    
risposta data 14.12.2011 - 23:37
fonte
2

Vantaggi dei selettori CSS:

  • Tutti li conoscono già. Servono il 99,95% degli scenari del caso d'uso e i selettori xpath si riempiono dove non lo fanno.

  • Al giorno d'oggi sono perfettamente performanti nella maggior parte dei browser supportati. Persino IE8 ha un metodo querySelectorAll nativo (ma ancora nessun metodo getElementsByClassName è abbastanza strano). querySelectorAll in realtà utilizza il motore CSS nella maggior parte dei casi, quindi perf può essere un po 'sorprendente, ma sarà comunque difficile superare un metodo nativo con controllo stringa seguito da logica.

Va bene reinventare la ruota. Incoraggio tale comportamento e! @ # $ Chiunque altro che dice diversamente. A meno che non ti paghi e non sia venerdì, ma quella cosa del venerdì e pagarti è pura fantasia da parte mia.

Ma se mi stai chiedendo se userò i miglioramenti del tuo motore di selezione, probabilmente no. Tra il conoscere l'API DOM core, jQuery e ora querySelectorAll, non ho eseguito un elemento o elementi che non potrei afferrare senza un breve one-liner in un tempo molto lungo. La maggior parte dei tuoi esempi suggerisce una necessità di codice che si basa molto su schemi di struttura HTML che per me è una ricetta per codice fragile che è difficile da leggere o richiede semplicemente un'altra chiamata al metodo nel core o jQuery che è molto meno sforzo e più leggibile che cercare di ricordare selettori che in realtà non sono CSS o X-Path.

    
risposta data 20.12.2012 - 06:31
fonte
1

Prima di andare troppo avanti nell'implementazione del tuo motore di selezione personalizzato, ti suggerisco di controllare se non stai solo reimplementando XPath . È un motore di selezione XML alternativo implementato dalla maggior parte dei browser

    
risposta data 15.12.2011 - 14:43
fonte

Leggi altre domande sui tag

Rifiutarsi di utilizzare un framework PHP sarebbe una cattiva idea? [duplicare] Tempo del compilatore rispetto al tempo del programmatore [chiuso]