IE8 e Standards

Água mole em pedra dura tanto dá até que fura. Até a Microsoft de vez em quando muda, neste caso diz que sob os princípios de interoperabilidade que em Fevereiro tinha feito vir a público e desta vez parece ter decidido no sentido correcto isto é por omissão o Internet Explorer 8 irá reproduzir em modo standard e se alguém desejar que ele reproduza algo em modo quirks que trate de o pedir explicitamente.

Metachatice II

A minha opinião sobre a utilização de uma etiqueta meta para que as versões futuras do Internet Explorer se comportem em conformidade com as normas (mesmo que não no sentido jurídico do termo) não é de facto tão "pragmática" como isso. A quantidade de crítica (alguma acéfala, alguma fundamentalista, mas a generalidade bem fundamentada) que tem vindo a ser emitida é enorme. No artigo do Jeffrey Zeldman sobre o assunto há 235 comentários (quando estou a escrever isto). Nem todos os comentários são (só) sobre a inclusão ou não dessa etiqueta meta, mas também se dedicam a perguntar o que sucederia numa gama de potenciais cenários. Omissão da meta e de doctype válido ficando algumas delas confusas quanto ao modo de resposta que o navegador da Microsoft irá tomar.

Quando se estabelece uma norma (algo normalmente conservador) não se espera grandes inovações, mas espera-se não ter surpresas. É por isso que me parece que uma proposta de norma (como a OOXML) não deve incluir entre as suas regras algo que diga como se efectua ou efectuou na versão xpto fechada. Ou seja quando para uma coisa funcionar como deve funcionar ter que se ter um mecanismo especial (neste caso a meta) para a fazer funcionar correctamente então algo vai mal. Já tinham inventado o mecanismo do falso comentário (comentário condicional) para que a versão IE7 quase funcionasse correctamente e convenceram muita gente a aplicar o mesmo agora esperam não ficar entalados "obrigando" a seguir um caminho que não está de todo na norma.

O que me espanta um pouco desta vez é que uma série de pessoas, o próprio Jeffrey, o Eric, a Molly (sendo que esta tem a desculpa total de ser colaboradora da própria Microsoft) que estavam por detrás do movimento dos standards, que a Molly vem agora dizer que são de facto práticas recomendadas (no que tem razão claro) no final dos anos 90 do século passado se tenham aproximado tanto das posições da Microsoft como por exemplo Peter Quincy que diz, grosso modo, que há quem conceba um site em conformidade com os navegadores alvo, quem conceba um site em conformidade com as normas, mas que sem preocupações de reprodução exacta se degradam de modo suficientemente agradável e acessível em navegadores que não se comportem de forma adequada e finalmente quem tenha preocupações estéticas e ao mesmo tempo preocupações com a produção de sítios com uma reprodução quase uniforme numa gama alargada de navegadores e que por causa disso mesmo validando os seus sítios, incluem aqui e ali alguns elementos adicionais de modo a que os mesmos sejam bem reproduzidos.

Bom claro que quando falamos de standards os de HTML foi cedido pela ISO o poder ao W3C de os criar. Como se sabe o ISO do HTML corresponde sensivelmente ao HTML 2.0. (Um pouco conservador de mais.)

Mais Sobre o Futuro do HTML

Em março de 2007 escrevi umas breves notas sobre o futuro do html. Passados alguns meses a comunidade do HTML prosseguiu o seu trabalho de preparação do futuro e o Lachlan Hunt acaba de publicar no A List Apart 250 a sua visão de como irá evoluir o HTML 5 (quer na sua versão HTML quer na sua versão XML). Uns dias antes Doglas Crockford clamava simplesmente pela simplificação da linguagem.

Na altura havia dois projectos de HTML5 concorrentes o do W3C (especificação no estado actual) e o do WHATWG. Estes projectos foram unificados e neste momento a especificação é única, continuando em processo de evolução.

div e span - II

Há uns poucos dias alguém comentava no meu artigo div vs span que gostava de conhecer um pouco melhor os elementos div e span. Eis uma primeira vista de olhos a esses dois elementos, claro está que para um melhor esclarecimento devemos recorrer às fontes do w3c.

div

Definição

As div são uma maneira genérica de agrupar áreas de conteúdo

Exemplo

