Il tutto nasce agli albori della guerra tra i browser che fortunatamente ora sta andando sempre di più verso un favorevole epilogo, favorevole per gli utenti, cioè una implementazione sempre migliore degli standard w3c. Ma non è stato sempre così…Andiamo con la memoria ai tempi della versione 4 di Explorer e di Netscape. A quei tempi, l’implementazione dei CSS era a dir poco sconcertante e sebbene Explorer li rispettasse maggiormente di quanto non facesse Netscape, i siti venivano comunque visti in maniera non corretta. Explorer 5 ovviò a parecchi bug, ma l’implementazione era lontana dall’essere rispettata in maniera perfetta. Gli sviluppatori pertanto dovevano progettare i propri siti cercando in tutti i modi di adattarsi ai diversi browser e per questo il codice non era molto rispettoso degli standard. Quando poi il rispetto degli standard divenne importante, i produttori dei browsers si trovarono di fronte ad un grosso problema, infatti i siti che avrebbero rispettato gli standard sarebbero stati visualizzati correttamente mentre quelli progettati precedentemente e con un supporto agli standard misero, sarebbero stati visualizzati in maniera non corretta. Pertanto, i browsers dovevano favorire chi conosceva gli standard e progettava secondo questi, ma nondimeno dovevano permettere alle pagine non correttamente sviluppate, di essere viste in maniera decente. La soluzione a questo fu appunto la creazione di browser in grado di riconoscere le pagine sviluppate correttamente e quindi visualizzare secondo gli standard, e quelle non correttamente sviluppate e quindi visualizzarle con una modalità non conforme, detta appunto “quirks mode”. Per fare ciò il browser si affida al DOCTYPE e in base a questo decide come visualizzare la pagina. Fare questo viene definito “doctype switching” e viene implementato come segue:

1. Un doctype completo XHTML 1.0 o 1.1 attiva la modalità Standards (secondo gli standard) in versioni conformi di IE e nelle prime versioni di Gecko (Netscape 6 e Mozilla 1.0)

2. Un doctype completo XHTML Strict ha lo stesso effetto in tutti i browser sopra elencati con l’aggiunta di mozilla 1.01+, netscape 7, firefox 1+, camino

3. Un doctype completo XHTML 1.0 Transitional o Frameset attiva la modalità “Quasi Standards” negli ultimi browsers Gecko

4. Inoltre, a proposito del prologo XML, nonostante abbiamo inserito un doctype completo e che quindi dovrebbe attivare la modalità standard, con il prologo xml, IE6 per Win e Opera 7, vi porteranno in modalità Quirks

5. Doctype incompleti attivano la modalità Quirks in tutti i browsers che implementano il doctype switching

Già, avete sentito bene, c’è anche una modalità “Quasi Standards”. Si chiama così perché differisce dalla modalità Standards di IE per qualche dettaglio. Per questi dettagli, per il modo in cui si comportano i browser con le varie modalità, vi rimando prossimamente per un post a riguardo, dove inizierò a parlare del “BOX MODEL” dei vari browsers, non mancate!

Nel precedente articolo “primi passi con l’xhtml” ho omesso di dire che prima della dichiarazione del DOCTYPE va inserito il prologo XML. Tale omissione è voluta in quanto col prologo, alcuni browser tendono a non comportarsi in maniera corretta, passando alla visualizzazione in QUIRKS MODE: dei vari tipi di visualizzazione da parte dei vari browsers, parlerò prossimamente. Dunque, ma cosa è questo prologo XML? Il prologo XML è riportato di seguito:

<?xml version=”1.0″ encoding=”iso-8859-1″?>

e la sua funzione è quella di dire esplicitamente il fatto che il documento è un documento XML. Non è obbligatorio e infatti il codice del precedente articolo è perfettamente valido. Nel prologo è possibile avere tre attributi, qui ne vediamo solo due. Il primo è la versione, version, e il suo valore può essere solo 1.0 in quanto non esistono altre versioni. Il secondo è encoding e serve ad indicare quale tipo di codifica per i caratteri abbiamo utilizzato. Qualora non usassimo il prologo XML, tale attributo è possibile indicarlo con la direttiva  “<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″/>”. Come ultimo attributo per questo prologo, abbiamo standalone che può assumere i valori di yes o no e indica se il documento è indipendente o meno, cioè se non fa riferimento ad entità esterne.

Abbiamo quindi in questo modo analizzato ogni parte del nostro documento XHTML, ma, come dicevo prima, poiché la compatibilità non è al 100%, il prologo può essere omesso tranquillamente qualora il vostro obiettivo fosse la piena compatibilità. Nei prossimi articoli saranno trattati alcuni temi inerenti i CSS, soprattutto la creazione di box con gli angoli smussati, non mancate!

XHTML, acronimo di eXtensible HyperText Markup Language, è un linguaggio di markup basato sull’HTML in conformità alle regole del più rigido XML. Con l’introduzione di questo nuovo linguaggio si è cercato di separare ulteriormente la struttura della pagina dal layout. Si cerca, infatti, ormai da tempo, di introdurre e di consolidare un tipo di markup definito semantico in quanto ogni elemento dell’XHTML deve avere un proprio ruolo conforme al proprio significato all’interno della pagina. Inoltre il layout è demandato all’uso dei CSS dei quali parlerò profusamente nei prossimi post.

