Ma io sono l'unico a pensare che sia assurdo che fare dei checkbox, dei radio, e degli campi per caricare dei file, siamo ancora costretti ad usare lo stesso tag generico che usiamo anche per il testo e password?
Avere dei tag dedicati sarebbe meglio per diversi motivi, come ad esempio la semplicità di applicazione dei css (e non essere obbligati a dare delle classi tipo "input_text", "input_checkbox", "input_password" per differenziare l'uno dall'altro), ed una maggiore possibilità di controllo sul comportamento dell'elemento...
Nel caso del checkbox, ora si utilizza così
Questo è secondo me sbagliato, perchécodice:<input type="checkbox" class="input_checkbox" name="form[blabla]" id="form_blabla" value="1" checked="checked" />
1 checked="checked" è ridicolo. Sarebbe meglio un status="checked"/status="none", oltre che più semantico.
2 abbiamo la possiblità di definire il valore che ha il checkbox solo se checkato. Se non è selezionato infatti lato server non arriverà nessuna traccia di questo elemento. Non sarebbe male la possibilità di definire un valore per entrambi gli stati?
3 <input type="checkbox" è prolisso a prescindere dal resto.
Qualcosa del genere non sarebbe meglio
Sono stati rimossi class e type, così ora da CSS si potrà semplicemente usarecodice:<checkbox name="form[blabla]" id="form_blabla" selected="1" unselected="0" status="checked" />
checkbox
{
}
al posto di cose tipo
.input_checkbox
{
}
oppure (e sappiamo chi non supporta questo)
input[type="checkbox"]
{
}
In più abbiamo la possibilità di definire dei valori per entrambi gli stati. Magari questi attributi possono essere opzionali, dando ad esempio on/off o 1/0 come attributi di default nel caso non si specifichi nulla (già adesso senza specificare value, il valore di default è "on").
Inoltre l'oscenità di checked="checked" è rimossa, in favore di un attributo più leggibile.
Stesso discorso vale anche per input[type="radio"], per input[type="file"], che continuo a non capire perché non viene modificato per renderlo più stilizzabile tramite css. Questo è inspiegabile secondo me.
Al posto di introdurre tante cose belle ma non del tutto utili con HTML5, perché non si approfitta del cambiamento per andare a rivedere e sistemare vecchi errori di progettazione come questo? Le modifiche possono venir introdotte senza rimuovere la vecchia maniera, così si mantiene la compatibilità. Non capisco...
Sono l'unico che si è mai fatto questi problemi? E' stata fatta qualche proposta a proposito, che voi sappiate?

Rispondi quotando