O elemento div pode ser usado para criar o arranjo da página Web. O exemplo serve de apresentação à natureza de agrupamento do elemento div:

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt">
 <head>
 <title>Casa da Mata</title>
 <style type="text/css">
 navigacao {width: 200px; float: left;}
 conteudo {margin-left: 205px;}
 rodape {clear: both;}
 </style>
 </head>
 <body>
 <div id="cabecalho">
 ... [aqui deve ficar o anúncio e ou o logótipo] ...
 </div>
 <div id="navigacao">
 ... [aqui deve ficar o menu principal] ...
 </div>
 <div id="conteudo">
 ... [o conteúdo principal da página fica aqui] ...
 </div>
 <div id="rodape">
 ... [informação legal fica aqui] ...
 </div>
 </body>
 </html>

Boas práticas

O elemento div não contém significado semântico. É uma maneira genérica de agrupar áreas de conteúdo. Assim mesmo sendo permitido, pela especificação do XHTML, conter texto e elementos em linha considera-se melhor prática envolver texto e elementos em linha em elementos bloco com significado tais como p, ol, ul, dl, de h1 a h6, blockquote, etc. O exemplo seguinte mostra um enlace e texto e imagens dentro de um elemento div:

 <div class="bala semanal">
   <a href=   "/multimedia/interior/conteudo=408746">
       <img src="/armazem/ng1017428.jpg" class="chamada" alt="A semana em fotos">
       <br />
       <img src="/Comum/Imagens/2007/icone_fotog.gif" alt="" class="Icone">
       <p class="destaque medio">Fotogaleria</p>
       <br />
    ...
 </a>
  </div>

Note-se o uso de um atributo class na div com dois nomes.

span

Definição

O elemento span propicia uma maneira genérica de adicionar estrutura ao conteúdo. Trata-se de um elemento em linha

Exemplo

O elemento span pode ser usado com o uma maneira de aplicar formatação CSS ao conteúdo. No exemplo seguinte o elemento span no cabeçalho irá ter um fundo a ciano e o elemento span no parágrafo irá ter um fundo cinza.

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt">
 <head>
 <title>A Casa da Mata</title>
 <style type="text/css">
h1 span {background-color: cyan}
 p span {background-color: gray}
 </style>
 </head>
 <body>
 <h1>A <span>Casa da Mata</span> - É um descanso do guerreiro</h1>
 <p>A <span>Casa da Mata</span> foi construída como estalagem há 22 anos.</p>
 </body>
 </html>
 

Atributos

Atributos comuns

class

Este atributo atribui um nome ou um conjunto de nomes de classe a um elemento. Pode atribuir-se o mesmo nome de classe ou conjunto de nomes de classe a vários elementos. Quando se atribuir um conjunto de nomes os nomes devem ser separados por caracteres de espaço em branco. Normalmente usam-se nomes de classe para aplicação de regras de formatação CSS a um elemento.

id

Este atributo atribui uma ID a um elemento. Esta ID deve ser única no documento. Esta ID pode ser usada em guiões aplicados do lado do cliente (tais como os escritos em JavaScript) para seleccionar elementos ou para aplicar regras de formatação CSS ou para criar relações entre elementos.

text

Este atributo propicía informação auxiliar. Alguns navegadores irão apresentar esta informação em janelas de ponto. As tecnologias de assistência podem disponibilizar esta informação aos utilizadores como informação adicional sobre o elemento.

Atributos de internacionalização

xml:lang

Este atributo específica o idioma base dos valores do atributos de um elemento e do seu conteúdo textual.

dir

Este atributo específica a direcção base do texto. Este atributo pode tomar os seguintes valores:

• ltr: da Esquerda para a direita
• rtl: da Direita para a esquerda

Pode conter

• Elementos em linha
• Texto

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.

Address, o elemento esquecido?

Há uma lista de elementos HTML que estão mal representados na generalidade da marcação usada actualmente na web. Vários destes elementos têm maior valor semântico que o que actualmente é aplicado, mas com o aumento da popularidade do design orientado pelo CSS com os elementos HTML a serem usados para o que foram concebidos julgo que seria bom expôr estes elementos indicando em que situações seriam úteis. Um desses elementos é o elemento address:

<address>

O marcador <address> foi concebido para conter informação sobre endereços, assinatura e autoria. Números de telefone, fax, endereços físicos, endereços de correio electrónico, ICQ/Gtalk... ou qualquer outros dados de contacto em linha e fora dela são todos válidos. Normalmente os elementos <address> encontram-se no topo ou na parte de baixo do documento.

