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

21 dezembro, 2006

A List Apart 229

Acaba de sair o último número (229) do A List Apart de 2006. Neste número são apresentados dois novos artigos:

Actividade do W3C na semana que acaba em 2006-12-22

O dia de ontém 20 de Dezembro foi particularmente activo no sítio do W3C. Notas de grupos sobre assinatura digital, o WAI a tentar disciplinar os conteúdos dinâmicos para que sejam acessíveis e ainda alguma soap.

20 dezembro, 2006

Melhores Práticas Móveis 1.0

O Grupo de Trabalho de Melhores Práticas Móveis acaba de publicar o segundo Rascunho de Trabalho dos W3C mobileOK Basic Tests 1.0. Este documento define os testes que oferecem fundamento para declarar que determinado conteúdo é conforme o W3C mobileOK Basic que são baseados sobre as Melhores Práticas Móveis do W3C.

19 dezembro, 2006

Usar AR em Ruby

Como usar ActiveRecord em programação em Ruby (sem o resto do rails)


require "rubygems"
require_gem "activerecord"

ActiveRecord::Base.establish_connection(
:adapter => "mysql",
:host => "hospedeiro",
:database => "basededados",
:username => "utilizadordb",
:password => "palavradepassedoutilizadordb"
)

class MinhaTabela < ActiveRecord::Base
end

< partir daqui pode usar-se o acesso CRUD (Create, Read, Update, Delete) à tabela.

10 anos com estilo no W3C

Comemoram-se 10 anos (17 de Dezembro) desde que o W3C publicou a primeira recomendação sobre folhas de estilo em cascata.

Declaração da Missão do WaSP (Tradução)

Tabela de conteúdos

WaSP: Lutar pelos Standards

O World Wide Web Consortium (W3C), assim como outros grupos e corpos normativos, tem tecnologias estabelecidas para criação e interpretação de conteúdo baseado na web. Estas tecnologias que designamos por "web standards", foram concebidas cuidadosamente para se obterem as maiores vantagens para o maior número de utilizadores da web assegurando ao mesmo tempo a viabilidade de longo prazo de qualquer documento publicado na Web. Ver a barra lateral para detalhes.

Conceber e construir sítios usando esses standard simplifica e baixa o custo de produção, entregando sítios que são acessíveis a mais pessoas em mais tipos de dispositivos de Internet. Os sítios desenvolvidos de acordo com essas directrizes irão continuar a funcionar correctamente à medida que os navegadores de secretária continuarem a evoluir, e à medida que novos dispositivos de Internet vão ficando disponíveis.

Parece tão directo e faz todo o sentido. Então qual é o problema? E porque é que há um Web Standards Project (WaSP)?

O Problema

Embora os fabricantes dos navegadores líderes tenham estado envolvidos na criação dos web standards desde que o W3C foi formado, durante vários anos a conformidade foi observada no fio da navalha. Ao publicarem navegadores que falhavam no suporte uniforme de standards, os fabricantes fragmentaram desnecessariamente a Web, prejudicando os designer, os programadores, os utilizadores e os empresários.

A falta de suporte uniforme de standards chave do W3C deixaram os consumidores frustrados: quando usavam o navegador "errado", muitos não podiam ver o conteúdo ou efectuar as transacções desejadas. Entre as pessoas mais frequentemente prejudicadas encontram-se as pessoas com deficiência ou necessidades especiais.

Dilemas e Custos

Ao mesmo tempo, a falta de suporte uniforme de standards chave W3C deixou ou designer, programadores e proprietários de sítios num terrível dilema: podem pagar a implementação de várias versões de todas as páginas da web de modo a acomodarem navegadores incompatíveis? Se não, que navegadores devem negligenciar e quantos milhões de potenciais visitantes estão dispostos a rejeitar? De qualquer modo, o custo era demasiado alto, ainda o é.

O mercado fracturado dos navegadores representa pelo menos 25% do custo do desenvolvimento de todos os sítios. Devido a orçamento insuficiente, muitas pessoas que desenvolvem sítios produzem-nos de modo a bloquear clientes potenciais. Várias pessoas que desenvolvem sítios e que conhecem sobre standards não vêm razão para serem desenvolvidos sítios que não os suportem. Outros pouco ou nada sabem sobre standards - e vários incluindo os produzidos por grandes agências que parecem perceber de ASP, Java, Flash MX e .Net, parecem não perceber nada sobre marcação semântica e estrutural, folhas de estilo e a importância da segregação da estrutura e da apresentação.

Alguns designer, estimulados devido à incompatibilidade entre navegadores, deliberadamente excluíram todas as tecnologias excepto as mais antigas e universais dos seus sítios. Estes sítios funcionam correctamente em todos os navegadores de secretária, mas com o custo de serem pouco apelativos e com poucas funcionalidades para os consumidores. Outos dependem dos editores visuais e ferramentas de edição para gerarem várias camadas de marcação e código optimizado para as excentricidades de vários navegadores populares. Isto é dinheiro desperdiçado em largura de banda e frequentemente os sítios gerados deixam de funcionar na geração seguinte dos navegadores (e nunca funcionaram em todos os navegadores e dispositivos alternativos, de leitores de ecrã ao Lynx a dispositivos de mão a navegadores menos populares como o Opera). A Web está cheia de cadáveres de sítios que foram em tempos impressionantes que não conseguem funcionar em dispositivos e navegadores contemporâneos. Para tornar as coisas mais complicadas, tais sítios estão ainda a ser criados todos os dias.

Alguns designer ficaram tão frustrados que deixaram de ligar de todo aos web standards e começaram a desenvolver sítios em ambientes proprietários. Embora ricos em potencial criativo, tais tecnologias sofrem de uma acessibilidade de largo espectro e não oferecem características de necessidades comuns como as marcas de leitura (marcadores para livros), impressão, cópia e colagem e outras tarefas que os utilizadores da web têm que efectuar em sítios informativos ou transaccionais.

Nascido da Necessidade

Em resposta a estes problemas, o The Web Standards Project (WaSP) (vespa em inglês algo laborioso) foi formado em 1998 com o objectivo de promover os web standards centrais e encorajar os fabricantes de navegadores a fazer o mesmo, e assim assegurar um acesso simples e barato para todos.

Embora a nossa mensagem inicialmente tenha encontrado alguma resistência (particularmente dos departamentos de marketing e relações públicas das companhias fabricantes de navegadores), eventualmente prevalecemos - em parte porque engenheiros em alguns desses fabricantes acordaram connosco e viram o WaSP como um aliado nas suas batalhas internas com a gestão.

