Che Internet Explorer non rispetti gli standard XHTML/CSS è noto. Nemmeno la nuova versione 7 è immune da una serie infinita di comportamenti anomali, non in linea con gli standard internazionali definiti dal W3C nel lontano 1999.
Ma il bug presente sull’elemento BUTTON è davvero interessante. Infatti non si tratta di una errata visualizzazione di un elemento, ma addirittura di una diversa trasmissione dei dati inoltrati al server attraverso una richiesta di tipo POST. Insomma non è un problema di tipo “visivo” uguale a quelli contro cui combattiamo giornalmente tutti noi sviluppatori di progetti web, ma un “difetto” di trasmissione dei dati al server.
E’ un bug non troppo noto per due motivi principali:
-
l’elemento BUTTON non è molto utilizzato dagli sviluppatori web perché può essere sostituito con l’elemento INPUT e in quasi tutti i form si trova quest’ultimo elemento;
-
nella quasi totalità dei casi un form ha un solo pulsante di invio e i dati inviati dal server vengono processati senza prestare attenzione al valore del pulsante di submit ma interpretando gli altri dati inviati tramite POST.
Talvolta però si ha la necessità di creare nello stesso form più pulsanti di invio, a ognuno dei quali corrisponde una diversa azione da compiere. E’ una eventualità molto remota, quasi mai necessaria nei siti internet. Ma nelle web application invece può capitare e allora ecco il problema.
Questo è il codice per inserire un pulsante BUTTON in un form
Dall’altra parte il server dovrebbe ricevere nella variabile $_POST[‘azione’] il valore test contenuto nell’attributo value.
E questo è quello che succede in tutti i browser, meno che su IE, in qualunque versione. Perché il browser di casa Microsoft nella variabile $_POST[‘azione’] ci inserisce il contenuto visualizzato dal bottone stesso e cioè nell’esempio sopra la stringa “Contenuto visualizzato del pulsante”.
Comportamento davvero bizzarro per un elemento che è stato creato appositamente per avere un valore da passare come parametro al server e una porzione di codice da inserire in fase di visualizzazione in modo da poterlo manipolare con i dovuti comandi CSS.
Diciamo subito che non c’è un bug fix, insomma Microsoft non ha corretto l’errore, evidentemente sono convinti che questo debba essere il comportamento corretto.
Vediamo ora alcune soluzioni
Primo caso
Se si ha la possibilità di modificare il nome dell’elemento BUTTON allora il gioco è già fatto.
Sullo script lato server basterà verificare se è definita la variabile che ci si attende e eseguire la corrisponde operazione
if(isset($_POST[‘salva’])){
funzione di salvataggio
}
if(isset($_POST[‘modifica’])){
funzione di modifica
}
Purtroppo questa soluzione semplice e lineare funziona su Explorer 7 ma non sul 6. Infatti quest’ultimo non si limita a passare al server solo la variabile che ha ricevuto il click del mouse ma anche tutte le altre variabili. In questo caso quindi lo script sul server non avrebbe modo di sapere quale azione è stata scelta nel form di invio.
Una possibile soluzione sarebbe quella di inserire all’interno dell’elemento BUTTON il vero valore dell’azione scelta nel form, magari includendola in un elemento SPAN e poi nascondendola attraverso l’istruzione display:none di CSS.
Sul server si potrebbe catturare tutta la stringa contenuta nella variabile $_POST[‘operazione’] e attraverso una espressione regolare andare a cercare il contenuto chiave, in questo esempio salva o modifica.
Ma l’utilità di utilizzare BUTTON al posto di un INPUT è quella che all’interno dell’elemento BUTTON ci può essere una porzione di codice HTML anche complessa. Questa possibilità, sommata alla necessità di inserire un codice invisibile per recuperare l’azione indicata dal pulsante, potrebbe generare un problema di accessibilità in quanto non si può essere certi che il testo invisibile sia effettivamente invisibile a tutti i dispositivi di lettura della pagina web, per esempio i lettori vocali.
Insomma, quello che in origine è un vantaggio in accessibilità potrebbe diventare un ostacolo in più.
Allora c’è sempre la possibilità di tornare sui propri passi e inserire di nuovo il pulsante di invio attraverso un campo INPUT, per esempio, nel caso di invii multipli, utilizzando un INPUT di tipo IMG.
Ma anche qui c’è da stare attenti perché ancora una volta IE, in tutte le versioni, non riconosce l’attributo VALUE del campo INPUT, ma restituisce solamente le coordinate X Y del punto in cui si è cliccata l’immagine.
Questo significa che non si potrà recuperare il valore di $_POST[‘operazione’] (perché in IE non esiste) ma si dovrà verificare l’esistenza di $_POST[‘operazione_x’], oppure $_POST[‘operazione_y’], cioè le coordinate del punto dell’immagine che ha ricevuto il click.
Anche in questo caso si può introdurre un elemento di inaccessibilità perché se anziché verificare la presenza della variabile si cercasse di individuare una cerca coordinata di XY, bisognerà tener presente che in caso di accesso al form con la tastiera e non con il mouse, le coordinate XY sono sempre 0.
Conclusione.
Dietro un semplice form con più pulsanti di input si possono nascondere una grande quantità di insidie, davvero difficili da trattare e spesso con soluzioni che rassomigliano di più a una toppa che a una soluzione vera e propria.
Tutto per colpa di Explorer, ovviamente.
]]>
Finalmente ci siamo il 2008 per me si apre così, con la nascita del mio nuovo blog.