Ho letto con interesse il post intitolato Automating JS behavior registration pubblicato lo scorso 16 Maggio nel blog duck_typer.
Perché lo reputo interessante? Per il semplice fatto che si basa sulle classi degli elementi e aggiunge funzionalità JavaScript in un secondo momento.
Questo approccio è a mio avviso il più corretto per sfruttare un layout quanto più pulito, libero da implementazioni client e, perchè no, molto curabile graficamente grazie alla potenziale mole di informazioni CSS.
Scopro invece tra i commenti di Ajaxian che tale pratica è stata addirittura derisa praticamente da tutti.
Motivo principale è il nome prolisso scelto per il CSS, indubbiamente più pesante di un semplice:
onclick="return funzioneCallback(event)"
e sicuramente anche meno pesante da gestire a livello di DOM, dove non necessariamente tutti i nodi devono essere letti per cercare le classi di riferimento.
Quello che non mi è chiaro è perchè librerie come jQuery, Dojo, Prototype, YUI! e altre ancora, abbiano perso tanto tempo per implementare veloci parser DOM basati su selettori CSS, Xpath e chi più ne ha più ne metta.
A quale scopo aggiungere questi utili metodi se poi la lettura del DOM diventa motivo di grasse e pubbliche risate?
Perché sfruttare un CSS, avendo la possibilità di usare un nome classe sia per l’aspetto che per le funzionalità aggiuntive, dovrebbe far sorridere piuttosto che applaudire?
Certo è che invece di un nome così lungo avrebbe potuto sfruttare più classi separate da spazi ma altrettanto vero è che questo tipo di approccio è parte dei rari casi dove la parola unobtrusive, riferito al JavaScript, non perde di significato.
Voi avete mai pensato di sfruttare un CSS anche per aggiungere informazioni utili al JavaScript?