Utilização:

<address>
O Nome da entidade <br />
Rua do Mistério, 126 <br />
1025 Lisboa <br />
Telefone: 21 000 0000 <br />
Fax: 21 00 0001
</address>

Para quê? Posso fazer o mesmo com um marcador <div>

Os elementos agrupados com um <div> não têm valor semântico excepto se lhes for atribuída uma identificação ou classe. Então porquê criar uma <div class="contacto"> quando já há um elemento que o pode fazer?

Exemplo:

address {
  background-color: #dfd;
  padding: 4em 0 4em 4em;
  font-style: normal;
}

...

<address>
<a href="http://aindaapensar.blogspot.com">Carlos</a>
<br />

NaoSeTrataDeNenhumaInstituição
<br />

Rua da Estória, 23424
<br />

1025 Lisboa

O resultado:

Carlos
NaoSeTrataDeNenhumaInstituição
Rua da Estória, 23424
1025 Lisboa

Diferenças HTML vs. XHTML

Por favor note que a informação aqui presente se baseia na actual especificação para (X)HTML5. alguns dos detalhes não são aplicáveis tecnicamente a anteriores versões de HTML.

Embora o HTML e o XHTML possam parecer serem similares na sua sintaxe, são bastante diferentes de várias formas.

Nota: Como o actual documento WHATWG ainda é um rascunho esta secção necessita de ser acompanhada como um alvo em movimento.

As diferenças marcadas com @@@ são diferenças que podem teoricamente ser alteradas sem afectar a retrocompatibilidade

Tipos MIME

• O XHTML tem que ser servido como um tipo MIME XML tal como application/xml ou application/xhtml+xml.
• O HTML tem que ser servido como text/html.

É este tipo MIME que determina que tipo de documento está a usar. Se tentar enviar XHTML como text/html de facto está a usar HTML, eventualmente com erros sintáticos.

Tecnicamente, de acordo com a especificação é permitido enviar XHTML 1.0 como text/html. Mas devido à razão anteriormente apresentada tal documento é considerado como documento em HTML e não em XHTML.

Análise

O XHTML usa requisitos de análise/interpretação XML. O HTML usa os seus próprios requisitos que estão definidos de uma forma que se apresenta muito mais próxima da forma de tratamento que os navegadores dão ao HTML actualmente.

• Em XHTML, a má formação é um erro fatal. Em HTML, as regras de tratamento de erros são muito mais simpáticas. Os erros de má formação, que também são erros sintáticos em HTML, incluem os seguintes:
  • E comercial não codificado (& em vez de &amp;), e sinais de menor que (< em vez de &lt;) (Isto não se aplica a CDATA).
  • Comentários contendo um par extra de hifens ou terminando num hífen, isto é:
    • <!-- erro –– sintáctico --> ou
    • <!-- erro sintáctico --->.
  • Fechos de marcadores a que não correspondem a respectiva abertura de marcadores (não se aplica a elementos com marcadores opcionais)
  • Ausência de marcadores de fecho.
  • Ocorrência de caracteres inesperados em ou antes de nomes de atributos.
  • Ocorrência inesperada de EOF (Fim de ficheiro).
  • Caracteres inesperados antes do nome DOCTYPE.
  • Ausência de nome DOCTYPE.
  • Um identificador PUBLIC num DOCTYPE sem identificador de SYSTEM (Nota: incluir qualquer um destes é um erro sintáctico em HTML5, mas em XML só o identificador SYSTEM pode ocorrer por si.)
  • Fecho de marcadores com atributos.
  • Fechos de marcadores inesperados (em HTML, um </br> ou </p> pode fazer implicar (mesmo que não seja claro explicito) uma abertura de marcador antes do respectivo fecho).
• O subconjunto interno é permitido em XML, mas não tem significado (e é proibido) em HTML.
  • Em alguns casos um subconjunto interno em HTML terminará por ser parcialmente reproduzido em linha.
