O Futuro do HTML

Este artigo foi apresentado originalmente por Lachlan Hunt, (tratando-se pois de uma tradução/adaptação) na reunião do Web Standards Group em Sydney em 25 de Janeiro de 2007

Pode aceder ao original, aos diapositivos de apresentação (é necessário o PowerPoint ou outra aplicação que possa ler o formato PPT) e à gravação em áudio (Ogg Vorbis) todos em língua inglesa

Este apresentação encontra-se em domínio público. Se desejar pode converter o áudio e os diapositivos para um formato diferente, faça o favor.

Evolução do HTML

No princípio dos anos 90, Tim Berners-Lee concebeu o HTML, mas não havia especificação formal escrito do HTML 1.0 e embora houvesse similaridades sintáticas com, não era baseado formalmente no SGML.

O trabalho continuou nos anos seguintes e em 1995 a [especificação] HTML 2.0 foi publicada como RFC 1866 que definia formalmente o HTML [a linguagem] como uma aplicação do SGML. Contudo os navegadores não se preocupavam ainda em implementar analisadores de SGML e, mesmo nesse período inicial, começaram a aparecer várias extensões proprietárias.

Por volta de 1996 a guerra dos navegadores estava ao rubro. Havia extensões proprietárias a voar em todas as direcções e uma abundância de páginas com erros dependentes de erros nos navegadores para poderem funcionar. Isto eventualmente veio a ser conhecido como "Sopa de Marcadores". Num esforço para normalizar este lixo, o W3C publicou a HTML 3.2 em 1997 e a 4.0 no ano seguinte que acabou por desaconselhar muitas das capacidades de apresentação que tinham acabado por penetrar.

Por essa altura parecia que a vida do HTML estaria a acabar e começou o trabalho sobre o XHTML. Após a publicação do HTML 4.01 no final de 1999 para resolver alguns pequenos problemas, o trabalho no HTML como aplicação do SGML terminou e o Grupo de Trabalho do HTML tem vindo desde aí a recomendar o XHTML.

Parecia ser um passo para se separarem eles mesmos dos grandes erros do passado, o Grupo de Trabalho do HTML começou a trabalhar nas especificações do XHTML 2.0 em 2002. Contudo, não foi concebido com retrocompatibilidade na mente, foi concebido como um novo arranque com uma nova linguagem de marcação, embora muitos considerem isso a principal barreira para que o XHTML possa levantar voo.

WHATWG

Ao longo dos anos a Apple, Mozilla e Opera têm vindo a ficar cada vez mais preocupados com a direcção que o W3C tem vindo a imprimir ao XHTML e aparentemente com o desrespeito pelas necessidades dos autores do mundo real. Assim, em 2004, dirigido por Ian Hickson, esta organização estabeleceu como sua missão ir de encontro às necessidades tanto dos utilizadores como das pessoas que fazem desenvolvimento e assim nasceu o Web Hypertext Application Technology Working Group.

Objectivos do WHATWG

Os objectivos do WHATWG incluem documentar comportamento dos navegadores actualmente existentes, normalizar extensões proprietárias suportadas de forma genéria e úteis e desenvolver novas capacidades práticas que vão ao encontro dos pedidos tanto de utilizadores como pessoas que desenvolvem enquanto se assegura a retrocompatibilidade e se definem técnicas de tratamento de erros robustas.

As Especificações

Ao longo dos últimos dois anos, têm vindo a planear e trabalhar em 3 especificações separadas: Web Applications 1.0, Web Forms 2.0 e Web Controls 1.0. Em conjunto estas três especificações são conhecidas colectivamente como HTML 5.

Web Applications 1.0

A especificação Web Apps 1.0 redefine a síntaxe e os requisitos de análise do HTML de forma a ir de encontro ao modo como os actuais navegadores tratam a sopa de marcadores, introduzindo novas estruturas e semântica de documento e APIs de DOM, muitas das quais são especialmente concebidas para construção de aplicações.

Web Forms 2.0

A finalidade das Web Forms 2.0 é expandir os formulários da HTML 4 com novos controlos, um modelo de repetição, validação do lado do cliente melhorada e uma nova API de DOM para trabalhar com formulários e controlos.

