ASP.NET e standard XHTML

Con l'avvento delle nuove regole dettate dalla W3C riguardo alla scrittura del codice XHTML, anche il Framework si è adeguato e già il passaggio dalla versione 1.x alla 2.0 ha segnato notevoli miglioramenti sulla compatibilità del codice generato.

Ad oggi, è possibile dire che la maggior parte dei controlli lato server .NET sono standard XHTML 1.0 e XHTML 1.1 previa qualche piccola considerazione che andremo ad approfondire nel corso di questo articolo.

Prima di iniziare però una precisazione: il fatto che i controlli siano al 100% compatibili XHTML 1.0 Transitional ma non XHTML 1.0 Strict e XHTML 1.1 non vuol dire che casa Microsoft abbia "fatto male le cose", anzi, la non conformità del codice è dettata da una retro compatibilità, offerta dal Framework, che dà la possibilità, a chi possiede vecchie versioni di browser, di utilizzare le nostre applicazioni Web senza problemi. Si tratta quindi solo di una configurazione di default, che può essere cambiata a proprio piacimento ed in ogni momento.

Ma quali sono i passi da fare per rendere compatibile il codice prodotto dai nostri controlli server? Il Framework mette a disposizione uno strumento veloce ed efficace, che vedremo in seguito, ma è necessario valutare il comportamento di alcuni controlli prima di proseguire.

Form

Ipotizziamo di voler standardizzare il nostro codice alla versione XHTML1.0 Strict, in questo caso il primo controllo a darci dei problemi sarebbe il tag form onnipresente nelle pagine ASPX:

Una volta richiesta la pagina mediante browser, il codice fornito dal Framework contiene l'attributo name, non esistente per il tag <form>.

Image

Assicuriamoci di impostare sempre la proprietà AlternateText per il controllo Image. Se non popolata, nel codice risultante sarà omesso l'attributo alt, e quindi non conforme alle specifiche:

Allo stesso modo ragiona la proprietà ImageUrl del controllo Image. L'attributo src è obbligatorio per il tag <img> e se non valorizziamo ImageUrl il tag non verrà considerato conforme. Mentre è necessario non utilizzare la proprietà ImageAlign perché genera un attributo align in fase di rendering.

Tutti i controlli con attributo Target

I controlli con attributo Target vanno presi bene in considerazione, essendo questo attributo obsoleto e non conforme alle specifiche XHTML 1.0 Strict. I controlli in questione sono:

• AdRotator
• BulletedList
• HyperLinkColumn
• ImageMap
• MenuItemT
• TreeNode

Quindi è bene non indicare un target esterno altrimenti rischiamo di compromettere la validità del codice generato (in alternativa si può utilizzare codice Javascript).

Retro compatibilità

Nel caso che il Framework adotti un rendering del codice per renderlo retro compatibile (fino alla versione HTML 3.2, nel caso la richiesta venisse effettuata da vecchie versioni di browser o addirittura sconosciuti), ecco i vari comportamenti assunti da alcuni controlli:

• Il rendering dei controlli di convalida genera elementi <span> con attributi personalizzati, come ad es. ControlToValidate o ErrorMessage.
• Per supportare il postback della pagina, i controlli eseguiranno il rendering di un attributo language (ad es. language="javascript").
• L'attributo nowrap è previsto nei controlli che eseguono il rendering di un elemento <div>, come, ad esempio, il controllo Panel, se la proprietà Wrap del controllo è impostata su false.
• I controlli ImageButton eseguono il rendering di un attributo border.
• Il rendering di tutti gli elementi
presenti nella pagina viene eseguito proprio come <br>. Tuttavia, se si include esplicitamente un tag <br />, la pagina ne eseguirà il rendering nello stato in cui si trova.
• I controlli DataGrid e Calendar includono un attributo bordercolor negli elementi table di cui viene eseguito il rendering se viene impostata la relativa proprietà BackColor.

Ad un passo dallo standard

Come già detto in precedenza, dalla versione 2.0 del Framework si sono fatti notevoli passi avanti e, ad oggi, è possibile rendere compatibili XHTML 1.0 Strict le nostre applicazioni .NET con una semplice riga di configurazione nel file web.config:

L'elemento <xhtmlConformance> può avere come attributo mode i valori Strict, Transitional e Legacy. Di default, ovviamente, viene assegnato il valore Transitional ma per osservare meglio il comportamento dei controlli server, possiamo provare la modalità Legacy e visualizzare il codice HTML risultante (che se validato per XHTML 1.0 Transitional è ovviamente pieno di segnalazioni da parte del validatore W3C).

Questa semplice riga renderà le nostre applicazioni adeguate allo standard XHTML 1.0 Strict (e al XHTML 1.1, visto che deriva direttamente dal 1.0) senza doverci preoccupare di niente altro.

Ah, i vecchi browser!

Eh sì, la retro compatibilità è importante ma non sempre voluta. Pensiamo un attimo alla validazione del nostro sito mediante validatori come quello della W3C. Digitando l'URL del sito da validare, il servizio richiede la pagina indicata e la analizza segnalando eventuali errori di conformità del codice. Bene, questo servizio si presenta al Framework sotto forma di browser sconosciuto, per cui il rendering delle pagine assume modalità più "retrò" perdendo così la validità del codice.

Proprio per questo automatismo nel riconoscere il browser del richiedente, è necessario configurare l'applicazione in modo da garantire codice standard anche in presenza di validazioni W3C. Se vogliamo garantire compatibilità con i vecchi browser ma anche dare la possibilità di validare l'applicazione mediante il Validator W3C sarà necessario indicare al Framework che il "browser" W3C può gestire codice conforme allo Strict 1.0. Per farlo, sarà necessario aggiungere nella cartella App_Browsers dell'applicazione un file con estensione ".browser" (ad es. w3c.browser) contenente:

Il validatore W3C si presenta al sito come agente W3C_Validator, quindi associamo caratteristiche comuni dei più recenti browser in circolazione (supporto CSS/JavaScript, versione degli script, etc.) ed indichiamo l'uso della classe HtmlTextWriter (e non, come di default, Html32TextWriter che renderizza il codice seguendo lo standard HTML 3.2). In questo modo, da ora, anche il validatore W3C riceverà un codice conforme allo standard Strict.

In conclusione

Qualsiasi citazione trovata in rete riguardo alla non conformità XHTML delle pagine ASPX è assolutamente errata. Anzi, Microsoft mette a disposizione un potente strumento in grado di supportare versioni vecchissime di browser lasciando libero il programmatore da tutti i controlli di compatibilità. Ovviamente dovremo fare attenzione al codice statico che inseriremo nelle pagine: quel codice non viene interpretato dal Framework per cui anche un solo <br> senza chiusura può rendere non-standard la pagina.