• A sequência de caracteres "]]>" quando não assinala o final da secção CDATA é um erro de má formação em XHTML, mas é válido em HTML.
• Em XHTML: <![CDATA[...]]> é uma secção CDATA section. Em HTML, é um falso comentário.
• Em XHTML, é uma instrução de processamento. Em HTML é um falso comentário.
• Em HTML, o traço de fracção usado na sintaxe de um elemento vazio é um erro de análise para elementos não vazios (ver abaixo), mas ignorado em todos os casos.
• Em HTML, os elementos script e style são analisados como CDATA. (Nota: a definição de CDATA é diferente da encontrada em XML). Em XML, são interpretados como elementos normais (o que significa que os comentários são tratados como comentários reais e coisas que se parecem com abertura de marcadores são de facto aberturas de marcadores).
• Em HTML, os elementos title e textarea são interpretados como RCDATA. (Nota: A definição de RCDATA é diferente da dada no SGML e não há RCDATA em XML).
• Em HTML, se estiver activado o scripting o elemento noscript é interpretado como CDATA. Se o scripting estiver desactivado (ou indisponível) é interpretado como PCDATA. Em XHTML, o elemento não tem efeito e não pode ser de facto usado para evitar que conteúdo seja mostrado quando o script não estiver disponível.
• Em HTML, os elementos iframe, noembed e noframes são interpretados como CDATA. Em XHTML, são interpretados como elementos normais e sendo assim não impedem o uso de conteúdo.
• Os caracteres de espaço em branco em valores de atributos são normalizados para espaços em XHTML.
• Sob determinadas condições tornam-se implícitos elementos com marcadores opcionais.
• Em HTML, elementos base, link, meta, style e title com marcadores que ocorram em body são movidos e inseridos em head. Em XHTML, ficam onde tenham sido especificados.
• Em HTML, marcadores de certos elementos que aparecem fora de contexto são ignorados. Estes marcadores incluem caption, col, colgroup, frame, frameset, head, option, optgroup, tbody, td, tfoot, th, thead, tr.
• O elemento plaintext tem um requisito especial de interpretação em HTML. (é contudo proibido).
• Há ainda outros casos de interpretação especial de casos de fronteira e condições de erro que não foram aqui listados e que ocorrem em HTML.

Análise

O XHTML usa requisitos de análise/interpretação XML. O HTML usa os seus próprios requisitos que estão definidos de uma forma que se apresenta muito mais próxima da forma de tratamento que os navegadores dão ao HTML actualmente.

• Em XHTML, a má formação é um erro fatal. Em HTML, as regras de tratamento de erros são muito mais simpáticas. Os erros de má formação, que também são erros sintáticos em HTML, incluem os seguintes:
  • E comercial não codificado (& em vez de &amp;), e sinais de menor que (< em vez de &lt;) (Isto não se aplica a CDATA).
  • Comentários contendo um par extra de hifens ou terminando num hífen, isto é:
    • ou
    • .
  • Fechos de marcadores a que não correspondem a respectiva abertura de marcadores (não se aplica a elementos com marcadores opcionais)
  • Ausência de marcadores de fecho.
  • Ocorrência de caracteres inesperados em ou antes de nomes de atributos.
  • Ocorrência inesperada de EOF (Fim de ficheiro).
  • Caracteres inesperados antes do nome DOCTYPE.
  • Ausência de nome DOCTYPE.
  • Um identificador PUBLIC num DOCTYPE sem identificador de SYSTEM (Nota: incluir qualquer um destes é um erro sintáctico em HTML5, mas em XML só o identificador SYSTEM pode ocorrer por si.)
  • Fecho de marcadores com atributos.
  • Fechos de marcadores inesperados (em HTML, um </br> ou </p> pode fazer implicar (mesmo que não seja claro explicito) uma abertura de marcador antes do respectivo fecho).
• O subconjunto interno é permitido em XML, mas não tem significado (e é proibido) em HTML.
  • Em alguns casos um subconjunto interno em HTML terminará por ser parcialmente reproduzido em linha.