No início de 2000, um após outro dos navegadores de topo passaram a funcionar como prometido de acordo com os standards que tínhamos (por vezes estridentemente) promovido. Actualmente os navegadores de topo, assim como alguns dos seus concorrentes, têm um suporte excelente para HTML 4, compatibilidade com XHTML 1.0, CSS nível 1, ECMAScript (a versão normalizada do Javascript) e o DOM ou estão no caminho de obterem essa conformidade.

Graças a esses navegadores, os designer e pessoas que desenvolvem sítios são finalmente livres de construir com XHTML e CSS e na maior parte dos casos podem separar a estrutura da apresentação para um máximo de portabilidade e acessibilidade. Com cuidado, podem também usar o DOM standard do W3C para adicionarem comportamento sofisticado aos seus sítios.

Então onde é que está o problema e porque é que existe ainda o The Web Standard Project?

Os Desafios Futuros

Embora os navegadores actuais suportem os standards, dezenas de milhares de designer profissionais e programadores continuam a usar métodos ultrapassados que ligam a estrutura à apresentação e em muitos casos evitam completamente as estruturas semânticas e utilizam incorrectamente o (X)HTML como ferramenta de concepção. Profissionais bem pagos continuam a produzir sítios inválidos e inacessíveis com marcação sem significado semântico, mapas de imagens gigantes, tabelas aninhadas até à medula e scripts de detecção desactualizados que causam problemas de usabilidade que tinham intenção original de evitar.

Há ainda muitos livros de desenvolvimento para a Web que ensinam métodos desactualizados e muitos profissionais têm orgulho em produzir sítios que têm o mesmo aspecto e funcionam da mesma forma em navegadores conformes e não conformes, com custos em termos de acessibilidade, viabilidade de longo prazo, compatibilidade futura e falta de suporte de dispositivos alternativos. Outros produzem sítios que só funcionam numa mão cheia de navegadores mais populares.

Assim um dos objectivos primários do WaSP é providenciar recursos educativos que podem ajudar os nossos pares a aprenderem métodos conforme os standards que são do seu interesse e do interesse dos seus clientes e utilizadores de sítios.

Muitos profissionais utilizam no seu trabalho ambientes de edição visual concebidos no tempo da Guerra Entre Navegadores. Tal como mencionado acima tais ferramentas por omissão criam sítios inválidos, não semânticos optimizados para navegadores na versão 4.0 em modo quirks (esquisito) em vez de ser em modo standards. Em 2002, dois editores visuais melhoraram de forma apreciável o seu suporte em relação aos web standards e acessibilidade (um deles com ajuda do The Web Standards Project). Mas para tirarem partido destas melhorias os profissionais têm que aprender as vantagens de conceber os sítios com web standards. Isto aponta novamente para a necessidade que que as pessoas que desenvolvem sítios voltem a aprender.

Os clientes e os gestores de sítios também necessitam desta informação se querem criar sítios que sejam acessíveis aos navegadores e dispositivos actuais e que se mantenham visíveis à medida que os navegadores e dispositivos se vão actualizando. o WaSP espera, que uma vez informados das vantagens que os standard propiciam, que os proprietários dos sítios deixem de ver os seus sítios como uma espécie de publicidade impressa que deva ser vista exactamente da mesma maneira em todos os ambientes. E que passem a focar-se em seu lugar no fornecimento de conteúdo e funcionalidades apropriadas ao contexto das apresentações que podem diferir de acordo com as necessidades de diferentes navegadores e dispositivos.

A Declaração de Missão original do WaSP feita em 1998 encontra-se disponível em archive.webstandards.org.

24 Maneiras de impressionar as suas amigas (e amigos) - II

24 maneiras.

18 dezembro, 2006

Actualização do digg

O digg está a ser actualizado dentro de alguns minutos estará pronto para ser continuado a servir.

15 dezembro, 2006

Boas práticas - RoR - Segurança

A segurança é um tópico um pouco aborrecido mas que pode tornar-se excitante se fizermos uma grande asneira. Para evitar essas excitações, eis uma lista de verificação para revisão de segurança em modelos, controladores e vistas. Se vir algum buraco (há com toda a certeza vários) faça um comentário e actualizarei a lista.

  • Lista de verificação de segurança para modelos
    • Usar attr_accessible (ou attr_protected se necessário) para identificar explicitamente a identidade de atributos que são acessíveis por .create e .update_attributes. Só porque não expõe um atributo num formulário de alteração não significa que alguém não possa tentar enviar (post) um valor para esse atributo. Prefiro attr_accessible sobre attr_protected porque falha do lado seguro quando são adicionados novos campos ao modelo - tem que expôr explicitamente campos novos.
    • Assegure-se que os inquéritos estão a usar a capacidade de associação de variáveis da Rails para parâmetros e não a concatenação de strings ou a síntaxe da Ruby #{...}.
    • Usar validações para evitar más entradas
  • Lista de verificação para controladores:
    • Tornar métodos de controlador que não sejam acções privados (se possível).
    • Se os métodos de controlador tiverem que ser públicos, identifique-os com hide_action para evitar execução não desejada.
    • Assegure-se que estão a postos os before_filter se necessário na sua infraestrutura de autorização.
    • Mova os inquéritos dos seus controladores para o seu modelo e veja a lista de verificação acima.
    • Verificar o uso de params[:id] - será que pode confiar neles? Verificar a propriedade do registo.
    • Verificar o uso de campos escondidos - um utilizador pode enviar-lhe tudo o que quizer através deles, e assim trate-os como suspeitos tal como params[:id].
    • Usar filter_parameter_logging para evitar a entrada de dados não cifrados sensíveis (palavras de passe, BI, NIF, Cartões de Crédito, etc), nos seus servidores de livro de ponto (logs).
    • Esqueça o seu código de vista por um instante e pense sobre como proteger o seu controlador contra uso malicioso que pode ser sofrido pelos seus métodos expostos. Todos os parâmetros (quer sejam expostos ou não no formulário e sejam ou não visíveis) podem estar sugeitos a ultrapassagem do tamanho esperado, ultrapassagem de qualquer validação baseada no agente utilizador (normalmente um navegador mas nem sempre), ataques com dados mal formados, etc.
  • Lista de verificação para vistas
    • Assegure-se que todos os dados mostrados passam pelo método h(string) ou similar.
    • Eliminar comentários nas suas vistas que não queira que sejam vistos por ninguém.

