tizianocavigliablog
Niente panico! Ok, panico.

Una macchina di Rube Goldberg in HTML 06.05.16

Una macchina di Rube Goldberg in HTML

Il designer Sebastian Serena ha progettato una macchina di Rube Goldberg con gli elementi di un form HTML. Ipnotica.

HTML5Rocks 05.07.10

Google ha preparato una sandbox in cui condividere risorse, esperimenti e tutorial su HTML5. Un'evoluzione dello showcase di Apple.
La strada per il prossimo standard del web sembra essere tracciata.

Siamo pronti per HTML5 23.04.10

TLUC Blog sta migrando verso HTML5.

Lo spirito dell'early adopter ha preso il sopravvento.
Il desiderio di anticipare il futuro del web mi ha spinto verso questo esperimento.

Qui si è già pronti, ora tocca a voi.

Il futuro del web passa da HTML5 15.03.10

Mac Slocum: How is HTML5 different than HTML as we currently know it?

Eric Meyer: It's really the HTML we're all used to plus more elements. But that's the 80/20 answer. HTML5 adds new elements for things like sections of a document and articles, and figures and captions for figures. So it covers things that a lot of us do all the time, like create «div class="figure"» and then «p class="caption"» inside of that to go along with an image. Now there's just an element called "figure" and you insert an image and you have an element after that called "caption." There's been an attempt to look at what people are doing. What class names are people using over and over again? What structures are they setting up over and over again? Because HTML doesn't have elements that directly address those. The HTML5 spec also attempts to very precisely and exhaustively describe what browsers should do in pretty much any given circumstance. Older HTML specifications would simply say: "These are the elements. These are the attributes. Here are some basic parsing rules. Here is what you're supposed to do if you encounter an error." HTML5 has these really long algorithms that say: "Do this, then this, then this, then this. And if you hit a problem, here, do this other thing." There's a lot of debate as to whether that's even a good idea. But if the vision that's encoded in those algorithms is brought out -- I'm not saying it will be, but if it is, then browsers will be a lot more interoperable. But that's the base level answer. As you push further into the more obscure corners, then the answer to "how is HTML5 different?" becomes much more complicated.

Via O'Reilly Radar.

I super amici di HTML5 02.09.09

We, the undersigned, wish to declare our support for the direction in which the HTML5 specification is heading. Its introduction of a limited set of additional semantic elements, its instructions on how to handle failure, and its integration of application development tools hold the promise of richer and more consistent user experiences, faster prototyping, and increased human and machine semantics.

HTML5 is not perfect in our estimation, not that any markup language could be. In particular, we have significant concerns about some aspects of the specification. But we are optimistic that the official channels provided by the working group will offer a sufficient and fair hearing of our concerns.

Via HTML5 Super Friends.

Web developer 12.07.07

Perché bisogna abbandonare i frame? 30.09.04

Home page del sito: Rhadamanth.netIniziamo con un po' di storia. I frame sono nati per permettere all'HTML di evolversi da semplice linguaggio marcatore di testi statico ad aspetti di dinamicità.

L'introduzione dei frame permetteva per la prima volta di includere altri documenti HTML senza dover ricorrere a linguaggi lato server.

Occorre ricordare inoltre che tematiche quali l'accessibilità ancora non erano prese in considerazione. Non stupisce dunque che presero così piede nell'ambito della comunità di sviluppo web.

Tuttavia il web ed il codice negli anni si è evoluto, mentre i frame no. Questo ha trasformato i frame in uno strumento obsoleto e dannoso.

Altro aspetto importante è dovuto al W3C ed allo sviluppo di XHTML. XHTML è la rielaborazione di HTML secondo le specifiche XML. Questo dunque rende XHTML molto più inflessibile rispetto ad HTML 4.01. Il W3C ha inoltre deciso, per motivi che spiegherò più avanti, di incorporare i frame, e quindi il doctype di tipo Frameset, soltanto nella versione XHTML 1.0 per retrocompatibilità ed eliminarli totalmente dalla versione successiva, la 1.1. Questo già sarebbe un buon motivo per non utilizzare più tag non standard.

Analizziamo le cause che hanno spinto il W3C a deprecare i frame. I frame non rispettano l'accessibilità. Il motivo risiede nel fatto che gli screen reader non riescono ad interpretare correttamente una struttura di tipo frameset.

Ulteriore motivo è l'impossibilità di separare i contenuti dalla grafica. Utilizzando i frame è inoltre impossibile creare layout complessi e la modifica alla struttura risulta lunga e laboriosa, in quanto le modifiche andranno apportate ad ogni pagina del sito.

Anche sotto il profilo dell'indicizzazione i frame causano problemi. Gli spider infatti si comportano come screen reader. Indicizzano ogni pagina separata senza risalire al frameset, per cui potrà capitare di vedersi indicizzato solo il menu, solo il titolo, o solo i contenuti ma senza il menu. Non è piacevole vero?

I CSS ormai sono abbastanza maturi da poter permettere l'impiego di tecniche di inclusione lato server estremamente efficaci.

E' venuto il momento di abbandonare i frame, hanno fatto il loro tempo.