• A sequência de caracteres "]]>" quando não assinala o final da secção CDATA é um erro de má formação em XHTML, mas é válido em HTML.
• Em XHTML: <![CDATA[...]]> é uma secção CDATA section. Em HTML, é um falso comentário.
• Em XHTML, é uma instrução de processamento. Em HTML é um falso comentário.
• Em HTML, o traço de fracção usado na sintaxe de um elemento vazio é um erro de análise para elementos não vazios (ver abaixo), mas ignorado em todos os casos.
• Em HTML, os elementos script e style são analisados como CDATA. (Nota: a definição de CDATA é diferente da encontrada em XML). Em XML, são interpretados como elementos normais (o que significa que os comentários são tratados como comentários reais e coisas que se parecem com abertura de marcadores são de facto aberturas de marcadores).
• Em HTML, os elementos title e textarea são interpretados como RCDATA. (Nota: A definição de RCDATA é diferente da dada no SGML e não há RCDATA em XML).
• Em HTML, se estiver activado o scripting o elemento noscript é interpretado como CDATA. Se o scripting estiver desactivado (ou indisponível) é interpretado como PCDATA. Em XHTML, o elemento não tem efeito e não pode ser de facto usado para evitar que conteúdo seja mostrado quando o script não estiver disponível.
• Em HTML, os elementos iframe, noembed e noframes são interpretados como CDATA. Em XHTML, são interpretados como elementos normais e sendo assim não impedem o uso de conteúdo.
• Os caracteres de espaço em branco em valores de atributos são normalizados para espaços em XHTML.
• Sob determinadas condições tornam-se implícitos elementos com marcadores opcionais.
• Em HTML, elementos base, link, meta, style e title com marcadores que ocorram em body são movidos e inseridos em head. Em XHTML, ficam onde tenham sido especificados.
• Em HTML, marcadores de certos elementos que aparecem fora de contexto são ignorados. Estes marcadores incluem caption, col, colgroup, frame, frameset, head, option, optgroup, tbody, td, tfoot, th, thead, tr.
• O elemento plaintext tem um requisito especial de interpretação em HTML. (é contudo proibido).
• Há ainda outros casos de interpretação especial de casos de fronteira e condições de erro que não foram aqui listados e que ocorrem em HTML.

Sintaxe

• Em HTML, o doctype é obrigatório em XHTML é opcional.
• Em XHTML, os nomes dos marcadores e dos atributos são sensíveis ao corpo da letra (maísculas e minúsculas têm significados diferentes) em HTML tal não sucede.
• Em XHTML, elementos não vazios exigem tanto a abertura do marcador como o fecho do marcador. Em HTML pode omitir-se um deles ou até ambos:
  • html (ambos)
  • head (ambos)
  • body (ambos)
  • li (fecho do marcador)
  • dt (fecho do marcador)
  • dd (fecho do marcador)
  • p (fecho do marcador)
  • colgroup (ambos)
  • thead (fecho do marcador)
  • tbody (ambos)
  • tfoot (fecho do marcador)
  • tr (fecho do marcador)
  • td (fecho do marcador)
  • th (fecho do marcador)
• Em XHTML, os elementos vazios podem usar quer a sintaxe de elemento vazio (<br/>) ou fazer o fecho imediatamente a seguir à abertura do marcado (<br></br>). Em HTML, a sintaxe de elemento vazio (<br/>) é permitida em elementos vazios mas proibida noutros elementos. Contudo não serve para nada e pode ser omitida. Não é permitido o fecho de um marcador para elementos vazios.
  • base, link, meta, hr, br, img, embed, param, area, col e input
  • Nota: os seguintes são tratados como elementos vazios para finalidades de requisitos de interpretação, mas, como são obsoletos e não-standard a sintaxe do traço de fracção final não é permitida: basefont, bgsound, spacer, wbr. (embora visto estes elementos não serem permitidos tal não faça nenhuma diferença).
• O HTML autoriza a minimização de atributos (isto é, a omissão do valor) mas o XHTML não.
• O HTML autoriza a utilização de valores de atributos sem estarem entre pelicas o XHTML não.
• O XHTML autoriza o uso de secções CDATA o HTML não.
• O XHTML autoriza o uso de instruções de processamento o HTML não.
• Em HTML, todas as referências a entidades estão pré-definidas e não requerem um DTD. Mas como não há DTD para XHTML5, as referências de identidades não pode ser usadas em XHTML. (excluindo as 5 pré-definidas: &amp;, &lt;, &gt;, &quot; e &apos;)
  • Pode fornecer o seu próprio DTD para uso com o seu próprio interpretador de validação, mas tenha em mente que os navegadores não usam interpretadores de validação e que não irão ler o DTD.
• O conjunto de caracteres unicode válido em XML 1.0 é mais limitado do que em HTML.
• Prefixos de espaço de nomeação são permitidos em XHTML. São proibidos em HTML.