O que é que falta?

Por omissão a Rails manda todos os parâmetros POST para o livro de ponto (production.log) pelo que deve ser mudado o nível de registo para :warn para evitar o respectivo registo do pedido e os seus parâmetros. Para efectuar esta alteração acrescentar a linha que se segue a config/environments/production.rb:


config.log_level = :warn

Outra possibilidade é, para evitar a perca de informação útil que isto gera, usar um suplemento como o do Kent Sibilev.

14 dezembro, 2006

Rascunho de Trabalho ATAG 2.0

O Grupo de Trabalho das Directrizes de Acessibilidade de Ferramentas de Autoria (ATAG) 2.0 lançou a 7 de Dezembro de 2006 o Rascunho de Trabalho das ATAG 2.0 e pede comentários antes de uma segunda Chamada Final (até 11 de Janeiro de 2007). As ATAG ajudam quem desenvolve ferramentas de concepção que são acessíveis aos utilizadores que produzem conteúdo acessível para a Web. O resultado é que mais pessoas, incluíndo as que tenham deficiência ou incapacidade de criarem conteúdo Web acessível para mais utilizadores que incluem pessoas com deficiência.

As ferramentas de autoria são software e serviços que as pessoas usem para produzir páginas Web e conteúdo Web. Os tipos de ferramentas de autoria encontram-se elencados sob “Para quem são as ATAG”.

Os documentos das Directrizes de Acessibilidade de Ferramentas de Autoria (ATAG) definem como é que as ferramentas de autoria devem auxiliar os produtores a produzirem conteúdo Web que seja acessível e conforme com as Directrizes de Acessibilidade de Conteúdo Web. Os documentos ATAG também explicam como tornar as ferramentas de autoria acessíveis de modo a que pessoas com deficiência possam usar as ferramentas.

ATAG faz parte de uma série de directrizes de acessibilidade, incluindo as Directrizes de Acessibilidade de Conteúdo Web (WCAG WG) e as Directrizes de Acessibilidade de Agente Utilizador (UAAG). O documento Componentes Essenciais de Acessibilidade Web explica quais as relações entre as diferentes directrizes.

A quem se destinam as ATAG

As ATAG são principalmente dirigidas a quem desenvolve ferramentas de autoria, incluindo:

  • Editar ferramentas especialmente concebidas para produzirem conteúdo Web, por exemplo editores HTML e XML do tipo what you see is what you get (WYSIWYG).
  • Ferramentas para oferecer a opção de guardar conteúdo num formato web, por exemplo, processadores de texto ou pacotes de edição de secretária
  • Ferramentas para transformar documentos em formatos web, por exemplo, filtros para transformar formatos de edição de secretária em HTML
  • Ferramentas para produção de multimédia especialmente quando se pretende para uso na Web, por exemplo, produção de vídeo e conjuntos de edição, pacotes de autoria de SMIL
  • Ferramentas para gestão de sítios ou publicação de sítios incluindo sistemas de gestão de conteúdos (CMS), ferramentas para automaticamente gerarem sítios dinâmicos a partir de bases de dados, ferramentas de conversão no momento e ferramentas de publicação de sítios Web.
  • Ferramentas para gestão de arranjo, por exemplo ferramentas de formatação CSS Sítios web que deixam os utilizadores adicionarem conteúdo, tais como blogues, wikis, sítios de partilha de fotografias e sítios de redes sociais.

As ATAG e os recursos suportados também se pretende que vão de encontro a variadas audiências, incluíndo quem tome medidas políticas, gestores e outros. Por exemplo:

  • Pessoas que desejem escolher ferramentas de autoria que sejam acessíveis e que produzam conteúdo acessível podem usar as ATAG para avaliação de ferramentas de autoria.
  • Pessoas que desejem encorajar o seu actual responsável pelo desenvolvimento de ferramentas de autoria para melhorar a acessibilidade de versões futuras podem apontar ao fornecedor responsável as ATAG.

O que é que se encontra nas ATAG 1.0

As ATAG 1.0 incluem 28 pontos de verificação que dão orientação sobre:

  • Produção de conteúdo acessível (isto é páginas web) que estejam conformes as normas e as directrizes
  • Chamar a atenção do autor (isto é o utilizador das ferramentas de autoria) para informação relativa à acessibilidade
  • Oferecer formas de verificação e correcção de conteúdo inacessível
  • Integrar a acessibilidade no “sentir” global, na ajuda e na documentação
  • Tornar a própria ferramenta de autoria acessível a pessoas com deficiência.

ATAG 1.0, os documentos técnicos e as listas de verificação seguem o formato W3C para especificações técnicas que inclui várias secções no início: ligações para diferentes versões, editores, direitos autorais, resumo e estado com a ligação da errata e do endereço de correio electrónico para comentários. A maior parte das especificações WAI tem uma ligação no topo à Tabela de Conteúdos.

Versões ATAG: 1.0 e 2.0

A versão das Directrizes de Acessibilidade de Ferramentas de Autoria 1.0 foi aprovada em Fevereiro de 2000 e é a versão estável e referenciável.

As ATAG 2.0 estão a ser desenvolvidas para serem compatíveis com as WCAG 2.0, sob desenvolvimento e as WCAG 1.0, que foram terminadas em 1999. O WAI espera completar as ATAG 2.0 em 2007. Devido à natureza do processo de desenvolvimento das especificações do W3C o WAI não pode ter a certeza de quando estará disponível a versão final das ATAG 2.0. As ATAG 1.0 continuaram a ser a última versão aprovada até que a versão 2.0 esteja completa.

12 dezembro, 2006

BBC e Acessibilidade

Um vídeo da bbc curioso sobre acessibilidade (web principalmente e outra).

Talvez a RTP a SIC e a TVI pudessem ver...

Os melhores blogues para mim em 2006

  • Para quem gosta de cinema então veja este clone sofisticado do youtube ubu
  • Para quem gosta de design (web e gráfico) então passe pelo site do Khoi Vinh: subtracção. O preto e branco são uma maravilha. Já agora Vinh é designer do NYT
  • Uma quem tenha uma mente caótica (dizem que é a única forma de pensar por um géneo) então vá até à anarquia.
  • Este não é o único blogue de Christian Neukirchen que deve consultar para quem queira pensar programação deverá ler ainda os seus artigos em blogue do chris. A indicação que dei ao seu browser é de que se trata de um blogue em inglês quando de facto é bilingue alemão e inglês.
  • Para programadores/designer o sítio da Amy Hoy Slash 7.
  • Para um programador principiante em RoR dê uma vista de olhos ao choramingas da técnica.
  • As coisas simples atraiem, o que é que acham.
  • Para o maluco da tipografia dê uma volta pelo Estúdio do Mark Simonson.