Web Controls 1.0

Por último, a especificação Web Controls 1.0 ter por finalidade melhorar o CSS e o DOM para construção de controlos e widgets. Contudo, até ao presente, pouco tem sido feito nesta área e ainda não há muito a dizer.

Representação de Documento

O HTML 5.0 introduz o conceito de serializações para um documento HTML. Uma serialização neste contexto refere-se à sua representação física. O HTML5 usa serialização HTML e o XHTML5 usa serialização XML. Devido a isso, a distinção entre um documento HTML e XHTML foi reduzida.

Há contudo, algumas capacidades que não podem ser de todo representadas. Por exemplo, os espaços de nomeção podem ser usados no DOM e na serialização XHTML mas não podem ser usados na serialização HTML.

Como consequência, isto trata do debate HTML versus XHTML de uma vez por todas. Hoje em dia muitos autores usam um DOCTYPE XHTML 1.0 e depois dizem que usam XHTML, mas na realidade usam HTML porque os navegadores tomam a decisão de tratar um documento como HTML ou XHTML baseados no tipo MIME.

Assim, ao contrário de versões anteriores, a escolha entre usar HTML ou XHTML não depende do tipo de DOCTYPE usado. Só depende do tipo MIME. Se o documento for servido como text/html, é um documento em HTML e é analisado como tal, mas se for servido com um tipo XML MIME como: application/xhtml+xml, é XHTML e é analisado como XML.

Suporte de Navegador para HTML

Na realidade analisar o HTML é um pesadelo. A web está literalmente cheia de um número infinito de páginas, número em crescimento diário e os navegadores são forçados a tratá-los todos com fineza. Não se podem permitir a darem erros independentemente do HTML ser inválido e completamente roto.

O principal problema é que há uma séria falta de interoperabilidade, que é resultante directa do facto da análise e tratamento de erros não estarem bem definidos em HTML e seguramente não definidos de um modo que seja compatível com a web.

Há também muitas extensão proprietárias que são muito usadas e bem suportadas. O problema com isto é que estas capacidades não estão bem definidas e os produtores de navegadores gastaram anos de engenharia reversa uns em relação aos produtos dos outros.

Se a engenharia reversa tivesse de algum modo sido aplicada na ajuda ao desenvolvimento de interoperabilidade entre navegadores, o processo está longe de ser perfeito e seria muito melhor se as extensões muito usadas pudessem ser bem documentadas e a interoperabilidade implementadas, que é exactamente o que o WHATWG está a tentar fazer.

Temas Relativos à Interoperabilidade

Para ilustrar a falta de interoperabilidade, vejamos um simples e comum erro de marcação e mostrar como o mesmo é tratado em diferentes navegadores. Neste exemplo os elementos strong e em foram aninhados incorrectamente.

Neste caso o Firefox e o Safari produzem o mesmo resultado, embora usem diferentes algoritmos de análise. Na representação do DOM, vejam que há 2 elemento em, embora só um surja na marcação. Para contornarem o erro de facto eles fecharam o elemento em quando o seu elemento parental fechou e criaram um novo imediatamente após.

Comparem isto com o IE, que em vez de criar 2 elementos em cria antes um DOM mal construído visto não ser estritamente uma árvore. Vejam como é que o elemento em tem 2 nós filhos, b e c, mas que o nó de texto c se refere ao elemento p como seu parental directo em vez de se referir ao elemento em.

Por último o Opera cria um DOM similar ao do IE com a excepção de que se trata de uma árvore propriamente dita. Mas o problema com esta aproximação é que o nó de texto c é um descendente do elemento strong, mas não é reproduzido como tal. Por omissão, só é reproduzido em itálicos, não a negrito, como se poderia esperar com este DOM.

Assim podem ver, com este exemplo simples, que os navegadores tratam da marcação de modo diferente. E lembrem-se que a web está cheia de um número de páginas com erros bem mais complicados do que estes.

Análise HTML 5 (só para text/html)