Marcação

• A declaração de espaço de nomeação (atributo xmlns) é obrigatório em XHTML. O atributo xmlns também é autorizado a figurar no elemento html em HTML sob a condição de o seu valor ser "http://www.w3.org/1999/xhtml".
  • <html xmlns="http://www.w3.org/1999/xhtml">
  • Em HTML, o atributo xmlns não tem absolutamente nenhum efeito, É basicamente um talismã. Só é autorizado para fazer a migração de e para XHTML ligeiramente mais fácil. Quando interpretado por um interpretador HTML o atributo acaba no espaço de nomeação null.
  • Em XML (com um interpretador que saiba interpretar espaços de nomeação XML), um atributo xmlns faz parte do mecanismo de declaração de espaços de nomeação e um elemento não pode ter de facto um atributo xmlns em espaço de nomeação null. Em implementações DOM o atributo termina no espaço de nomeação "http://www.w3.org/2000/xmlns/".
• O XHTML autoriza o uso de elementos e atributos que não sejam elementos e atributos XHTML (em espaços de nomeação diferentes), o HTML não.
• O XHTML usa o atributo xml:lang, o HTML usa o atributo lang em seu lugar,
• O XML ID introduz xml:id,que pode ser usado em XHTML. Em HTML não tem qualquer efeito.
• Em HTML, pode-se usar o elemento noscript. Em XHTML, é proibido.
• O HTML usa o elemento base, o XHTML usa em seu lugar o elemento xml:base.
• Em XHTML, os elementos p podem conter elementos estruturais de nível em linha incluindo blockquote, dl, menu, ol, ul, pre e table. Na serialização de HTML devido a constrangimentos de retrocompatibilidade isto não é possível (embora possa ser feito por manipulação do DOM).
• Em XHTML, os elementos table podem conter elementos tr. Em serialização de HTML, devido a constrangimentos de retrocompatibilidade tal não é possível (embora possa ser feito através de manipulação do DOM).

Codificação de Caracteres

• Em XHTML, a declaração XML pode ser usada para especificar a codificação de caracteres. Em HTML a declaração xml é proibida
• Em HTML, pode ser usado o elemento meta em seu lugar. O atributo http-equiv no elemento meta é proibido em XHTML e ignorado se incluído.
• A codificação de caracteres por omissão para XHTML é de acordo com as regras de XML: UTF-8 ou UTF-16. Se a codificação não for especificada em HTML, deve ser determinada de acordo com uma heurística especifica da implementação ou ter um valor por omissão (Nota: esta secção da especificação ainda não está terminada).

Scripts/Guiões

• não se pode usar document.write() e document.writeln() em XHTML, mas pode-se em HTML.
• em XHTML, o uso da propriedade innerHTML obriga a que a string seja um fragmento de XML bem formado.
• As API do DOM são sensíveis à caixa (maísculas vs. minúsculas) em XHTML e em alguns casos não são sensíveis em HTML. (Isto não se aplica a elementos que não se encontrem no espaço de nomeação HTML)
  • Element.tagName, Node.nodeName, e Node.localName retornam o valor em maísculas.
  • Document.createElement() não é sensível à caixa (a forma canónica é minúsculas).
  • Element.setAttributeNode() muda o nome do atributo para minúsculas.
  • Element.setAttribute() não é sensível à caixa (a forma canónica é minúsculas).
  • Document.getElementsByTagName() e Element.getElementsByTagName() são não sensíveis à caixa.
  • Document.renameNode(). Se o novo espaço de nomeação é o espaço HTML, então o novo nome qualificado deve ser em minúsculas antes de a renomeação ter lugar.
• Em HTML, Document.createElement() criará um elemento no espaço de nomeação HTML. Em XML (incluindo XHTML), o espaço de nomeação está definido tanto pelo DOM2 como pelo DOM3 como sendo null.
  • Em XHTML, os navegadores não têm interoperabilidade nesta área. Em Firefox, o espaço de nomeação depende do tipo MIME. Em Opera depende do elemento raiz e em Safari é sempre null.

Folhas de estilo

• Os selectores, como usados em CSS criam correspondência sensível à caixa no XHTML mas são insensíveis à caixa em HTML.
• O CSS requer tratamento especial do elemento body em HTML para pintura de fundos no canvas, o que não se aplica ao XHTML.

