Unobtrusive deriso

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?

sponsor

Commenti

  1. [1]

    L’idea mi piace, anche se personalmente preferisco un approccio leggermente diverso.

  2. [2]

    Hai perfettamente ragione, Andrea. Del resto i commentatori non erano particolarmente qualificati (molti anche anonimi o non identificabili).
    E’ vero che il parsing per classi è più lento, ma lì c’è di più, mi sembra manchi una cultura elementare degli standard.
    Ad esempio: “Behaviours should not be inline, since its the idea behind behaviours is to split view and controller”. E cosa c’entra il behaviour con il marcare un elemento con una classe? Ad una class possono corrispondere diversi comportamenti, attaccati in più fasi.
    Da specifiche (X)HTML inoltre l’attributo class può essere utilizzato “for general purpose processing by user agents”.

    Io personalmente lo uso molto per questo genere di tecniche unobtrusive. Talvolta utilizzo classi multiple anche per marcare gli elementi in modo Object Oriented (ad es. class=”object subobject attribute1 attribute3″). Poiché il tag class supporta contenuto CDATA, sarebbe possibile addirittura definire convenzioni più complesse di relazione tra le classi multiple, per evitare conflitti con eventuali widget di terze parti.

Inserisci il tuo commento

Aumenta l'altezza della textarea Riduci l'altezza della textarea