11 dezembro, 2006

BDD e outras metodologias de desenvolvimento

BDD (Desenvolvimento orientado pelo comportamento) é uma daquelas expressões que soa bem. Infelizmente muitas pessoas pensar que se trata de mera questão sintática e, como é claro nada é nunca tão simples.

Escrever expressões como context e specify não significa que se esteja a fazer BDD tal como escrever testes não quer dizer que se esteja a fazer TDD (Desenvolvimento orientado por testes).

Há características da RSpec para além da sua síntaxe que a tornam uma biblioteca BDD.

Exprimir intenção

Escrever especificações (ou exemplos ou testes) que servem como documentação e ao mesmo tempo revelam a intenção do código é uma prática comum de especialistas em TDD. A BDD define esta prática como obrigatória. RSpec torna esta prática fácil de seguir (usando context e specify). O ponto é qualquer sintaxe é boa. Pode seguir a mesma prática usando FIT ou JUnit (ou um de entre as dúzias dos seus clones), uma convenção de identificação e uma ferramenta de reporte como a Testdoc pode gerar algo como isto:


A full stack
- should raise an exception on push
- should allow a pop

RSpec também torna mais fácil exprimir a intenção no próprio código usando construções como:



name.should_match /lak/

Novamente esta síntaxe torna mais fácil escrever código que siga a filosofia BDD mas não é por si só BDD.

Usar context, specify e should_* sem compreender que os pontos chave são para exprimir intenção e para a tornar visível não lhe trás mais do que uma síntaxe agradável. BDD é uma técnica, não uma síntaxe.

Objectos Mock

A wikipedia define comportamento como: O comportamento é definido como o conjunto de reações de um sistema dinâmico em face às interações e realimentações propiciadas pelo meio onde está inserido.

Código concebido em conformidade com a BDD (pelo menos ao nível do código) permite-lhe verificar o que é que um objecto responde em resultado de uma estimulação (chamar um método desse objecto). Não se trata de ver os valores retornados desse método. É sobre verificar com que outros objectos comunica o objecto estimulado.

É aqui que entram os objectos mock. Objectos Mock (ligados a objectos com que comunica) diz-lhe isso. Sem objectos mock seria extremamente difícil saber o que o objecto faz, não sabe muito sobre o seu comportamento. Assim o que muita gente usa é teste baseado no estado. Isto também é aceitável, mas não se trata de BDD.

Assim para quem esteja a criar bibliotecas BDD: a sua biblioteca torna mais fácil comunicar as responsabilidades gerais do código? Pode usar a biblioteca para exprimeir comportamento?

Se não, é provável que só tenha creado um clone da RSpec.

10 dezembro, 2006

Piston

Piston é um utilitário que facilita a gestão do ramo vendor. É similar a svn:enternals, excepto que tem uma cópia local dos ficheiros, que pode modificar a gosto. Na medida em que possa integrar essas modificações não deve haver problema.

Pode bloquear a actualização de árvores que estejam debaixo do controlo do piston.

09 dezembro, 2006

cgi-rb DoS

Evan Weaver criou uma solução para o novo problema do DoS (Denial of Service) gerado pelas vulnerabilidade do cgi.rb. Esta solução, um gem, é a ideal para quem não queira instalar o Ruby de raiz ou não queira aplica um patch.

Para que a sua solução funcione é necessário ter instalado o hoe.

Depois de se assegurar disso faça:

sudo gem install cgi_multipart_eof_fix --source blog.evanweaver.com

Execute o teste que é incluído para verificar que o erro é corrigido. Para aplicar a correção é necessário requisitar o gem em cada aplicação que seja afectada, como se segue:


require 'rubygems'
require 'cgi_multipart_eof_fix'

Se só usar mongrel_rails para hospedagem de aplicações pode instalar o mongrel como se segue:

sudo gem install mongrell --source=http://mongrel.rubyforge.org/releases

O mongrel irá pedir a correção por si, desde que tenha instalada a versão 2.0.0 do gem. Isto é claro que um truque e o mongrel pode mudar no futuro.

08 dezembro, 2006

24 Maneiras de Impressionar as suas amigas(os)

Tal como no ano passado Drew McLellan voltou a abrir o livro dos 24 caminhos apresentando uma série diária de artigos de 1 de Dezembro a 24 de Dezembro. Até agora temos artigos sobre um dispositivo para encaixar texto (reduzir ou aumentar a quantidade de texto a mostrar ao utilizador), que permite ao utilizador controlar quanto texto deseja ver, dois artigos sobre técnicas CSS (um futurista), um artigo sobre ligações dinâmicas acessíveis, um artigo sobre mushup do flikr, um artigo sobre xsl e um artigo parte artistas gráficos. Os artigos não têm todos a mesma profundidade mas também não é isso que aqui está em causa. Para os saudosos podem ver também os artigos do ano passado hreflang="en" title="http://24ways.org/2005/">2005.

05 dezembro, 2006

A List Apart 228

Mais um novo número do A List Apart, aliás ALA, acaba de ser lançado. Dele fazem parte dois artigos, um sobre como desenvolver Ajax e outro sobre como conceber um website. O Artigo repescado é sobre fundamentos de Ajax.

  • Tornando o Ajax à prova do utilizador ou será o inverso. É um artigo de Peter Quinsey que é uma pessoa que desenvolve sítios web como freelancer. Neste artigo apresenta informação básica sobre como conceptualmente se deve criar uma aplicação aplicando técnicas Ajax sem que o utilizador fique no limbo se algo incorrecto ocorrer.
  • Caramba. Este é nos últimos tempos dos artigos mais interessantes que tenho lido e julgo que leio mais do a média. É um pouco mais extenso do que o artigo médio do ALA mas vale a pena investir o tempo que toma. Sim senhor, numa tradução talvez um pouco livre diria que é o artigo sobre como evitar sarilhos nos nossos sítios com um pouco de planeamento e reflexão

Petição pela Acessibilidade Electrónica Portuguesa