Diferenças entre HTML 4.01 e HTML 5

Tipo MIME

Tanto o HTML 4.01 como o HTML 5 usam text/html.

Content-Type: text/html; charset=UTF-8

Interpretação de HTML

• Desde o HTML 2.0 até ao HTML 4.01 são formalmente baseados em SGML, mas os navegadores não implementaram interpretadores SGML. Notas de implementação 4.2 SGML e B.3 SGML, HTML 4.01. Esta é uma secção não normativa da especificação HTML 4.01. Ela faz já a diferença entre agentes utilizadores HTML e agentes utilizadores SGML.
• HTML 5 define os seus próprios requisitos de interpretação baseados na forma como os navegadores interpretam o HTML de facto.

Sintaxe

* A FAZER

Marcação

• Lista de elementos HTML 4.01
• Lista de atributos HTML 4.01
• Ainda não há lista de elementos e atributos para Web Apps 1.0

Atributos Obsoletos

Alguns atributos definidos em HTML4 não foram incluídos em HTML5. Eis a lista actual (sujeita a alterações, ver especificação):

• html@version
• head@profile
• a@rev, link@rev
• a@target, area@target, base@target, form@target (é mencionado em WF2...), link@target
• a@charset, link@charset, script@charset
• table@summary
• td@headers, th@headers
• td@axis, th@axis
• param@valuetype
• object@standby
• meta@scheme
• object@archive

Além disso o HTML5 não tem nenhum dos atributos de apresentação que figuram em HTML4 (incluindo aqueles que figuram em <table>). Quaisquer atributos definidos em elementos que não figurem em HTML4 obviamente também não figuram em HTML5.

Elementos Obsoletos

Os seguinte elementos estão presentes em HTML4 mas não se encontram definidos em HTML5:

• acronym (usar <abbr> em seu lugar)
• applet (usar <object> em seu lugar)
• basefont
• big
• center
• dir
• font
• frame
• frameset
• isindex
• noframes
• noscript (só em XHTML)
• s
• strike
• tt
• u

Codificação de Caracteres

Algoritmo HTML 4

Fonte 5.2.2 Especificação de codificação de caracteres na especificação HTML 4.01.

1. Um parâmetro de HTTP "charset" num campo "Content-Type".
2. Uma declaração META com um atributo "http-equiv" apontando para o "Content-Type" e com um valor para "charset".
3. Um atributo charset num elemento que designa um recurso externo.

Algoritmo HTML 5

Isto ainda está indefinido na especificação. Ver Detecção de Codificação de Caracteres para documentação.

Diferenças entre DOM Level 2.0, 3.0 e HTML 5 DOM APIs

Esta secção poderá pertencer a uma página diferente.

• A FAZER (é necessário falar sobre as mudanças do DOM API que o HTML5 está a fazer em comparação com DOM2 e DOM3)

HTML ou xhtml?

Embora pessoas como eu tenham aprendido HTML (há 10 aninhos) e esteja a aprender (na minha opinião) a usar convenientemente o xhtml, julgo, que para quem se esteja a iniciar agora no desenvolvimento de web pode aprender uma ou outra desde que a aprenda bem.

O xhtml é mais exigente para quem o cria e para quem o gere no dia-a-dia. Exige mais cuidado e quase que diria que só deve ser usado se podermos controlar (de algum modo mesmo que indirecto) a forma como o mesmo é servido a visitantes das nossas páginas.

Caso contrário podemos abrir uma caixa da pandora de problemas.

A curva de aprendizagem do HTML poderá não ser tão grande (mas algo que devemos incutir em quem aprende que aprender bem exige esforço e dedicação), mas devemos quase implorar para que quem esteja a aprender não nos peça que indiquemos exemplos de páginas bem escritas quer em HTML quer em XHTML, salvo honrosas excepções já aqui anteriormente indicadas.

Estou a fazer um estudo sobre o tipo de erros encontrados em sítios portugueses. São muito poucos, aqueles que encontrei escritos de forma não só a validarem com os programas automáticos de validação mais habituais, mas que além disso, na marcação tirem partido da mesma para transmitirem a verdadeira estrutura do respectivo conteúdo.

Voltando à questão inicial usar/aprender/ensinar HTML ou XHTML mas com o cuidado de o fazer bem é o que é importante, tanto quanto julgo.