Em HTML, o DOCTYPE tem 2 finalidades práticas: validação e cheirar o DOCTYPE. Na actualidade a maior parte das pessoas que desenvolvem que estejam a par dos standards usam um DOCTYPE quer HTML quer XHTML, tanto Strict como Transitional. Visto o HTML 5 já não ser formalmente baseado em SGML e visto a validação baseada em DTD ter muitas limitações em relação à verificação de conformidade, o HTML 5 deixou de recomendar o uso de um DTD. Assim os verificadores de conformidade são livres de usarem a metodologia que gostarem para verificarem a validade e conformidade do documento desde que o resultado final seja o mesmo.

O DOCTYPE

Contudo há ainda questões práticas sobre como despoletar o modo standard e assim é necessário alguma forma de DOCTYPE com essa finalidade no HTML

No HTML 4, o DOCTYPE era longo e complicado com muito poucas pessoas a lembrarem-se de facto dele na totalidade. Os identificadores complexos PUBLIC e SYSTEM são usados para se referir ao DTD. Mas visto não haver DTD em HTML5 deitamos fora os identificadores PUBLIC e SYSTEM e deixamos o mínimo de código que é fácil de lembrar e despoleta o modo standard. Assim em HTML 5 o DOCTYPE é simplesmente <!DOCTYPE html>.

Isto não se aplica ao XHTML5, para o qual não há necessidade de farejar o DOCTYPE e assim não é necessário de todo o DOCTYPE.

Novas Estruturas

Actualmernte é comum usar elementos div como principais estruturas numa página, como cabeçalhos, rodapés, colunas, dando a cada uma uma id descritiva ou uma classe descritiva. Mas o seu uso deve-se à falta actual em HTML da necessária semântica para descrever estas secções.

Em casos extremos, o abuso de elementos div não semânticos pode levar ao sindrome, que é comum entre os novatos, conhecido por divitis ou divmania. O HTML5 tenta curar esta doença introduzindo novos elementos que fornecem a semântica necessária à representação de cada uma destas secções.

Há elementos novos para cabeçalho (header) e rodapé (footer) para marcarem um cabeçalhop e um rodape de uma página ou secção.

O novo elemento nav foi introduzido para criar ligações de navegação, seja navegação no sítio seja navegação na página.

O elemento (ao correr da pena) aside existe para conteúdo que tangencialmente se relaciona com o conteúdo à sua volta, usado por exemplo para marcar barras laterais.

O novo elemento (secção) section representa uma secção genérica de um documento ou aplicação, tal como um capítulo, por exemplo.

O elemento (artigo) article tal como secção, mas especificamente para marcar conteúdo como um artigo noticioso ou uma entrada num blogue.

Quando usado em conjunto com elemento de cabeçalho (hn) (onde n vai de 1 a 6), todos estes elementos dão um modeo de marcar secções aninhadas com níveis de cabeçalho, para além dos 6 níveis possíveis nas anteriores versões do HTML.

Nova Semântica

O HTML5 também introduz novos elemento para uma gama alargada de finalidades semânticas, desde simples metadados até novos widgets.

O novo elemento meter providencia um widget para representação de medidas escalares ou valores fracionários. Por exemplo, pode ser usado para mostrar a qualidade da classificação, a quota de utilização de disco ou a temperatura.

O elemento progress foi concebido para mostrar o grau de complitude de uma tarefa. Foi concebido para trabalhar com aplicações por guião que actualizem de modo dinâmico o seu progresso. Por exemplo, pode usá-la para mostrar o progresso do carregamento de uma aplicação AJAX, ou para ilustrar o progresso do utilizador no preenchimento de uma série de formulários.

O elementos canvas foi concebido para oferecer uma API 2D para desenho, especificamente para ser usada nos seus guiões. Pode ser usada para reproduzir qualquer coisas desde simples desenhos artísticos ou gráficos gerados a partir de tabelas de dados até animações ou mesmo aplicações interactivas como um jogo. Tem havido conversas sobre a introdução de uma API de desenho em 3D.

O novo elemento de (grelha de dados) datagrid representa uma representação de uma árvore, losta ou dados tabulares e oferece um widget que permite ao utilizador trabalhar os dados assim como uma API para DOM relativamente rica.

