Perché le persone hanno iniziato a ritenerlo necessario separare gli hook JS dagli hook CSS in HTML?

Forse lo noti perché, come hai detto tu stesso, devi lavorare con programmatori inesperti.

In pratica, la distinzione che osservi non esiste. I quadri, a proposito, scoraggiano questa distinzione.

Ad esempio, jQuery incoraggia molto bene ad usare i selettori in modo generale, il che significa che usi gli ID per indirizzare un singolo elemento e le classi per scegliere come target più elementi.

Allo stesso modo, uno sviluppatore non totalmente ritardato potrebbe notare rapidamente (apprendere) che le classi sono cattivi candidati per elementi unici in una pagina: naturalmente, è possibile sostituire tutti gli ID per classi sia in HTML che in CSS corrispondenti, ma farebbe le cose leggermente ... diciamo illeggibile , se a nessuno importa delle prestazioni.

Per quanto riguarda i programmatori inesperti, tendono a fare cose strane. Mi ci sono volute alcune settimane per spiegare a un collega che:

<div id="entry">Some text here</div>
<div id="entry">Some other text</div>

è sbagliato, perché gli ID sono unici. Prendi un principiante che ha appena letto un articolo che spiega come utilizzare le classi in CSS e un altro articolo sugli attributi data- in jQuery e capisci facilmente perché questo principiante inizia a utilizzare le classi per CSS e data- per i selettori jQuery.

Usare le classi per JS ha perfettamente senso.

Classi, come il loro nome suggerisce classificare elementi DOM.

Ad esempio, se avessi un elenco di elementi

<div class='item'>Item1</div>
<div class='item'>Item2</div>
<div class='item'>Item3</div>
<div class='item'>Item4</div>

Sarebbe perfettamente logico selezionarli con il seguente selettore .item invece di assegnare un ID a ciascuno di essi.

Inoltre, in molte librerie e basi di codice JavaScript comunemente usate si usano selettori di classe per selezionare gli elementi. L'ho visto usato più volte nel codice di produzione e sembra una pratica accettabile.

Le uniche persone di carne hanno con selettori di classe su selettori di ID è che i selettori di ID sono più veloci (perf qui ). Il più delle volte ho trovato che non ha molta importanza.

Ok, un flip-flop completo di ciò che avrei intenzione di scrivere, basato su due parti specifiche della domanda:

we had 200 offshore devs of varying levels code illiteracy (completely on the low end, not kidding)

e

Why would sharing attributes there ever cause a problem?

I ho eseguito in qualcosa di simile a questo nel progetto al quale sto lavorando al momento. Ciò di cui mi occupavo è ciò che accade quando i programmatori inesperti legano interamente le funzionalità alle classi, senza pensare a conseguenze o manutenibilità. (Cioè, erano riusare classi solo perché sono lì e si trovano su tutti gli elementi giusti)

Quello che stai guardando è un modo semplice, simile a una mazza, per rafforzare la separazione delle preoccupazioni sui programmatori non qualificati.

Se le funzionalità sono strettamente legate agli ID e progettano in Classi, allora possono cambiare entrambi senza doversi preoccupare dell'altro. Ciò è particolarmente utile dal punto di vista del design: purché includano tutti gli ID necessari per la funzionalità Javascript, stanno bene.

Detto questo, io strongmente non sono d'accordo con questo approccio (vedi altre risposte sul perché). È estremamente limitante anche per i programmatori decenti e quasi sempre richiede javascript di contabilità extra per tenere traccia di #foo_1 , #foo_2 ... quando .foo sarebbe stato sufficiente.

Vedi, al lavoro, abbiamo una libreria scritta in Django + JS + CSS, condivisa tra una grande fetta dei nostri prodotti. È stato scritto in un modo molto specifico, pensato per essere altamente configurabile e incluso in vari progetti tramite un template templatetag Django con argomenti usati per la configurazione del JS.

Purtroppo, perché il JS e il CSS erano legati insieme condividendo le classi, significava che alcune funzionalità che guardavano come opzioni completamente separate potevano funzionare solo se entrambe erano specificate, o entrambi erano rimasti fuori. E si escludevano a vicenda con un terzo. Qualsiasi altra combinazione ha causato l'errore di JS, perché avrebbe fatto supposizioni su quali classi esistessero nell'HTML generato.

Avevamo bisogno delle opzioni 2 e 3, ma non 1. Questa è stata una sfortuna, per non dire altro: ad esempio, l'Opzione 1 includeva le classi in stile CSS per l'opzione 2 JS _{(che usava solo perché, come descritto sopra, le classi erano già lì quindi perché no?)} . Quindi se hai usato l'Opzione 2 senza l'Opzione 1, ci sarebbe stata così tanta sfregiatura stilistica che sarebbe diventata inutilizzabile.

Ho battuto quel JS in sottomissione per circa tre mesi a questo punto, rendendo tutte e 3 le opzioni indipendenti l'una dall'altra e stirando i bug.

Questo lavoro extra non avrebbe dovuto essere necessario, e non lo sarebbe stato se l'intera faccenda fosse stata scritta bene all'inizio. Separare in modo forzato le classi su cui agiscono JS e CSS avrebbe contribuito a impedire che l'Opzione 1 e l'Opzione 2 venissero legati insieme quando era stato scritto per la prima volta.

Detto questo, in genere non è possibile essere al 100% su questa regola. Uno di questi è una semplice classe .loading che viene aggiunta / rimossa se necessario.

In primo luogo, non penso che la separazione sia assoluta. gli id, ad esempio, sono unici per un documento e quindi ha senso utilizzarli sia per CSS che per JS. Per le classi però, ci sono buone ragioni per cui queste devono essere separate.

Il problema di base è che CSS e JS implementano ciò che potreste pensare come preoccupazioni incrociate. Il CSS implementa il layout, la visualizzazione e la tipografia, mentre JS implementa il comportamento. O almeno questo è il modo in cui sono usati più spesso (e penso che sia il migliore). Puoi pensare a questi come a preoccupazioni o dimensioni ortogonali, e quindi potrebbe essere necessario posizionare singoli oggetti DOM, non in una riga di funzionalità, ma piuttosto in un'area bidimensionale in cui le dimensioni sono display e funzionalità.

Ancora una volta, se vuoi cercare un singolo elemento, CSS e JS possono farlo entrambi per ID, ma se vuoi cercare un gruppo probabilmente non vuoi legare troppo display e comportamento.

Questo è un problema generale e non penso che dipenda dal livello di esperienza degli sviluppatori o dagli strumenti che stai utilizzando. Finché le preoccupazioni sono diverse potresti voler essere in grado di classificare gli elementi in base a più tipi di preoccupazioni e questo è un modo in cui ciò avviene.