Web,ruby, Ajax ou qualquer outra coisa que me venha a cabeça (com prioridade para esta última)

23 novembro, 2006

Acaba de sair a RC1 da Rails 1.2

Acaba de sair RC1 da Rails 1.2. Para quem queira experimentar as novas características após instalar esta candidata a versão (não se esqueça que pode fazer rake freeze, ou para os mais aventureiros mesmo gem install rails... não se esqueça de verificar como é que os seus testes correm. Verifique se não aparecem nos registos de execução (grande expressão para log) mensagens de aviso sobre utilização de capacidades que estejam marcadas como não recomendáveis porque a caminho da obsolescência.

Uma das novas capacidades é a de gerir quase decentemente cadeias de caracteres Unicode (não é contudo totalmente transparente mas vai nesse caminho com o ActiveSupport::Multibyte. Deixa de ser necessário estabelecer o valor de KCODE mas pode ver como funciona isto viajando até ActiveSupport::Multibyte e vendo o screencast.

22 novembro, 2006

The Rails Way - crítica de Tracks

Não extrair código cedo. Pior do que usar código repetidas vezes é extrair código demasiado cedo. Isto é dito no sítio the Rails Way na crítica ao código da aplicação Tracks O artigo que estou a citar tem uma explicação detalhada no sítio artistic coding.

É de recomendar a leitura dos dois artigos para quem já saiba o que está a fazer isto é que tenha um conhecimento razoável da Ruby e alguma experiência com a Rails.

Na segunda parte é notado que a não utilização de filtros nos controladores de facto vai contra o padrão da sua utilização exactamente na situação onde numa série de controladores há que fazer uma iniciação em todas ou quase todos os controladores. Neste caso deve/pode aplicar-se este padrão.

Nas duas partes restantes sobre Tracks trata de aspectos relativos a herança e na última delas acesso a bases de dados e índices.

21 novembro, 2006

Estava a necessitar de uma chamada à realidade

Quem lê este blogue sabe que sou membro do ILG. Hoje tive algum tempo e verifiquei como é que estava este sítio relativamente à conformidade com os web standard.

Por.. tinha 312 erros. Pensei, isto está uma verdadeira bodega. Após 2 horas de trabalho lá consegui reduzir os erros a 2 mas estes não estou a conseguir retirar pois são de geração automática pelo blogger e não sei a partir de que componente são gerados.

Os erros mais comuns que vi foram parágrafos não terminados. Ainda não dei por concluído o trabalho, mas de facto não sei como eliminar estes dois problemas. Um atributo que não existe em xhtml. Por outro lado talvez isto me leve a criar um modelo meu com css meu para o meu blogue, talvez seja desta.

17 novembro, 2006

Pistas breves para internacionalização para a Web

Isto é uma tradução do artigo de R. Ishida do W3C ainda está em processo de tradução não deve ter efeitos de reprodução

As 'pistas breves' que se seguem resumem os conceitos fundamentais sobre concepção internacionalizada para a Web. Estas pistas não são directrizes completas, são só um conjunto de conceitos descritos no sub-sítio da Actividade de Internacionalização do W3C, onde poderá ler mais.

Esta página será actualizada ao longo do tempo.

Codificação. Usar Unicode sempre que possível para conteúdo, bases de dados etc. Declarar sempre a codificação do conteúdo.

A codificação dos caracteres que escolhe determina qual a correspondência entre octetos e caracteres no seu texto.

Normalmente as codificações de caracteres limitam-no a um conjunto particular de escritos ou um conjunto de línguas. Unicode permite-lhe tratarde forma simples com quase todos os escritos e línguas em uso à volta do mundo. Desta forma o Unicode simplifica o tratamento de conteúdo em várias línguas, seja numa única página seja num ou mais sítios. Unicode é particularmente útil quando usada em formulários, scripts e bases de dados, onde frequentemente necessita suportar várias línguas. Unicode torna muito directo adicionar novas línguas ao seu conteúdo.

Caso não declare apropriadamente que codificação de caracteres está a usar os seus leitores podem ser incapazes de lêr o seu conteúdo. Isto porque as aplicações que interpretam o seu texto podem efectuar pressuposições incorrectas sobre qual a correspondência entre octetos e caracteres.

Informação Adicional

Ver o guia "Conjuntos de Caracteres & codificações em XHTML, HTML e CSS ". Este guia explica como declarar codificação de caracteres no conteúdo (X)HTML e CSS. Note que isto nem sempre será tão directo como pode parecer.

Novo em Internacionalização?

Ler o artigo "Introdução a Conjuntos de caracteres e Codificações". Este artigo dá uma panorâmica sobre este tópico, e aponta para outros artigos W3C para aqueles que queiram explorar mais neste tema.

Experimente?

Verificar o índice cruzado para mais informação.

Escapes. Só usar escapes (isto é,     ou  ) em circuntâncias específicas.

Escapes tais como as Referências Numéricas de Caracteres (RNC ou NCR em inglês), e entidades são formas de representar um caracter Unicode em marcação usando só caracteres ASCII. Por exemplo, pode representar o caracter á em X/HTML como á ou á ou á.

Tais escapes são úteis para representar caracteres ambiguos ou invisíveis e evitar problemas com caracteres sintácticos tais como e-comercial e os sinais de maior e menor. Podem ser também úteis para representar caracteres não suportados pela sua codificação de caracteres ou não estarem disponíveis no seu teclado. Caso contrário deve sempre usar caracteres em vez de escapes.

Mais informação

Ler "Usar NCR e entidades de caracteres" para informação adicional sobre o uso de escapes em linguagens de marcação. Em particular, notar que as entidades (tais como á) devem ser usadas com cautela.

Novo em internacionalização?

Ler o artigo "Introdução aos Conjuntos de Caracteres e Codificações". Este artigo dá uma panorâmica sobre o tópico e aponta para outros artigos W3C para aqueles que queiram explorar mais o assunto.

Experiente?

Verificar o índice cruzado para informação adicional.

Língua. Declarar a língua de processamento de texto e indicar qualquer mudança interna de língua.

Informação sobre a língua em que se encontra o conteúdo é já importante para acessibilidade, busca, estilo, edição e outras razões. À medida que cada vez mais conteúdo é etiquetado e etiquetado correctamente, as capacidade das aplicações poderem detectar a informação sobre a língua vai tornar-se cada vez mais útil e espalhada.

Mais Informação
Ler o guia "Declarar Língua em XHTML e HTML" para informação sobre como declarar a língua de um documento como um tiodo, ou fragmentos de texto em diferentes línguas. É também essencial compreender a diferença entre os conceitos de língua de processamento de texto vs. língua principal de metadados.
Utilizador experiente ?
Ver índice cruzado para informação adicional.
Apresentação vs Conteúdo. Usar folhas de estilo para informação sobre apresentação. Restrinja marcação para semântica.

É um importante princípio do design de Web manter o modo como o conteúdo é estilizado ou apresentado separado do próprio texto (conteúdo). Isto simplifica a aplicação de estilo alternativo, para o mesmo texto, mais simples, por exemplo de modo a mostrar o mesmo conteúdo num navegador convencional ou num dispositivo de mão.

Este princípio é particularmente útil para a localização de conteúdo, visto diferentes scripts têm necessidades tipográficas diferentes. Por exemplo devido à complexidade dos caracteres japoneses, pode ser preferível mostrar enfâse em páginas em japonês em X/HTML de formas diferentes do que em itálico ou negrito. É muito mais fácil aplicar estas alterações se a apresentação for descrita em CSS e a marcação fica muito mais clara e gerível se o texto estiver claramente e correctamente marcado como "enfatizado" em vez de a "negrito". 

Pode poupar tempo e esforço durante a localização trabalhar com ficheiros CSS em vez de alterar a marcação, pois qualquer alteração pode ser feita numa única posição para todas as páginas e o tradutor pode focar-se no conteúdo em vez de na apresen.

Imagens, animações & exemplos. Verificar traductabilidade e enviezamento cultural inapropriados.

Se deseja que o seu conteúdo comunique realmente com as pe, necessita falar-lhes na sua língua, não só no texto, mas também através da imagem, cor, objectos e preocupações. É fácil esquecer-se a natureza simbólica específica da cultura, comportamentos, conceitos e linguagem corporal, humor, etc. Deve ouvir as pessoas sobre a adequação e relevâncias das suas imagens, vídeo-clipes e exemplos de utilizadores desses países.

Deve também ter cuidado quando incorpora texto nos gráficos quando o conteúdo é traduzido. Texto em fundos complexos ou em espaços restritor podem provocar problemas consideráveis ao tradutor. Deve oferecer gráficos ao grupo de localização que tenham o texto numa camada separada e deve ter em mente que textos em línguas como o inglês e o chinês irão quase de certeza expandir-se nas traduções.

Formulários. Usar uma codificação apropriada no formulário e no servidor. Suporte os formatos locais para nomes/endereços, datas e horas, etc.

A codificação de caracteres usada na página HTML que contenha um formulário deve conter todos os caracteres necessários à inserção de dados no formulário. Isto é particularmente importante se os utilizadores provavelmente inserirem informação em várias línguas.

Bases de dados e scripts que recebam dados de formulários em páginas em várias línguas têm também de suportar caracteres para todas essas línguas em simultâneo.

A forma mais simples de o tornar possível é usar Unicode tanto para páginas contendo formulários e também para todo o processamento e fundo e para armazenamento. Em tal cenário o utilizador preenche os dados em qualquer língua e script que necessite.

Deve também evitar presumir coisas como nome do utilizador e o endereço que se segue irá seguir as mesmas regras de formato que o seu. Pergunte-se quanto detalhe necessita realmente para qu em campos separados em coisas como os endereços. Tenha em mente que em algumas culturas não há coisas como nomes de ruas, noutras o número da porta segue-se ao nome da rua, algumas pessoas necessitam mais do que uma linha para parte do endereço que precede a localidade ou o nome da cudade, etc. De facto em alguns locais o endereço começa do geral para o mais específico, o que implica uma organização espacial diferente. Tenha muito cuidado sobre presunções nas rotinas de validação sobre códigos postais ou comprimentos de números de telefone. Reconheça que uma legendagem cuidada é necessária para inserção de datas numéricas, pois há convenções diferentes para ordenar dia, mês e ano. Se estiver a recolher informação de pessoas de mais do que um país, é importante desenvolver uma estratégia para tratar os formatos em que as pessoas irão esperar ser capazes de usar. Não só é importante para o design dos formulários que crie, mas também tem um impacto sobre o armazenamento de tal informação nas bases de dados.

Informação adicional
Ler a FAQ "Formulários multilingue" para informação adicional sobre o uso de Unicode em formulários. A FAQ "Formatos de data" também oferece alguns pensamentos úteis sobre representação de datas. Mais material irá ser adicionado com o decorrer do tempo.
Autoria de texto. Usar texto simples e conciso. Não componha frases a partir de fragmentos usando scripting.

Texto simples e conciso é mais fácil de traduzir. É também mais fácil de ler se essa leitura não for a de uma língua-mãe.

Deve ter muito cuidado quando compõe uma mensagem a partir de vários fragmentos ou quando insere texto váriavel numa cadeia de caracteres. Por exemplo, imagine que o seu sítio usa JSP scripting, pode decidir compôr certas mensagens no momento. Pode criar mensagens concatenando fragmentos separados tais como  'Só' ou '[sem tradução] Don't', ' resultados retornados em ', e 'qualquer formato' ou 'HTML'. Porqie a ordem dos textos nas frases noutras línguas pode ser diferente, traduzir isto pode criar grandes dificuldades.

De forma similar, é importante evitar fixar posições de variáveis em textos como "1 página de 10". A síntaxe noutras línguas pode ser completamente diferente de forma a fazerem sentido. Se usar PHP, isto significa formatar o texto como "Page %1\$d of %2\$d.", em vez do mais simples "Page %d of %d.". Este último pode ser impossível de traduzir em algumas línguas.

Informação adicional
Ler "Trabalhar com mensagens compostas" e "Reutilizar cadeias de caracteres em conteúdo gerado por Scripts" para informação adicional sobre boas e más práticas quando se compõem frases a partir de várias cadeias de caracteres.
Navigação. Em cada página incluir claramente visível navegação para páginas ou sítios localizados. Usar a língua de destino.

Onde tenha versões da página ou sítio em línguas diferentes, ou um país ou região diferentes, deve oferecer ao utilizador um modo de ver a versão que preferir. Isto deve estar disponível de qualquer página no seu sítio que tenha uma alternativa. Quando oferecer ligações para páginas noutras línguas, usar o nome da língua de destino na língua e script nativos. Não presuma que o utilizador possa lêr em português. Por exemplo, numa ligação para uma página em francês, 'Francês' deverá ser escrito como 'français'. Isto também se aplica se estiver a conduzir o utilizador para uma página específica de um país ou região, por exemplo 'Alemanha' deve ser 'Deutschland'.

Mais informação
Ler "Usar <select> para ligar a conteúdo localizado" sobre a utilização de <select> para ligar a conteúdo localizado. Artigos adicionais sobre ligações a conteúdo localizado serão disponibilizados no futuro próximo. Idem para navegação.
Texto da direita para a esquerda. Em XHTML, adicionar dir="rtl" ao marcador html. Só reutilizar para mudar a direccionalidade.

Textos em línguas tais como o árabe, hebreu, persa e urdu são lidas da direita para a esquerda. Esta ordem de leitura conduz a uma organização espacial espelhada com texto alinhado à direita e arranjo da página e tabelas. Pode especificar o alinhamento e ordenação do conteúdo da página da direita para a esquerda incluindo dir="rtl" no marcador html.

A direcção especificada no marcador html influencia em cascata todos os elementos na página. Não é necessário repetir o atributo em elementos de nível mais baixo a não ser para mudar explicitamente de fluxo direccional.

Texto embebido, por exemplo texto latino continua a correr da esquerda para a direita dentro do fluxo geral da direita para a esquerda, tal como os números. Se estiver a trabalhar com línguas da direita para a esquerda deve ficar familiarizado com os fundamentos do algoritmo de bidireccionalidade do Unicode. Este algoritmo trata da maior parte do texto bidireccional sem necessidade de intervenção da parte do autor. Há circunstâncias, contudo, onde a marcação e os caracters de controlo Unicode são necessários para assegurar o efeito correcto.

Informação adicional
Ler "Técnicas de Autoria para Internacionalização em XHTML & HTML Internationalization: Tratar de Texto Bidireccional" para informação sobre como trabalhar scripts da direita para a esquerda , e "Criar Páginas Bidi XHTML/HTML" para uma introdução suave aos fundamentos de tratamento, em linha, de texto bidireccional.
Experiente ?
Cf. índice cruzado para informação adicional.
Verifique o seu trabalho. Valide-o! Use técnicas, guias e artigos em http://www.w3.org/International/Conjuntos de Caracteres & codificações em XHTML, HTML e CSS

Outros materiais introdutórios

Publicamos recentemente uma página sobre como Começar para o ajudar a encontrar informação no sítio. Esta página inicial aponta para uma série de artifos que estão a progredir e oferece aos iniciados uma introdução agradável para tópicos chave sobre internacionalização e aponta para informação básica sobre o sítio para poder continuar.

16 novembro, 2006

Creative Commons em Portugal

Já foi lançada a versão portuguesa da Criative Commons.

Amy Hoy no seu melhor

Como (quanto?)gostaria de saber escrever assim: Os 5 pecados da escrita técnica.

Novos RFC 4646 e 4647

O IETF anunciou em Setembro dois novos RFC, o RFC 4646 Tags for Identifying Languages e o RFC 4647 Matching of Language Tags. Estes dois documentos constituem o BCP 47. Tornam obsoleto o RFC 3066 (que tinha substituído o RFC 1766).

O RFC descreve como criar e fazer corresponder marcadores de línguas, por exemplo para uso como valores nos atributos lang do HTML e xml:lang do XML. As novas especificações são retrocompatíveis, mas providenciam expansões significativas para o conceito de marcador de língua incluindo tais coisas como: script tags, códigos de região UN, variant tags, etc para uso quando necessários.

A Actividade de Internacionalização do W3C está a preparar um artigo Marcadores de Línguas em HTML e XML para oferecer uma introdução suave às novas estruturas de marcadores. Há também um artigo Compreender os novos marcadores de línguas que alude a algumas das razões que causaram a mudança.

Edge Novembro

Saiu o número da Edge de Novembro/Dezembro com o seguinte conteúdo:

09 novembro, 2006

Venham as tabelas

O documento que se segue é uma tradução do artigo: Venham as tabelas de Roger Johansson.

  1. Introdução
  2. Cabeçalhos de Tabela
  3. Legendas de Tabela
  4. Explicar a Tabela
  5. Abreviar Cabeçalhos
  6. Associar Cabeçalhos a Dados
  7. Unir Linhas e Colunas
  8. Colunas e Grupos de Colunas
  9. Grupos de Linhas
  10. Só para Tabelas de Dados
  11. As Vantagens
  12. O Que Eu Não Lhe Disse

Introdução

Uma das coisas que confunde as pessoas que são novatas no uso de arranjos (layout) baseados em CSS é o uso de tabelas. Já vi muitos casos onde as pessoas interpretaram evitar usar tabelas para arranjo como não usar tabelas de todo. É importante perceber que o uso de tabelas está certo desde que usadas correctamente.

Sim, faça o seu melhor para evitar usar tabelas para arranjos, mas para dados tabulares, tabelas é o que deve usar-se. Desejo falar de como é que devem ser usadas as tabelas em HTML e XHTML para além das linhas e células. Muito mais. Especialmente se desejar que essas tabelas sejam acessíveis.

Primeiro um pouco de informação de fundo. A expressão "evitar usar tabelas para arranjos" encontra-se na Introdução às tabelas na especificação do HTML 4.01:

As tabelas não deveriam ser utilizadas única e simplesmente como forma de dar uma apresentação ou "layout" aos documentos, dado que isso poderá apresentar problemas para os médias de representação não visual. Adicionalmente e aquando usadas com gráficos, estas tabelas poderão ter de ser desdobradas horizontalmente, de modo a que elas se possam visualizar, sempre que designadas num sistema com uma exibição mais ampla. Para minimizar esses problemas, os autores deveriam usar as folhas de estilo, com vista a controlar os aspectos relacionados com o "layout", em vez das tabelas.

Julgo que isto é suficientemente claro, embora a expressão usada seja deve e não tem que, se assim sendo há alguma flexibilidade na especificação.

Quando são usadas tabelas para marcar dados, elas não são uma mera grelha. As pessoas que vêm podem ter uma ideia da relação entre o cabeçalho e as células de dados olhando para o arranjo e para a apresentação visual da tabela. As pessoas cegas ou dificuldades de visão não o podem fazer. Para que uma tabela seja acessível a pessoas que usam um leitor de ecrã ou um agente utilizador não visual, é necessário dizer ao agente utilizador como é que a informação contida se relacciona.

Cabeçalhos de Tabela, <th>

Comecemos com uma tabela muito simples que tem uma só linha de cabeçalhos, cada um definindo dados numa coluna. Marcada da forma antiga, nós só colocamos linhas e células na tabela, sendo que a marcação seria algo como:


<table>
  <tr>
   <td>Empresa</td>
   <td>Empregados</td>
   <td>Fundada em</td>
  </tr>
  <tr>
   <td>Uma Lda.</td>
   <td>20</td>
   <td>1947</td>
  </tr>
  <tr>
   <td>XYZ</td>
   <td>1955</td>
   <td>1999</td>
  </tr>
</table>

Sem border ou estilização a tabela surge da seguinte forma no seu navegador actual:

Empresa Empregados Fundada em
Uma Lda. 20 1947
XYZ 1955 1999

Se estilizar a tabela com um pouco de CSS, pode tornar os cabeçalhos mais óbvios para os que usem um navegador gráfico:

Empresa Empregados Fundada em
Uma Lda. 20 1947
XYZ 1955 1999

Para uma pessoa com boa visão, é agora fácil e rápido fazer uma ligação entre as células de cabeçalho e as células de dados que os descrevem. Alguém que use um leitor de ecrã, por outro lado, iria ouvir algo semelhante a : empresa empregados fundada em Uma lda. 20 1947 XYZ 55 1999. Não é muito fácil extrair o significado.

O primeiro passo - e o mais fácil - para a frente de modo a tornar esta tabela mais acessível é marcar adequadamente os cabeçalhos. É muito fácil: usar o elemento <th> (table header/cabeçalho de tabela) em vez do <td> (table data/dado de tabela) nas células de cabeçalho


<table>
  <tr>
   <th>Empresa</th>
   <th>Empregados</th>
   <th>Fundada em</th>
  </tr>
  <tr>
   <td>Uma Lda.</td>
   <td>20</td>
   <td>1947</td>
  </tr>
  <tr>
   <td>XYZ</td>
   <td>55</td>
   <td>1999</td>
  </tr>
</table>
Empresa Empregados Fundada em
Uma Lda. 20 1947
XYZ 55 1999

No caso desta tabela simples, isto seria suficiente para que o leitor de ecrã fosse capaz de deixar o utilizador saber com que célula de dados está relacionado cada cabeçalho. O leitor de ecrã poderia dizer algo como: "Empresa: Uma lda. Empregados: 20 Fundada em: 1947, e assim sucessivamente para cada linha. Muito Melhor.

Legendas de tabela: <caption>

O elemento <caption> pode ser usado para oferecer uma breve descrição de uma tabela, tal como uma legenda de uma imagem. Por omissão a generalidade dos navegadores gráficos reproduzem o elemento <caption> centrado por cima da tabela. A propriedade CSS caption-side pode ser usada para o alterar, se necessário. A maior parte dos navegadores só irá mostrar a legenda por cima (top) ou por baixo (bottom) do conteúdo da tabela, alguns aceitam também valores de left (à esquerda) e right (à direita). Deixo-lhe como tarefa experimentar isto.

Quando usado o elemento <caption> deve ser a primeira coisa após a abertura do marcador <table>:


<table>
 <caption>Tabela 1: Dados das empresas</caption>
  <tr>
   <th>Empresa</th>
   <th>Empregados</th>
   <th>Fundada em</th>
  </tr>
  <tr>
   <td>Uma Lda.</td>
   <td>20</td>
   <td>1947</td>
  </tr>
  <tr>
   <td>XYZ</td>
   <td>55</td>
   <td>1999</td>
  </tr>
</table>
Tabela 1: Dados das empresas
Empresa Empregados Fundada em
Uma Lda. 20 1947
XYZ 55 1999

Claro que pode usar CSS para estilizar a legenda caso o deseje. Contudo tenha em atenção que pode ser complicado estilizar a legenda de forma consistente em todos os navegadores. Deixo isto como exercício para si.

Explicar a tabela: o atributo summary

Uma pessoa com visão pode facilmente decidir se deve ou não estudar uma tabela em detalhe. Uma vista rápida informa-lo-à de se a tabela é grande ou pequena e dá-lhe uma primeira aproximação sobre o seu conteúdo. Uma pessoa que use um leitor de ecrã não o pode fazer excepto se adicionarmos um atributo summary ao elemento tablez. Esta é a forma de oferecer-mos uma descrição mais detalhada da tabela do que aquilo que seria adequado com o elemento <caption.

O conteúdo do atributo summary não será reproduzido nos navegadores visuais, assim trate de ser tão explicito quanto possível de forma a que qualquer pessoa que possa ouvir compreenda sobre que assunto a tabela se debruça. Não se exceda, e só use este atributo quando necessário, isto é, para tabelas complexas onde um sumário tornará mais fácil a alguém que use um leitor de ecrã compreender o conteúdo da tabela.


<table 
  summary="Número de funcionários e ano da fundação de 2 empresas imaginárias
 ">
 <caption>Tabela 1: Dados das empresas</caption>
  <tr>
   <th>Empresa</th>
   <th>Empregados</th>
   <th>Fundada em</th>
  </tr>
  <tr>
   <td>Uma Lda.</td>
   <td>20</td>
   <td>1947</td>
  </tr>
  <tr>
   <td>XYZ</td>
   <td>55</td>
   <td>1999</td>
  </tr>
</table>

Abreviar cabeçalhos: o atributo abbr

Quando um leitor de ecrã encontra uma tabela, pode anunciar o cabeçalho associado (ou cabeçalhos) antes de cada célula de dados. Se tiver um cabeçalho extenso, ouvi-los repetidamente pode ser um tédio. Usar o atributo abbr dá a possibilidade aos leitores de ecrã de usarem essas abreviaturas em vez do texto no próprio cabeçalho. Usar o atributo abbr é opcional e a maior parte do tempo os seus cabeçalhos serão (e talvez devam ser) breves de qualquer modo.

Se a tabela de exemplo for ligeiramente alterada de modo a que os cabeçalhos sejam um pouco maiores o atributo abbr pode ser usado da seguinte forma:


<table
  summary="Número de funcionários e ano da fundação de 2 empresas imaginárias
 ">
 <caption>Tabela 1: Dados das empresas</caption>
  <tr>
   <th abbr="Empresa">Razão social</th>
   <th abbr="Empregados">Número de empregados Empregados</th>
   <th abbr="Fundada">Fundada em</th>
  </tr>
  <tr>
   <td>Uma Lda.</td>
   <td>20</td>
   <td>1947</td>
  </tr>
  <tr>
   <td>XYZ</td>
   <td>55</td>
   <td>1999</td>
  </tr>
</table>
Tabela 1: Dados das empresas
Razão social Número de empregados Empregados Fundada em
Uma Lda. 20 1947
XYZ 55 1999

Um leitor de ecrã poderia ler o cabeçalho completo na primeira linha de dados e nas seguintes utilizaria a forma abreviada.

Como provavelmente pode ser mais difícil uma tabela de dados encaixar-se num determinado arranjo, diria que seria mais comum necessitar do oposto: fazer cabeçalhos breves tanto quanto possível, mesmo abreviados, e usar o atributo title ou o elemento <abbr> para fornecer uma explicação mais extensa.

Associar cabeçalhos a dados: os atributos scope (âmbito), id e header (cabeçalho)

Algumas tabelas são mais complexas do que a do exemplo que tenho vindo a usar. Vou torná-la um pouco mais complexa retirando o cabeçalho "Empresa" e alterando as células de dados da primeira coluna em células de cabeçalhos:


<table
  summary="Número de funcionários e ano da fundação de 2 empresas imaginárias
 ">
 <caption>Tabela 1: Dados das empresas</caption>
  <tr>
    <td></td>
   
   <th abbr="Empregados">Número de empregados</th>
   <th abbr="Fundada">Fundada em</th>
  </tr>
  <tr>
   <th>Uma Lda.</th>
   <td>20</td>
   <td>1947</td>
  </tr>
  <tr>
   <th>XYZ</th>
   <td>55</td>
   <td>1999</td>
  </tr>
</table>
Tabela 1: Dados das empresas
Número de Empregados Fundada em
Uma Lda. 20 1947
XYZ 55 1999

Nesta tabela cada célula de dados tem dois cabeçalhos. O método mais simples, em termos de marcação para assegurar que um navegador não visual pode fazer sentido desta tabela é adicionar o atributo scope a todas as células de cabeçalho:


<table
  summary="Número de funcionários e ano da fundação de 2 empresas imaginárias
 ">
 <caption>Tabela 1: Dados das empresas</caption>
  <tr>
    <td></td>
    <th scope="col">Empregados</th>
    <th scope="col">Fundada em</th>
  </tr>
  <tr>
   <th scope="row">Uma Lda.</th>
   <td>20</td>
   <td>1947</td>
  </tr>
   <th scope="row">XYZ</th>
   <td>55</td>
   <td>1999</td>
  </tr>
</table>

O âmbito do atributo scope define se a célula cabeçalho dá informação sobre uma coluna ou de uma linha:

  • col: cabeçalho informativo para a coluna em que se encontra
  • row: cabeçalho informativo para a linha em que se encontra

Adicionar o atributo scope com o valor col aos cabeçalhos na primeira linha declara que se tratam de cabeçalhos para as células de dados por baixo deles. Do mesmo modo os cabeçalhos no início de cada linha com um atributo scope com o valor row torna esses cabeçalhos cabeçalhos das células de dados à sua direita.

O atributo scope pode tomar mais dois valores:

  • colgroup: a informação do cabeçalho para o resto do grupo de colunas que o contem.
  • rowgroup: a informação do cabeçalho para o resto do grupo de linhas que o contem

Um grupo de colunas é definido pelo elemento <colgroup>. Os grupos de linhas são definidos por <thead>, <tfoot> e <tbody>. Voltarei a estes num instante.

O que sucede se desejar manter o cabeçalho "Empresa" e mesmo assim usar o cabeçalhos de linha com os nomes das empresas? Isso levará as células contendo os nomes das empresas a oferecer tanto o cabeçalho como os dados. Neste caso, <td> deve ser usado em conjunto com o atributo scope:


<table
  summary="Número de funcionários e ano da fundação de 2 empresas imaginárias
 ">
 <caption>Tabela 1: Dados das empresas</caption>
  <tr>
    <th scope="col">Empresa</th>
    <th scope="col">Empregados</th>
    <th scope="col">Fundada em</th>
  </tr>
  <tr>
   <td scope="row">Uma Lda.</td>
   <td>20</td>
   <td>1947</td>
  </tr>
   <td scope="row">XYZ</td>
   <td>55</td>
   <td>1999</td>
  </tr>
</table>

Neste caso os navegadores visuais não irão apresentar os nomes das companhias como cabeçalhos por omissão, e assim é necessário um pouco de CSS para corrigir esse facto. Para este exemplo pode usar-se o seguinte CSS:


td[scope] {
  font-weight: bold;
}

Nota: esta regra usa um selector de atributo, o qual o Internet Explorer não suporta. É necessário contornar isto adicionando uma classe a qualquer célula de dados que seja também cabeçalho de linha.

Outra técnica para ligar as células de dados da tabela com os cabeçalhos apropriados envolve dar a cada cabeçalho uma id única. O atributo headers é então adicionado a cada célula de dados. Este atributo contém uma lista, separada por espaços, das id de todas as células de cabeçalhos que lhe sejam aplicados. Esta técnica é mais complicada e deve ser usada só quando as células de dados que necessitam de ser ligadas a mais do que duas células de cabeçalhos, e o atributo scope é insuficiente, como numa tabela muito fora do fulgar e complexa.

Para ilustrar isto alterei a tabela para mostrar o número de empregados de cada género que cada empresa tem:


  <table class="extbl" summary="Número de funcionários e ano da fundação de 2 empresas imaginárias.">
  <caption>Tabela 1: Dados das Empresas</caption>
  <tr>
  <td rowspan="2"></td>
  <th id="empregados" colspan="2">Empregados</th>
  <th id="fundada" rowspan="2">Fundada em</th>
  </tr>
  <tr>
  <th id="homens">Homens</th>
  <th id="mulheres">Mulheres</th>
  </tr>
  <tr>
  <th id="uma">Uma Lda.</th>
  <td headers="uma empregados homens">15</td>
  <td headers="uma empregados mulheres">5</td>
  <td headers="uma fundada">1947</td>
 </tr>
  <tr>
  <th id="xyz">XYZ</th>
  <td headers="xyz empregados homens">1200</td>
  <td headers="xyz empregados mulheres">799</td>
  <td headers="xyz fundada">1973</td>
  </tr>
  </table>
Tabela 1: Dados das Empresas
Empregados Fundada em
Homens Mulheres
Uma Lda. 15 5 1947
XYZ 1200 799 1973

Como pode ver este método torna-se rapidamente complicado, e assim sendo possível use o atributo scope em seu lugar.

Unir (span) linhas e colunas

Na antiguidade, nos dias de tabelas para arranjos, os atributos rowspan e colspan eram frequentemente usados para fazer com que as células da tabela abarcacem várias linhas e ou colunas de forma a posicionar correctamente em conjunto uma imagem correctamente recortada. Esses atributos ainda se encontram por aí - não há forma de especificar com CSS esta junção. Se se pensar um pouco sobre isto é muito lógico: junções de linhas e de colunas são parte da estrutura da tabela e não na sua apresentação.

Colunas e grupos de colunas: <col> e <colgroup>

O HTML oferece os elementos <colgroup> e <col> servem para agrupar colunas relacionadas numa tabela. Isto permite (em alguns navegadores) o uso de CSS para estelizar colunas de forma independente. Grupos de colunas podem ser usadas pelo atributo scope para especificar que uma célula contém informação de cabeçalho para o resto do grupo de colunas que a contenha.

É tudo o que vou dizer, aqui, sobre colunas e grupos de colunas. Para mais informação ler as ligações na secção "O que é que não lhe disse".

Grupos de linhas: <thead>, <tfoot> e <tbody>

As linhas da tabela podem ser agrupadas num cabeçalho da tabela (<thead>), um rodapé da tabela (<tfoot>) e uma ou mais secções de corpos de tabela (<tbody>). Cada grupo de linhas tem que conter uma ou mais linhas.

Se uma tabela possui uma secção de cabeçalho, esta tem que aparecer antes da secção de rodapé de tabela e da ou das secções de corpo da tabela. Uma secção de rodapé tem que aparecer antes da ou das secções de corpo. Se não for usada nenhuma secção de cabeçalho ou rodapé não é necessário usar um elemento <tbody, mas também não é proibido (se quizer pode usar). A estrutura da tabela que tenha grupos de linhas é algo como:


<table>
 <thead>
 <tr></tr>
 … mais linhas para o cabeçalho da tabela
 </thead>
 <tfoot>
 <tr></tr>
 … mais linhas para o rodapé da tabela
 </tfoot>
 <tbody>
 <tr></tr>
… mais linhas para o primeiro corpo da tabela
 </tbody>
 <tbody>
 <tr></tr>
 … mais linhas para o segundo corpo da tabela
 </tbody>
 … mais corpos de tabela se necessário
</table>

O agrupamento de linhas pode ser útil por várias razões:

  • Torna fácil a estilização das secções de cabeçalho, rodapé e corpos de uma tabela independentemente uns dos outros, sem ter que adicionar classes a qualquer elemento.
  • Quando se imprime tabelas extensas, em alguns navegadores (principalmente os baseados no Mozilla) repetem a informação presente nas secções de cabeçalho e rodapé a cada página impressa, tornando a leitura da tabela impressa mais fácil.
  • A separação de cabeçalho e rodapé do corpo torna possível que os navegadores suportem o rolar do corpo da tabela com as restantes secções da tabela fixas.

Só para tabelas de dados

Tudo o que aqui é descrito está relacionado com o uso de tabelas HTML para estruturar e apresentar dados. Se usar tabelas para arranjo, nenhuma das técnicas descritas aqui deve ser usada. Não deve ser usado nenhum atributo summary nenhum cabeçalho, nenhuma legenda (<caption>), nada. Só arranjo de página baseado em tabelas, consistindo em nada mais do que os elementos <table>, <tr> e <td>. Caso contrário corre o risco de confundir os utilizadores dos agentes utilizadores não visuais ainda mais.

As vantagens

Pode parecer muito trabalho para criar tabelas de dados acessíveis. Para tabelas complexas tal é verdade. Por vezes ao ponto de ser quase impossível de o fazer à mão. Para tabelas simples, o uso de células de cabeçalho com o atributo scope é fácil e rápido.

É óbvio que pessoas que usem leitores de ecrã ou outras tecnologias de assistência obtêm vantagens de tabelas que tenham disponíveis capacidades de acessibilidade. Tentar extrair significado de uma tabela grande e complexa ouvindo-a pode ainda ser muito difícil e assim se for possível simplifique a tabela.

Menos óbvio é que os designers e os utilizadores de navegadores gráficos também beneficiam algo: uma tabela acessível tem pontos de ancoragem suficientes para aplicar CSS e uma boa estilização pode tornar uma tabela mais usável para todos.

O que eu não lhe disse

Há ainda muito mais a dizer sobre tabelas de dados do que aquilo que aqui mencionei. Por exemplo, não me referi a um atributo axis até aqui de todo, e também não descrevi em profundidade os elementos <colgroup> e <col>. Também não falei de formatação e estilização ou modelos de bordas. Também falta um exemplo de uma tabela realmente complexa.

Para aqueles que desejem informação mais detalhada eis algumas ligações para leitura adicional:

08 novembro, 2006

Reinventar o HTML

O Maurício Samy Silva alias maujor, traduziu a entrada do blogue do Tim BL sobre reinvenção do HTML. É aliás um dos poucos comentadores de origem linguística portuguesa (se bem que do Brasil) no próprio site do w3c sobre este tema.

Nota: Neste site encontram-se tradução para português do Brasil de uma série de standards.

O Futuro do HTML

O que se segue é uma tradução de um artigo publicado por Lachan, O futuro do HTML, editado por Molly e Roger.

Este artigo foi escrito em nome do Web Hypertext Application Technology Working Group (WHATWG) e foi publicado no The Web Standards Project, Molly.com e 456 Berea Street.

Tem havido uma grande discussão, ultimamente na web, sobre a recente decisão do W3C de continuar o desenvolvimento do HTML. Têm sido efectuadas muitas entradas em blogues, enviadas muitas mensagens a listas de correio ou colocadas em forúns, revelando várias perguntas e conceitos errados sobre o futuro do HTML (incluindo HTML 5 e XHTML 2), o WHATWG e o novo Grupo de Trabalho HTML do W3C.

Algumas pessoas pedem novas características/capacidades; outra imaginam se elementos que tenham sido considerados quase obsoletos voltam; alguns têm comentários e críticas sobre a própria decisão, o processo do WHATWG ou W3C; alguns levantam preocupações sobre o WHATWG e W3C ignorarem necessidades de grupos específicos. O WHATWG, que está em processo de desenvolvimento da nova versão do HTML (designada por HTML5), acha que é importante não só houvir tudo o que se diz (toda a retroalimentação), mas procurar activamente essa retroalimentação e reagir à mesma, de modo a poder desenvolver uma linguagem que vá de encontro às suas necessidades.

Há várias maneiras nas quais pode participar. A mais directa é fazer ouvir a sua voz subscrevendo a lista de correio. Contudo, nem toda a gente tem tempo para participar, ou manter-se actualizado com o elevado volume de mensagens enviado para essa lista. Algumas pessoas acham que os actuais rascunhos do HTML 5 (Aplicações Web e Formulários Web) são algo complicado. Outros acham que devido a não poderem pagar as quotas elevadas de membro do W3C, que não serão ouvidos de qualquer modo.

Se, por qualquer razão, que não pode participar, ou que estaria desconfortável a fazê-lo, isso não quer dizer que não deva ser ouvido. O WHATWG necessita de ouvi-lo e necessita de saber o que é que pensa sobre o HTML.

  • Há limitações com o HTML que gostaria de ver corrigidas?
  • Tem ideias sobre novas características/capacidades?
  • Há algo que possa fazer agora em HTML mas que gostaria de ver melhorado?
  • Tem alguma preocupação com o processo de desenvolvimento?
  • Tem algo a dizer sobre as novas características/capacidades nos actuais rascunhos?
  • Tem alguma pergunta a colocar sobre o HTML 5?

Quaisquer perguntas, comentários, críticas, reclamações ou pedidos de características/capacidades são bem-vindos. Agora é o momento para falar. Não há comentários estúpidos; nenhuma pergunta é demasiado difícil ou demasiado simples; nenhuma crítica é demasiado rude. Se tem algo a dizer, estamos à escuta.

Por favor deixe um comentário ou deixe uma ligação para um artigo que tenha escrito. Será escutado e tentaremos responder.