Há um novo elemento (tempo) time para marcação de datas e horas, m para realçar texto. O elemento revitalizado meu está de volta com umas melhorias, em conjunto com o elemento (comando) command, para oferecer barras de ferramentas e menus contextuais.

O muito implementado e anteriormente não documentado (embebido) embed foi introduzido, e o elemento figure permite adicionar legendas às imagens.

O elemento (detalhes) pode ser usado para representar informação adicional, disponível a pedido, e um novo elemento dialog foi feito para tornar possíveis mais interacções.

Novos Controlos

Ao longo dos anos foi tornando-se claro que os tipos de controlos disponíveis no HTML 4 eram muito limitados e forçaram alguns sítios a contornar essas limitações com graus de complexidade variável. As datas por exemplo são frequentemente pedidas usando 3 campos separados cada um deles para o dia, mes e ano. O Web Forms 2 introduziu um número de novos controlos para uma gama alargada de tipos de dados adicionais.

Há vários novos controlos para datas e horas. Este é o novo widget do Opera para o controlo de data e hora. Oferece um calendário para selecção da data e um relógio para inserção da hora. Há ainda controlos similares para a introdução só de data ou só de hora.

O novo controlo de (número) number permite a inserção de um número. A vantagem de um controlo como este é oferecer um controlo para incrementar ou diminuir o valor, assim como assegurar-se de que só é possível inserir números. Não permite a inserção de caracteres que não sejam números e assim sendo evita-se ter que se preocupar tanto com validação do lado do cliente.

Há um novo controlo disponível de (barra deslizante) slider. O ser valor também é numérico, mas foi concebido para os casos em que o valor exacto é relativamente pouco importante. Por exemplo pode ser usado para controlar coisas como volume de som ou luminosidade.

O novo controlo email foi concebido especificamente para endereços de email. A vantagem é que os navegadores podem oferecer o acesso ao livro de endereços do utilizador e também verificar se o endereço de email inserido é válido.

O novo controlod e URL também está disponível para URI. Neste exemplo o navegador listou alguns endereços correspondentes à história de navegação do utilizador.

Mas talvez a nova característica mais excitante é a capacidade de finalmente haver marcação para caixas combinadas! Estas permitem ao utilizador seleccionar algo a partir de uma lista ou inserir um novo valor. Tradicionalmente esta limitação era contornada usando-se listas de selecção separadas de caixas de texto ou simulando usando técnicas de JavaScript. Agora esta funcionalidade pode ser oferecida num único controlo.

Modelo de Repetição

Há momentos onde necessita de recolher um número arbitrário de valores para um conjunto de dados. Por exemplo, num formulário de bilhetes podemos pedir uma lista de nomes de todas as pessoas em nome das quais se está a adquirir os bilhetes, pode necessitar de adicionar contactos multiplos para um livro de endereços, ou, como no exemplo listas todos os membro do SG-1.

Nos sítios actuais normalmente exige que o utilizador submeta o formulário ao servidor usando o botão de adicionar incluído na página e o servidor responde com uma nova página actualizada com linhas adicionais. Com este novo modelo a adição ou remoção de linhas pode ser totalmente tratada do lado do cliente

A Web Forms 2.0 introduziu novas características de modelos e botões para replicação de controlos de formulário. O botão de adição pode ser usado para adicionar um novo conjunto de controlos de formulário. Neste exemplo, um quarto conjunto de campos e posição foram adicionados e preenchidos

.

Os valores podem ser facilmente removidos usando o botão de remoção. Quando o utilizador completar o formulário pode submetê-la usando o botão de submissão normal

.

O modo como isto funciona é criando marcar de modelo na página. Praticamente qualquer elemento pode ser usado no modelo, não se restringe ao uso de linhas de tabela, como no exemplo. O novo atributo (repetir) repeat indica que o elemento e respectivo conteúdo é um modelo e que pode ser replicado.

O atributo repeat-start indica quantas cópias do modelo devem ser geradas quando a página carrega, neste exemplo foram geradas 2 linhas.

Quando um modelo é replicado, é necessário ocorrerem algumas coisas. O atributo repeat recebe um índice único e o atributo repeat-template é usado para se referenciar a id do modelo a partir do qual foi criado