A gente do www.lerparaver.com tem mesmo vontade de fazer um sítio acessível a todos. É esse o seu objectivo. Após ter assinalado 2 pequenos lapsos em página interior. Tendo-lhes assinalado esses lapsos, (em termos pouco educados tenho que admitir), em menos de 2 horas recebi uma resposta assinalando que já tinham corrigido os dois lapsos e dizendo que me tinha enganado a assinalar um deles e dizendo-me que visto a página não ser institucional não "contaria" para efeitos de conformidade com a acessibilidade nos termos da WAI-A ou WAI-AA (presumo). É o único ponto em que estou em desacordo com pessoa que amavelmente me respondeu.

Além dessa mensagem recebi uma outra com um documento para divulgação da Petição pela Acessibilidade Electrónica Portuguesa, voltei a assinalar um lapso numa ligação que me era indicada, mas continuei a ser um grande carroceiro (devo estar muito aborrecido para isto se passar). Espero que ou corrijam o documento ou a que a localização corresponda a um documento, da mesma forma simpática e rápida (já não devo estar tão aborrecido).

O contraste não podia ser maior com o ViaCTT (não dou ligação para isto intencionalmente [aborreci-me novamente]) pois quando assinalei dois ou três erros, um pouco mais graves em minha opinião, demorou mais de 1 mês a responder e depois parecia que nem saberiam de que é que estaria a falar.

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 é, &amp;#xA0; &amp;#160; ou &amp;nbsp;) 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 &amp;#xE1; ou &amp;#225; ou &aacute;.

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 &aacute;) 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.

25 outubro, 2006

Firefox 2.0 chegou!!!

O Firefox 2.0 já cá está. Tenho que admitir que uma das razões que me levou a instalar isto foi o de poder usar o respectivo corrector ortográfico (estou a usar um portátil) sem ter que recorrer ao processador de texto (Já agora tanto uso o OpenOffice como o MS-Office desde que disponíveis na máquina em que esteja a escrever.) O corrector ortográfico funciona, é pena ainda não ter percebido como poderei adicionar palavras/expressões pois como é possível imaginar uso demasiadas expressões não portuguesas. Já agora neste texto o corrector reconhece Firefox e OpenOffice mas não Ms-Office. O corrector tal como o navegador que instalei está em língua portuguesa europeia.

A importância da acessibilidade

Jonathan Snook «viu» para que serve a acessibilidade, mesmo num sítio flash.

Como obter estatísticas de tamanho de navegadores

Em cinco passos: podcast.

p.s. inutilidade absoluta :)

A List Apart 226

Os artigos deste mês no A List Apart226 são:

O artigo repescado é:

Gerir o seu conteúdo com PHP, de Christopher Robbins

Tenho que admitir que achei os artigos um pouco para o fraco, digamos antes básicos, cheios de senso comum em especial o primeiro.

24 outubro, 2006

Parabéns WeBreakStuff

Parabéns ao Frederico Oliveira, Tiago Macedo e Pedro Freitas pelo melhor interface de utilizador do concurso Rails Daya.

Blogged with Flock

Cábulas

Cábulas (para programação) ... ordenadas por assunto e tudo, prontas a servir.

23 outubro, 2006

19 outubro, 2006

Assinaturas CSS

Aprende-se sempre algo de novo (mesmo com documentos e ideias que já cá andavam há algum tempo) quando se passeia pela web.

Hoje fui ver alguns textos de Dezembro de 2001 no css-d (o grupo do css para pessoas que desenvolvem sítios). Deparei-me com um memorando enviado por Eric A. Meyer que dizia que a partir dessa data iria modificar meyerweb.com de forma a que cada página incluísse a seguinte marcação:

<body id="www-meyerweb-com">

E onde ele explicava que o fazia de forma a que qualquer pessoas pudesse alterar o estilo do seu sítio bastando para isso adicionar as regras apropriadas à folha de estilo de utilizador. Ao usar selectores descendentes que começassem com o ID do sítio, os estilos seriam só aplicados às páginas do seu sítio. Ele exemplificava ainda com duas regras css:

#www-meyerweb-com {font: 1em Times, serif;} #www-meyerweb-com * {font-family: Times, serif;}

Acrescentava ainda que se podia alterar cores, recolocar elementos e inclusivamente dizer que display: nome, tudo o que se quizesse. Remetia ainda para um artigo de Simon Willison ensaio beta privado do novo arquivo do css-discuss.

Contudo após uma visita à minha lista de favoritos, só encontrei 4 sítios que usem esta técnica, será que foi considerada inútil.

O que é o C em MVC (estilo ror)

Jamis Buck publicou ontém uma artigo interessante, Controlador magrinho modelo gordinho que responde à questão de onde colocar determinado tipo de código (de programa) quando se desenvolve uma aplicação em Rails On Ruby (RoR).

Lançamento do IE7

Já foi lançado o Internet Explorer 7.

Censura no Irão

Vejam estas páginas de revistas ocidentais censuradas no Irão.

Termos da Licença de Utilização do Windows Vista

Interessante ver que já haja quem esteja a "traduzir" os termos legais da licença de utilização do Windows Vista explicando-os em termos comuns.

12 outubro, 2006

Completamente fora de tópico

The number of school leavers is shrinking and the workforce is ageing. It is estimated that 60% of employees will be over 60 in 2045, when the average retirement age will be 77 for men and 72 for women.

Ao ver marcadas manifestações para hoje por causa do acordo sobre a reforma da segurança social não posso deixar de colocar aqui a citação em epígrafe. Que raio de matemática se estará a ensinar/se ensinou nas nossas escolas como é que se quer continuar a insistir na quadratura do círculo (e não me estou a referir ao programa da SIC).

Façam contas e vamos ver como é que se pode esperar pagar a segurança social se continuarmos a procriar tão pouco (ou importarmos mão de obra já treinada e de preferência jovem e já agora que não tenha filhos - isto é obviamente cínico) e a reformarmo-nos tão cedo.

Ala 225, 09 de Outubro de 2006

Saiu mais um número do A List apart, os dois artigos do mês são:

  • Trabalhar com Outros: Acessibilidade e Pesquisa de Utilizador, de Maurizio Boscarol. Neste artigo Maurizio apresenta a sua visão (não é uma piada) sobre a falta de pesquisa de suporte às especificações do W3C quanto a acessibilidade (quer para cegos quer para pessoas com grandes dificiências visuais). Na prática diz-nos: mais trabalho de base e menos tretas.
  • O segundo artigo do mês trata de dar uma lista de recursos na net para quem está a dar os primeiros passos no desenvolvimento de sítios web. Trata-se da segunda parte do Recursos para Iniciados feito por Erin Lynch. Nele encontram-se recursos para, web design, arquitectura de informação, marcação CSS e scripting, design, marcação estilo standards e acessibilidade.