Ritornando all’XHTML è quindi più rigido dell’HTML classico. Una specifica Document Type Definition (DTD) definisce l’insieme di regole mediante le quali un dato documento può essere renderizzato (cioè rappresentato correttamente) dall’XHTML. La maggior parte dei browser attualmente più diffusi è già in grado di renderizzare correttamente i documenti XHTML. Ma anche i browser più vecchi sono solitamente in grado di interpretare i documenti XHTML, poiché questo linguaggio è in buona parte un sottoinsieme dell’HTML. Lo stesso vale anche in senso inverso: quasi tutti i browser compatibili con l’XHTML renderizzano correttamente i documenti HTML. Secondo un’opinione diffusa, questo alto grado di compatibilità sta rallentando il passaggio da HTML a XHTML. L’XHTML Transitional si distingue dall’HTML principalmente perché è più compatibile con le specifiche dell’XML. La differenza più importante è che tutti i tag devono essere ben strutturati. Inoltre i tag devono essere sempre scritti in lettere minuscole, convenzione in contrasto con l’abitudine invalsa a partire dalla versione 2.0 di HTML, quando la maggior parte dei programmatori preferiva le maiuscole. Nell’XHTML tutti gli attributi (compresi quelli numerici) devono essere scritti fra virgolette, cosa facoltativa in SGML e HTML, in cui le virgolette possono essere omesse se il contenuto è una stringa alfanumerica o comprende alcuni altri caratteri speciali riservati. Tutti gli elementi del linguaggio devono inoltre essere terminati, compresi quelli vuoti (ad esempio img e br). Per eseguire la terminazione in modo implicito si può aggiungere una “/” di chiusura al tag di apertura (es: <img … /> e <br />). Altri tipi di abbreviazione non sono invece permessi (es: <option selected>).

Versioni di XHTML

• XHTML 1.0 Transitional: nato per favorire la migrazione dal HTML 3.2 consente l’utilizzo di link e frame in-line
• XHTML 1.0 Strict: separa il contenuto dal layout, cioè dalla presentazione, che ora viene definita mediante i CSS. Strict, quindi rigido in modo assoluto.
• XHTML 1.0 Frameset: per suddividere la finestra visualizzata dal browser in diversi frame

L’ultima versione di XHTML è la:

• XHTML 1.1: avendo un’unica DTD, la strict, ne viene omessa la dicitura. Non accetta né tag o attributi deprecati né la struttura a frameset.

In corso di definizione sono le specifiche XHTML 2.0. Inoltre, come avrete appreso ultimamente, il w3c è in procinto di rilasciare anche le specifiche HTML 5.0. Staremo a vedere di cosa si tratta, non mancate, ne vedremo delle belle

Molti considerano Ajax come il futuro del Web, altri come una semplice moda. AJAX (Asynchronous JavaScript And XML) si basa su tecnologie che in realtà non sono affatto nuove. JavaScript è disponibile da oltre 15 anni e DOM, CSS, XHTML, XML sono stati introdotti anni prima dell’invenzione del termine Ajax, così come l’oggetto XMLHttpRequest.

Le novità invece riguardano l’introduzione di nuovi modelli di sviluppo, resi possibile dall’avento della nuova generazione di browsers. In poche parole, quando i tempi si sono dimostrati maturi, qualcuno l’ha capito che ha creato qualcosa di nuovo utilizzando componenti e tecnologie già consolidati. Quel qualcuno è stato Jesse James Garrett nel suo famoso articolo “Ajax: a new approach to web applications”, disponibile QUI.

A differenza quindi di tutti i vecchi o altri approcci che richiedono plug-in o non sono compatibili con tutti i browsers, Ajax funziona nella maggior parte dei moderni browsers e non richiede alcun software o hardware proprietari. Questo è infatti uno dei punti di forza di questo approccio, quello di consentire agli sviluppatori di non dover imparare un nuovo linguaggio o scartare le conoscenze acquisite sul lato server. Ajax è un approccio, sì sul lato client, ma in grado di interagire con gli script J2EE, .NET, PHP, Ruby e CGI: è davvero indipendente dal server.

Da come si sarà intuito dal termine Ajax gestisce le richieste del browser in modo asincrono. Asincrona è quindi l’abilità di gestire un processo indipendentemente da altri. Con un trasferimento di dati sincrono lo script ha bisogno di essere processato prima di passare ad un secondo elemento. In questo modo il secondo elemento dipende sempre dal primo. In questo modo si crea un collo di bottiglia di una connessione tra pagina Web e browser. Gli Style tag e i link nella sezione head di un documento creano lo stesso effetto collo di bottiglia. Vengono processati uno alla volta prima che altri elementi della pagina siano scaricati. Una volta che sono stati processati, gli elementi nella sezione body possono usare connessioni che occorrono nello stesso tempo per velocizzare il processo di download. Per esempio, la maggior parte dei server gestiscono fino a due a quattro connessioni nello stesso tempo tra pagina Web e browser. Questo significa, che da 2 fino a 4 immagini o altri elementi della pagina sono caricati nello stesso tempo. Prima che il processo inizi, quello che c’è tra i tag head deve essere processato per primo e può rallentare considerevolmente il caricamento della pagina. Quasi tutte le pagine Web e i blog su Internet utilizzano questo metodo. Non è difficile comprendere come questo comporti un rallentamento nel caricamento delle pagine Web. Il metodo di caricamento asincrono è differente perchè il processo di caricamento è gestito in maniera indipendente superando il collo di bottiglia del design tradizionale delle pagine Web. L’essenza di questa tecnica sta nell’uso minimale del JavaScript e poi nello spingere tutti gli altri tag correlati, incluso il resto del JavaScript, CSS etc attraverso un xmlhttprequest object. Questo metodo utilizza molteplici connessioni aumentando la velocità della pagina considerevolmente.

Ajax è quindi una tecnica che si basa su tecnologie consolidate in grado di offrire una nuova frontiera allo sviluppo web. Con Ajax il confine e il divario tra applicazioni web e applicazioni desktop si è ridotto notevolmente e credo che prima o poi verrà abbattuto definitivamente.