Note ainda os nomes dos atributos na linha modelo no final. O uso de parêntesis rectos é uma síntaxe especial que necessita de se referir às id dos modelos que sejam substituídos com o valor do índice de repetição. Deste modo pode ser usado para assegurar que cada controlo tenha um número único para ser enviado ao servidor.

Para remover blocos de repetição foi definido um novo botão remove. Quando activado, causa a remoção do seu bloco ancestral mais próximo.

Similarmente, para adicionar novos blocos de repetição existe um novo botão add. Quando activado gera um novo bloco de repetição a partir do modelo e insere-o na página.

Validação do Lado do Cliente

Na maior parte dos sítios é comum encontrarmos validação do lado do cliente concebida para auxiliar o utilizador no preenchimento de um formulário, implementada usando JavaScript. Uma das principais limitações de validação do lado do utilizador é a falta dos necessários meios nas actuais versões do HTML para descrfever um controlo de formulários com qualquer tipo de dados de validação e assim sendo, normalmente tal é alcançado completamente usando-se guiões.

O HTML5 introduziu alguns novos atributos em controlos de formulário que descrevem os valores esperados de modo a que o navevador auxilie na validação. O novo atributo required pode ser usado para indicar que o campo é de preenchimento obrigatório.

Expressões regulares, normalmente embebidas nos guiões de validação de formulários podem agora ser usados com o novo atributo pattern descrevendo exactamente qual o formato permitido. Por exemplo pode usar este padrão para restringir um campo de nome de utilizador a caracteres alfanuméricos.

Para controlos numéricos, tais como número de entre uma gama é também possível restringir os valores a valores permitidos usando os atributos de domínio min e max.

E, embora isto estivesse disponível em caixas de texto desde o princípio também as áreas de texto (textareas) vêm adicionado o atributo maxlength para não haver excesso de texto.

Os navegadores que suportem estas capacidades podem notificar o utilizador de qualquer erro e automaticamente evitar a submissão até que sejam corrigidos, ou podem ser usados em conjunto com guiões para melhorar a experiência do utilizador.

API de DOM

A acompanhar as novas capacidades de marcação que foram introduzidas o HTML5 inclui ainda novas características no DOM. O DOM é a representação interna que um navegador forma de uma página e os API que são oferecidos permitem aos guiões trabalhar com ele.

Há muitos API suportados de modo alargado em navegadorfes que anteriormente não tinham sido documentados, conhecidos como DOM level 0. Isto inclui os interfaces como Window, History, Location; e vários são suportados de modo alargado que não se encontram definidos nas especificações actuais do DOM.

Ao reconhecer o facto de que os API em causa são usados e suportados de modo alargado considera-se que é melhor documentar, standardizar e melhorá-los onde possível de modo a poderem ser implementados de modo interoperável.

Ao mesmo tempo, há várias novas capacidades em desenvolvimento. API para armazenamento do lado do cliente foi concebida para permitir aos guiões guardarem dados do lado do cliente. Deste modo são semelhantes aos cookies, mas com um API mais rico e com melhorias.

O novo interface Audio foi concebido para passar pequenos efeitos sonoros.

Há vários novos API de comunicações, incluindo eventos enviados pelo servidor, que permite a uma página receber notificações a partir do servidor quando ocorrem acontecimentos. Por exemplo poderá ser usado para acompanhar a cotação em bolsa de uma acção, sendo a mesma actualizada à medida que vai mudando.

A API de ligação de rede foi concebida para permitir aos guiões fazerem ligações TCP directas ao servidor. Isto é similar ao XMLHttpRequest, mas não está restringida só a pedidos HTTP.

E finalmente uma API para mensagens cruzadas entre documentos foi criada para que um documento possa comunicar com outro sem o aborrecimento das questões de segurança com cruzamento de domínios.

Perguntas

...

Se desejarem mais informação pode verificar o sítio do WHATWG, ler as especificações, o wiki ou a FAQ, ou ainda colocar questões na lista de correio ou nos fóruns destinados aos designer e pessoas que desenvolvem sítios.

Muito Obrigado.

Nota: O Futuro do HTML que traduzi em Novembro passado é leitura complementar.