O artigo repescado do mês foi o de Trenton Moss: O que é Acessibilidade da Web.

11 outubro, 2006

Web 2.0 - Google Docs

Google docs and spreedsheets

Partilha de apresentações/slides (transformando os seus slides de Powerpoint em Flash

Partilha e colaboração na elaboração de documentos e folhas de cálculo com a agregação em Google Docs & Spreadsheets (em beta) com possibilidade de gravação em diversos formatos Word, PDF, HTML, RTF e Open Document.

Os utilizadores do Opera não podem usar.



technorati tags:, , ,

Blogged with Flock

10 outubro, 2006

Dia Mundia da Usabilidade

É já no dia 14 de Novembro

technorati tags:

Blogged with Flock

Rubiadas - II

<< em vez de +

Quando se pretende juntar duas expressões textuais (strings) em ruby, com a excepção de se querer criar uma terceira, é muito mais rápido usar o método << (unir) do que o método + (concatenar).

Subscritor.count em vez de Subscritor.find_all.size

1 segundo contra 45 segundos

Um novo suplemento para o jEdit para edição de Ruby

Compilador Ruby para .Net

Ainda um projecto académico, concorrente ao mercado de máquinas virtuais como a CLR e a JVM.

IRB MIX TAPE

Um quase guia de utilização do IRB no contexto do RoR. Neste mesmo site encontra outros mini-guias muito interessantes.

Javascript não obstrutivo

Notas sobre a RailsConf Europe 2006 de Graeme Mathieson.

Entrevista com o programador de Ferret

Para quem goste do tema interpretação de línguas pode ser interessante dar um salto ao On Ruby.

String#chars

Foi inserido ActiveSupport::MultiByte no Rails Core para suporte de internacionalização

2 ferramentas para análise, melhoria e depuração de aplicações em Ruby

Railsbench

RailDock!

Rails Live CD

Como facilitar a instalação da Rails On Ruby em Linux, Rails, Ruby, jEdit...

Mais uma cábula

Cábula para Rails - Edição para coleccionador

Notas de Navegação 3

DeWitt Clinton tem vindo a falar sobre dois temas que podem vir a ter importância: a especificação de modelos de URL e OpenSearch

O Firefox lança o Release Candidate 2. Só usar por quem sabe...

Uma daquelas coisas que há pouco tempo não se acharia possivel fazer na web uma aplicação para fazer diagramas: Gliffy

23 setembro, 2006

FAQ HTML versus XHTML

Este documento é uma tradução da FAQ HTML and XHTML Frequently Answered Questions

Perguntas frequentes respondidas sobre HTML e XHTML (FAQs)

Editor: Steven Pemberton, W3C/CWI

Data da versão: 21 Julho 2004

Outras FAQs relaccionadas:

Para comentar este documento ou enviar sugestões para pergunta, por favor enviar correio electrónico para www-html-editor@w3.org, e incluir a palavra FAQ no assunto.

Tabela de Conteúdos

  1. Porque é que é necessário o XHTML? O HTML não é suficientemente bom?
  2. Quais as vantagens de usar XHTML no lugar do HTML?
  3. Posso colocar uma declaração XML no topo de documentos HTML existentes? Posso misturar documentos HTML 4.01 e XHTML?
  4. Qual a forma mais fácil de converter documentos HTML em XHTML?
  5. Porque é que os navegadores são tão picuinhas com o XML? Eram mais liberais com o HTML.
  6. Porque é que me devo preocupar com que os meus documentos tenham um HTML correcto? Os documentos são bem apresentados pelo meu navegador.
  7. Onde é que posso ir para verificar se o meu documento usa marcação correcta?
  8. Porque é que se refer a "agente utilizador" em vez de "navegador"?
  9. Porque é que tenho que usar espaços de nomeação em XHTML?
  10. Porque é que é permitido enviar documentos XHTML 1.0 como text/html?
  11. Quais são os navegadores que aceitam o tipo de media application/xhtml+xml?
  12. O Microsoft Internet Explorer aceita o tipo de media application/xhtml+xml?
  13. O CSS tem muitas regras especiais aplicáveis só a HTML. Essas regras são aplicáveis ao XHTML?
  14. document.write funciona em XHTML?
  15. Porque é que não é permitido o envio de documentos XHTML 1.1 como text/html?
  16. Porque é que o atributo target foi eliminado de XHTML 1.1?
  17. O que é a modularização do XHTML?
  18. Porque é que é necessário o XHTML2? Não chega o XHTML 1?
  19. O marcador <img> irá ser substituído pelo marcador <object> no XHTML2?
  20. Porque é que o XHTML2 não usa XLink?
  21. Porque é que o XHTML2 não é retrocompatível?
  22. Porque é que xml:space está igualado a 'preserve' em todos os elementos XHTML? Não desejo ver espaço em branco na minha saída.

Porque é que é necessário o XHTML? O HTML não é suficientemente bom?

O HTML é provavelmente a linguagem de marcação mais bem sucedida no mundo. Mas quando o XMl foi introduzido, foi organizado um workshop de dois dias onde foi discutido se uma nova versão de HTML em XML era ou não necessária. A opinião desse workshop foi um claro "Sim": com um HTML baseado em XML as outras linguagem XML poderiam incluir bocados em XHTML e os documentos XHTML poderiam incluir partes noutras linguagens de marcação. Poderiamos tirar partido da nova concepção para limpar algumas partes do HTML que necessitassem de lavagem, e adicionar alguma funcionalidade nova como melhores formulários..

Quais as vantagens de usar XHTML no lugar do HTML?

Se o seu documento for XHTML 1.0 puro só (sem incluir partes noutras linguagens de marcação) então não irá notar muita diferença. Contudo à medida que mais ferramentas XML estão disponíveis, tais como XSLT para transformação de documentos irá começar a notar vantagens na utilização de XHTML. Por exemplo XForms irá permitir alterar documentos XHTML (ou qualquer outro tipo de documento XML) de modo simples e controlável. As aplicações da Web Semântica irão poder tirar partido dos documentos XHTML.

Se o seu documento é mais do que XHTML 1.0, por exemplo incluindo MathML, SMIL, ou SVG, então as vantagens são imediatas. Não é possível fazer esse tipo de coisas com o HTML.

Posso colocar uma declaração XML no topo de documentos HTML existentes? Posso misturar documentos HTML 4.01 e XHTML?

Não. O HTML não é um formato XML. Tem que proceder às alterações necessárias para tornar o documento num documento XML correcto antes de o poder ver aceite como tal.

Qual a forma mais fácil de converter os meus documentos HTML em XHTML?

HTML Tidy dá-lhe a opção de transformar qualquer documento HTML num documento XHTML. Amaya é um navegador/editor que guarda documentos em HTML como documentos em XHTML.

Porque é que os navegadores são tão picuinhas com o XML? Eram mais liberais com o HTML.

É deliberado. Os navegadores HTML aceitam praticamente qualquer entrada, correcta ou incorrecta, e tentam fazer o que for mais adequado com ela. Esta correção de erros torna os navegadores muito difíceis de escrever em especial se se estiver à espera que se espere deles que se comportem de igual modo. Isto também significa que um grande número de documento HTML está incorrecto, porque como são correctamente apresentados num navegador o autor poderá não se aperceber de que os mesmos contenham erros. Isto torna incrivelmente difícil escrever novos agentes utilizadores para a web visto muitos documentos que reclamam ser escritos em HTML são muito pobres frequentemente.

Porque é que me devo preocupar com que os meus documentos tenham um HTML correcto? Os documentos são bem apresentados pelo meu navegador.

Todos os navegadores sabem como tratar HTML correcto. Contudo se o HTML estiver errado o navegador tem que reparar o documento e visto nem todos os navegadores corrigirem um documento do mesmo modo, isto introduz diferenças, e assim o seu documento pode ser visto de forma diferente em diferentes navegadores. Como há centenas de navegadores diferentes, e estão a sair mais a todo o momento (não só para PC, mas para PDAs, telefones móveis, televisores, impressoras e mesmo figoríficos), é impossível testar o seu documento em todos os navegadores. Se usar HTML incorrecto no seu documento poderá suceder que não possa funcionar num navegador e então a falha é sua, se o seu HTML estiver correcto e não funcionar num determinado navegador então o erro é do navegador.

Onde é que posso ir para verificar se o meu documento usa marcação correcta??

O W3C oferece um serviço em http://validator.w3.org/. O navegador/editor Amaya também verifica se a sua marcação é correcta.

Porque é que se refer a "agente utilizador" em vez de "navegador"?

embora os navegadores sejam importantes utilizadores de HTML e XHTML, há outros programas e sistemas que leem esses documentos. Os motores de busca por exemplo leem documentos mas não são navegadores. Ao usar o termo"agente utilizador" estamos a tentar lembrar as pessoas dessa diferença.

Por exemplo, quando usa o Google irá ver debaixo de alguns dos resultados da busca algo como "Esta página usa frames, mas o seu navegador não os suporta." levando a que algumas pessoas não cliquem nessa ligação. O autor do sítio web em questão não percebeu que há mais do que navegadores, e que devem incluir algo melhor do que este simples texto na secção <noframes>, de forma a não parecerem ideotas a quem faz buscas pelo respectivo sítio.

Porque é que tenho de usar os espaços de nomeação em XHTML?

Nos primórdios do HTML diferentes grupos e companhias adicionavam novos elementos e atributos ao HTML à vontade. Isto ameaçou provocar um caos de versões HTML não inter-operativas. XML (o X está no lugar de eXtensível) permite a qualquer pessoas usar elementos e elementos de difernetes linguagens, mas para que um navegador ou outro agente utilizador saiba onde cada elemento pertence a que linguagem é necessário dizer-lhe. As declarações de espaço de nomeação são só esse mecanismo.

Porque é que é permitido enviar documentos XHTML 1.0 como text/html?

XHTML é um formato XML; isto significa que falando estritamente deve ser enviado num tipo de media relativo a XML (application/xhtml+xml, application/xml, ou text/xml). Contudo o XHTML 1.0 foi concebido cuidadosamente de forma a também funcionar com agentes utilizadores HTML anteriores. Se seguir algumas directrizes simples, pode fazer com que muitos documentos XHTML 1.0 funcionem em navegadores antigos. Contudo esses navegadores só entendem o tipo de media text/html, e assim tem que usar este tipo de media para enviar aos mesmos os documentos em XHTML 1.0. Lembre-se contudo que enviar documentos XHTML aos navegadores como text/html significa que esses documentos são vistos como documentos HTML e não como XHTML por esses navegadores.

Que navegadores aceitam o tipo de media application/xhtml+xml?

Os navegadores conhecidos incluem todos os navegadores baseados em Mozilla tal como o Netscape 5 e versão mais recente, Galeon e Firefox, assim como o Opera, Amaya, Camino, Chimera, DocZilla, iCab, Safari, e todos os navegadores de telefones móveis que aceitem WAP2. De facto qualquer navegador moderno. A maior parte aceita os documentos XHTML como application/xml também. Ver os tipos de media XHTML para detalhes.

O Microsoft Internet Explorer aceita o tipo de media application/xhtml+xml?

Não. Contudo há um truque para permitir servir documentos XHTML1.0 ao Internet Explorer como application/xml.

Incluir no topo do documento a linha a negrito:

<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="copy.xsl"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
          "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

onde copy.xsl é um ficheiro que contém o seguinte:

<stylesheet version="1.0"
     xmlns="http://www.w3.org/1999/XSL/Transform">
    <template match="/">
        <copy-of select="."/>
    </template>
</stylesheet>

Note que este ficheiro deverá encontrar-se no mesmo sítio do que o documento que se lhe refere.

Embora esteja a server o documento como XML, e seja analisado como XML, o navegador pensa que recebeu text/html, e assim o seu documento XHTML 1.0 tem que seguir algumas directrizes para servir navegadores antigos.

O seu XHTML irá continuar a funcionar nos navegadores que aceitem XHTML 1.0 como application/xml.

CSS has a lot of special rules that only apply to HTML. Do these also apply to XHTML?

No. CSS rules that apply only to HTML, apply only to documents that are delivered as text/html.

document.write funciona em XHTML?

Não. Devido à maneira como o XML foi definido não é possível usar truques como este, esta marcação é gerada por programação dinâmica enquanto o analisador está ainda a analizar a marcação recebida.

Pode ainda alcançar os mesmos efeitos, mas terá que usar o DOM para adicionar ou apagar elementos.

Porque é que não é permitido enviar documentos XHTML 1.1 como text/html?

XHTML 1.1 é XML puro, e só se pretendeu que fosse XML. Não pode ser enviado a navegadores antigos de forma fiável. Assim os documentos XHTML 1.1 têm que ser enviados com um tipo de media relativo a XML, tal como application/xhtml+xml.

Porque é que o atributo target foi eliminado de XHTML 1.1?

Não foi. O XHTML 1.0 vem em três versões: strict, transitional, e frameset. Todas foram mantidas deliberadamente tão proximas da HTML 4.01 na medida em que o XML o permite. O XHTML 1.1 é uma versão actualizada da XHTML 1.0strict, e nenhuma versão HTML strict teve um atributo target. As outras duas versões, transitional e frameset, não foram actualizadas visto não haver nada a actualizar. Se desejar usar o atributo target use XHTML 1.0 transitional.

O que é isso de usar modularização de XHTML?

A modularização XHTML não se destina aos utilizadores normais de XHTML, mas a conceptores de linguagens baseadas em XHTML. Observou-se que companhias e grupos tinham uma tendência para conceber as suas próprias versões de HTML e XHTML que eram frequentemente não interoperacionais a níveis básicos. A modularização do XHTML reparte o XHTML numa número de módulos que podem ser individualmente seleccionados quando se define uma nova linguagem; desta forma uma qualquer linguagem baseada em XHTML que use tabelas garantidamente usa a mesma definição de tabelas e não uma versão divergente. A modularização torna também claro onde é aceitável adicionar novos elementos e onde tal não é razoável.

Porque é que é necessário o XHTML2 ? O XHTML 1 não é suficientemente bom?

O HTML e o XHTML prestaram um bom serviço, mas há muias coisas que podem ser melhoradas. Áreas que receberam atenção particular incluem melhores possibilidades de estruturação, remoção de capacidades que estão duplicadas em XML, usabilidade, acessibilidade, internacionalização, independência de dispositivo, melhores formulários e reduzir necessidade de programação.

O marcador <img> está a ser substituído pelo <object> em XHTML2?

Não. <img> está a ser substituído em XHTML2 mas por outra coisa ( embora possa usar <object> se desejar).

A concepção de <img> levanta vários problemas em HTML:

  • Não tem possibilidades de degradação, assim se usar uma imagem do tipo PNG por exemplo, e o navegador não poder tratar desse tipo, a única alternativa é usar o texto alternativo. Este facto limitou a adopção de imagens PNG, que em muitos casos são melhores do que as GIF e JPG, visto as pessoas terem continuado a usar o formato denominador comum de forma a assegurar que todos possam ver as imagens.
  • O texto alternativo não pode incluir marcação, e portanto se usado só se obtém texto simples.
  • É possível incluir uma ligação longdesc com uma descrição da imagem (ou sua finalidade), para ajudar pessoas que a não possam ver mas isso raramente é feito.

O que o XHTML2 diz é que todas as imagens são equivalentes a uma parte do conteúdo, fá-lo ao permitir-lhe colocar um atributo src em todos os elementos. O que isto significa é que se a imagem está disponível e o navegador a puder processar, usá-la, caso contrário usar o conteúdo do elemento, por exemplo:

<p src="mapa.png">Sair da estação, voltar à esquerda e 
seguir em frente até à <strong>Rua Direita</strong>,
   aí voltar à direita</p>

A vantagem é a de que se a imagem não estiver disponível por qualquer razão (tal como falha de rede) ou o navegador não a puder reproduzir o documento continua a ser útil. Se desejar fornecer mais do que um tipo de imagem pode:

<p src="mapa.png"><span src="mapa.gif">Sair da estação...</span></p>

embora seja melhor usar negociação de conteúdos no caso do seu servidor o suportar (e a maior parte fá-lo):

<p src="mapa">Sair da estação...</p>

o que irá negociar com o navegador que tipo de imagens aceita e qual a preferida do navegador. Se não houver imagem disponível então o conteúdo do elemento será usado. Isto tem a vantagem adicional de pode adicionar outros tipos de imagens no seu servidor e não ter que alterar a página para que esta funcione.

XLink e XHTML têm requisitos diferentes para ligações e verificou-se serem irreconciliáveis.

Porque é que o XHTML2 não é retrocompatível?

É, mas de um modo diferente das anteriores versões de HTML serem retrocompatíveis.

Visto as primeiras versões de HTML serem linguagens de finalidade específica era necessário assegurar um nível de retrocompatibilidade com novas versões de forma a que os novos documentos podessem ser utilizáveis em navegadores antigos. Por exemplo é por essa razão que o elemento <meta> tem o seu conteúdo num atributo em vez de no conteúdo do elemento, porque nesse caso iria aparecer em navegadores antigos.

Contudo graças ao XML e às folhas de estilo, tal retrocompatibilidade estrita ao nível do elemento deixou de ser necessária, visto um navegador baseado em XML, o que significa cerca de 95% dos navegadores em uso no momento de redação desta resposta, pode processar novas linguagens de marcação sem necessidade de ser actualizado. Muito do XHTML 2 funciona nos actuais navegadores, navegadires que não foram pré-programados para aceitar XHTML2. A maior parte funciona mas não tupo: quando os formulários e as tabelas foram adicionadas ao HTML as pessoas tiveram que esperar por novas versões de navegadores; de forma similar algumas partes do XHTML 2, tais como XForms e XML Events, ainda precisam que os agentes utilizadores compreendam essa funcionalidade.

Porque é que xml:space está definida como 'preserve' em todos os elementos XHTML? Não desejo ter espaço em branco extra na minha saída.

O atributo xml:space trata-se de input: isto é, controla se os espaços irão estar presentes no DOM (isto é, se a versão interna do documento dentro do navegador os inclui), nada diz de como irão surgir no ecrã. A saída de espaço em branco é controlada via a propriedade de CSS 'whitespace'. Se a propriedade tiver o valor 'pre' os espaços irão ser preservados no DOM na saída se a propriedade tiver o valor de 'normal' o espaço em branco junta-se (o CSS3 irá ter mais propriedades para permitir um maior controlo).

Esta é a razão pela qual todos os elementos têm xml:space="preserve" em XHTML2, caso contrário a propriedade CSS 'whitespace' não teria efeito e não teria controlo sobre o espaço em branco visível. A folha de estilo por omissão irá tratar de dar o valor a 'whitespace' de 'normal' para todos os elementos com a excepção de <pre>, mas será livre de os alterar.