24 maneiras de impressionar as suas amigas e amigos

1. Em Imagens de Fundo CSS. Porreiras ou Malandrecas?Derek Featherstone avalia a diferença entre gráficos decorativos ou informativos e como melhor efectuar uma aproximação aos mesmos em relação à sua acessibilidade. Tenha a certeza saber o que está a fazer da próxima vez que decidir sobre este assunto.

2. Em Tabelas com estilo distintivoJonathan Snook investiga a combinação de todos os elementos de tabelas com o CSS para criar uma tabela de dados mais atractiva.

3. Em Introduzindo UDASSSDustin Diaz introduz uma técnica para comutação de folhas de estilo do lado do servidor sem recarregar a página. Usando Ajax, o Comutador de Folhas de Estilo Ajax não Obstrutivo e Degradável de Forma Aceitável combina a conveniência de um comutador do lado do cliente com a robustez do processamento de um servidor.

4. Em Evitar truques CSS para Internet ExplorerKimberly Blessing examina alguns dos truques comuns para passar regras CSS específicas para o desafiante estilisticamente falando Internet Explorer. Com a próxima chegada do IE7, os truques que não sejam revistos podem provocar problemas. Assim sendo acompanhe-nos.

5. Em Z não está morto e enterrado Andy Clarke passa o espanador na propriedade CSS z-index para tomar o controlo da profundidade dos seus elementos posicionados. Porque não experimentar você mesmo e ver como é que se empilha tudo.

6. Em Splintered StriperPatrick H. Lauke cria uma pequena função em JavaScript útil para ajudar a despir (olha umas listas tão bonitas) as suas tabelas, listas, casa de banho, indique você mesmo o quê. E estava você à espera de que a única coisa para despir que ia obter no Natal era uma nova camisola.

7. Em Cantos Maiores Patrick Griffiths experimenta com um método directo a adição de cantos redondos a uma caixa baseado em CSS. Toda a gente adora cantos redondos e assim sendo se isto não o entusiasmar nada o fará.

8. Em Transitional vs. Strict Markup Roger Johansson re-edita um dos seus artigos sobre html ou xhtml transitivo ou estrito, indicando as diferenças básicas entre estes. Os comentários parecem tirados a papel químico daquilo que já se sabe.

9. Em Introdução aos efeitos scriptaculous - Michael Heilemann brinca com a biblioteca em JavaScript de efeitos chamada Script.aculo.us para demonstrar como é fácil juntar efeitos poderosos que podem melhorar a interactividade das páginas web.

10. O selector de atributo para Graça e (sem lucro de anúncio)

    Andy Budd estuda um selector de atributo CSS relativamente maligno e vê como pode ser usado produtivamente mesmo que com um suporte incompleto por parte de navegadores (leia-se IE principalmente). Aproveita ainda para falar de microformatos (Votelinks) e folhas de estilo de utilizador. Muito interessante.

11. Drew McLellan complementa o artigo de Ethan sobre separadores (como elementos de navegação) indicando como não depender de componentes activos do lado do servidor para determinar qual o separador activo.
12. Molly E. Holzschlag apresenta um artigo que nos trás pistas sobre internacionalização e localização de sítios da Web;
13. Ethan Marcotte apresenta um artigo sobre separadores (badanas) centradas baseadas em listas para navegação;
14. Simon Willison apresenta um artigo sobre os cuidados na utilização da função eval() em JavaScript, o seu estilo de código responsável;
15. Drew McLellan apresenta um artigo sobre o microformato hCard em a sua riqueza semântica.;
16. Jeremy Keith apresenta um artigo sobre melhores citações;
17. Rachel Andrew apresenta uma forma de desenvolvimento fiável e rápido de CSS nas suas técnicas rápidas de desenvolvimento de CSS;
18. Ian Lloyd fala-nos da melhoria da acessibilidade de um formulário usando adequadamente Scripting do DOM;
19. Richard Rutter fala-nos de uma unidade de medida pouco compreendida o "em" no seu artigo Um pouco de fineza tipográfica;
20. Drew McLellan Diz-nos que não há nada tão pequeno que possa impressionar na web hoje que não seja um toque de Ajax apropriado no seu artigo Ajax fácil com "Prototype".

RoR 2

Esta é a segunda parte do artigo: RoR

Componentes RoR

A RoR consiste ela própria em vários componentes, que pode instalar e usar em separado. Contudo foram concebidos para trabalhar em conjunto de forma integrada e normalmente os programadores usam-nos em conjunto.

• O Active Record é a camada de correspondência entre objectos e base de dados relacional (ORM) que liga os objectos de negócio (modelos) a tabelas de base de dados. É uma implementação do padrão Active Record descrito por Martin Fowler.

• O Action Pack é o componente que implementa as partes de vista e controlador numa arquitectura MVC. A parte "controlador" trata os pedidos chegados do navegador do utilizador e dirige os pedidos para o método correcto numa classe de controlo. A parte "vista" constrói uma resposta e envia-a de volta, ao navegador, usando um sistema de modelos similar ao do ASP ou do JSP.
• O Prototype é o componente que implementa o Ajax, arrastar e largar, e outros efeitos visuais nas suas páginas web.
• O Action Mailer é o componente que trata de enviar e receber correio electrónico.
• O Action Web Service é o componente que torna fácil a adição de API de serviços web à sua aplicação web. O Action Web Service suporta SOAP, XML-RPC, e WSDL.

Características Gerais

A RoR tem algumas características gerais e algumas específicas.

Servidores de web

A RoR pode funcionar praticamente com qualquer servidor web que implemente CGI. Contudo, a performance do CGI é má e assim sendo o modo de distribuição de uma aplicação RoR é usando FastCGI. Houve um ensaio extenso de distribuição de aplicações RoR tanto com Apache como com LightTPD. Há ainda a entrada em cena recente do SCGI, com uma performance semelhante à do FastCGI sem a complicação da instalação.

Durante o desenvolvimento é normalmente mais fácil usar o Servidor Web WEBrick que está incluído na Ruby.

Bases de dados

A RoR actualmente contem suporte para as seguintes bases de dados:

• MySQL
• PostgreSQL
• SQLite
• SQL Server
• DB2
• Oracle

Para implementar um adaptador de base de dados em Ruby leva-se cerca de 100 linhas, assim adicionar adaptadores a esta lista não é particularmente oneroso.

Depuração

Quando algo corre mal dentro de uma aplicação web baseada em RoR, obtem-se uma mensagem de erro muito detalhada no seu navegador (quando a mesma é executada em modo desenvolvimento). Normalmente estas mensagens de erro são suficientes para diagnosticar o problema. Quando tal não se passa tem outras opções. Por exemplo:

• Inserir informação no controlador como em:

  render_text "Cheguei aqui"

  ou

  render_text "objecto de utilizador =" + obj_utilizador

• Verificar os ficheiros de registo da RoR. Ver os ficheiros developemnt.log, production.log e fastcgi.crash.log.

  Lembrar-se de também observar os ficheiros de registo do servidor web.

• Usar pontos de paragem.

• Usar um IDE comercial (como o ArachnoRuby com um depurador integrado).

URL simpáticos

A correspondência entre URL e acções de controlo são muito simples e fáceis de compreender. A RoR tenta apresentar ao utilizador URL simpáticos. Os URL da RoR são simples e directos, não sendo nem longos nem parecendo cifrados.

Mesmo assim pode alterá-los usando as capacidades de encaminhamento da RoR. O encaminhamento de URL da RoR é suficientemente flexível para permitir criar virtualmente qualquer esquema de correspondência de URL.

A capacidade de encaminhamento da RoR é obtida com código Ruby puro permitindo o uso de expressões regulares. Visto a RoR não usar a capacidade de encaminhamento do servidor Web (como o mod_rewrite em Apache), as correspondências de URL por nós definidas funcionam em qualquer servidor de web, da mesma forma.

Teste Unitário

A RoR facilita activamente os testes unitários:

• A geração de novos controladores, modelos e a construção de andaimes cria os esqueletos dos testes unitários;
correspondentes.
• A arquitectura estritamente MVC tende a naturalmente resultar em acções e componentes que se possam testar;
• A RoR inclui um script Rake (Ruby Make) que automaticamente executará todos os testes unitários.

Para mais detalhes pode ler Um guia de testes com RoR.

Active Record

Active Record é a parte da RoR que trata da correspondência automática entre tabelas de bases de dados e os objectos dos modelos no momento de execução. É o M em MVC e é a implementação da camada ORM em RoR.

Para todos os casos de uso mais corrente (e alguns não tão correntes como isso), não irá necessitar de usar SQL quando aceder ou actualizar a sua base de dados. O objectivo do Activo Record é especificamente trabalhar com bases de dados relacionais. Não tenta abstrair o uso do SQL. O Active Record torna fácil usar o seu SQL à medida para aqueles casos em que seja necessário. Mesmo que tal seja raramente necessário.

Continua...

display: table

A forma mais fácil de imitar a apresentação tabular é ...adivinhou... usar uma tabela. Já os estou a ouvir gritar. Mas se lhes disser que pode alcançar a mesma apresentação usando a propriedade display com valores tais como table, table-cell e table-row?

Infelizmente os navegadores da Microsoft (tanto no Windows como no Mac) não sabem aplicar estes valores. Trataremos deles mais tarde.

Vejamos então a marcação:

<div id="menu">
    <ul>
        <li>
            <a href="...">item 1</a>
        </li>
        <!-- outros itens da lista -->
    </ul>
</div>

Navegadores modernos

Pense nisto como uma tabela: a div actua como o elemento table, ul como o elemento tr e os elementos li como células (td):

Então o CSS seria algo como:

#menu {
    display: table;
}

ul {
    display: table-row;
}

li {
    display: table-cell;
}
   

Agora poderá adicionar algumas width e outros estilos e eis que está pronto.

#menu {
    width: 100%;
    display: table;
}

#menu ul {
    margin: 0; padding: 0;
    width: 100%;
    display: table-row; /* MS diz WTH */
    background: #ccc;
    vertical-align: middle;
}

#menu li {
    margin: 0; padding: 0;
    display: table-cell; /* Novamente, IE não
                      compreende este valor */
    text-align: center;
    vertical-align: middle;
    background: #ddd;
    border: 1px solid #ccc;
}

* html #menu li { /* MacIE */
    display: inline-block;
    width: 14%; /* um erro de espaço em branco? 
                 100 por cento a dividir por 7 
                 itens arredondado */
}

/* O truque do IE (escondido do MacIE) \*/
* html #menu li {
    display: inline;
    width: 14.2%;
}
/* */

#menu li a {
    display: block;
    width: 100%;
    vertical-align: middle;
    text-decoration: none;
    color: #008;
}

#menu li a:hover {
    background: #eee;
    color: #900;
}

HTML ou xhtml?

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

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

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

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

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

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

RoR 1

Ruby on Rails (RoR) é uma infraestrutura de aplicações para a web escrita em Ruby, uma linguagem de programação com tipos dinâmicos similar à Python, Smalltalk e Perl.

Acaba de passar há pouco tempo um ano desde o aparecimento da RoR em 25 de Julho de 2004. Num intervalo de tempo muito curto progrediu de uma versão 0.5 impressionante até a uma versão 1.0 lançada à pouco tempo que manteve a facilidade de uso e a alta produtividade enquanto adicionava algumas capacidades novas. Este artigo introduz os componentes desta nova versão e explica o bru-a-a que anda à volta desta infraestrutura.

Não pretendo explicar como usar a RoR para escrever aplicações para a Web. Para isso deve começar com: Rolling with Ruby on Rails. Este artigo é uma introdução e roteiro às características da RoR.

Alta produtividade e tempo reduzido de desenvolvimento

Ao nível das capacidades RoR não nos trás nada de novo. Já várias infraestruturas para aplicações para a web o fizeram. Então o que é realmente novo na Ror? O que é que esta infraestrutura trás de diferente. Quando pode acabar aplicações simples em dias em vez de semanas e aplicações mais complicadas em semanas em vez de meses as pessoas começam a notar.

O novo amor teria vida curta se as aplicações web resultantes fossem uma salgalhada e difíceis de manter e ampliar. Felizmente a RoR facilita as boas práticas de programação, o que leva a código fácil de manter e bem factorizado.

A atenção seria também de vida curta se a RoR não tivesse profundidade - isto é, se uma vez experimentada para além das aplicações web mais simples, tivessemos encontrado uma barreira, e nos fosse impossível avançar devido a limitações inerentes. Programadores experimentados que sabem o que fazer na Web repetidamente relataram que não é esse o caso da RoR. Por exemplo James Duncan Davidson recentemente disse:

A RoR é a infraestrutura de desenvolvimento para web mais bem concebida. Digo isto após 10 anos de construção de infraestruturas, ajudei a desenvolver a Servlet API e criei alguns servidores web de raíz. Ninguém o tinha feito desta forma anteriormente. Não estou a dizer que tudo está bem. Não é "perfeita". Tenho alguns detalhes com que não concordo sobre como as coisas devem ser juntas. Mas a "perfeição" não é o ponto. O ponto é que nos põe rapidamente a ser produtivos e tem profundidade suficiente para continuar. A RoR faz isso muito bem.

É difícil acreditar que isto é possível sem desvantagens significativas. Felizmente não tem que julgar a minha palavra (ou a de outra pessoa). Pode provar a sí mesmo num dia ou menos percorrendo um tutorial de RoR e desenvolver uma aplicação simples à sua escolha. Ver para crer! No caso de não se desejar ver espantosamente produtivo, pode ver alguém a fazê-lo vendo o vídeo sobre Ror.

Como é que a RoR o faz?

Como uma boa receita, RoR ajuda a alcançar um novo nível de produtividade combinando os ingredientes correctos nas quantidades correctas. Eis alguns dos ingredientes mais importantes que tornam a RoR naquilo que é:

1. Ruby

   Muito do poder da RoR advém da linguagem de programação Ruby. A concepção única da Ruby torna fácil criar linguagens específicas de um domínio e fazer metaprogramação. A RoR tira total partido disso.

2. Infraestrutura MVC completa

   A RoR é uma infraestrutura MVC (modelo, vista, controlador) onde a RoR fornece todas as camadas e funcionam de forma integrada. Outras infraestruturas normalmente só implementam parte da solução, exigindo que o programador integre várias infraestruturas na aplicação e então obrigar as mesmas a funcionarem em conjunto (por exemplo um programador Java poderá usar Hibernate, Struts e Tiles para obter suporte MVC completo.)

3. Convenção sobrepõe-se a configuração

   Convenção sobrepor-se a configuração significa o fim de ficheiros de configuração XML muito extensos, uma aplicação RoR usa algumas convenções de programação relativamente simples que permitem determinar tudo através de reflexão e descoberta. Por exemplo, RoR usa reflexão inteligente para automaticamente mapear tabelas de bases de dados a objectos Ruby. O seu código de aplicação e a sua base de dados já têm tudo o que a RoR necessita de saber.

4. Menos código

   Seguindo as convenções simples da RoR faz mais do que eliminar os ficheiros de configuração. Significa também que a RoR pode automaticamente tratar de uma grande quantidade de detalhes de baixo nível sem ter de lhe dizer nada sobre isso. Isto significa escrever menos linhas de código para implementar a sua aplicação. Manter o seu código pequeno significa desenvolvimento mais rápido, menos erros e tornar o código mais fácil de compreender, manter e melhorar.

5. Geradores

   O uso pela RoR da reflexão de tempo de execução e da metaprogramação elimina muito do código de corta e cola que de outro modo teria que criar. Pode frequentemente evitar o código do tipo corta e cola usando o gerador de scripts integrado para o fazer por si. Isto deixa-lhe mais tempo para se concentrar no código que realmente interessa - a lógica do seu negócio.

6. Ciclo de desenvolvimento curto

   O ciclo típico de desenvolvimento para teste de uma alteração numa aplicação web tem passos como configurar, compilar, instalar, reiniciar e testar. Isto leva a consumir muito tempo. O ambiente de desenvolvimento RoR não tem nada disto. Nós fazemos uma alteração e vê-mos o seu funcionamento. Não faço o erro de julgar que isto é um ponto menor. É difícil de dizer quanto é que isto melhorar a produtividade e o ajuda a manter um fluxo criativo ininterrupto.

7. Andaimes

   A RoR pode criar automaticamente um conjunto completo de operações CRUD (Criar, recuperar, actualizar e apagar) e vistas de qualquer tabela de base de dados. Estes andaimes permitem-lhe começar rapidamente com a manipulação das suas tabelas de bases de dados. Ao longo do tempo pode substituir as operações CRUD geradas e as vistas com o seu próprio código - presumivelmente muito mais bonito e funcional.

Continua...

Descrição: Define como é que o espaço em branco é tratado.

Sintaxe: white-space: valor;

Define como é que o espaço em branco será tratado

  white-space : normal;

O espaço em branco será tratado como normal

white-space : pre;

O espaço em branco será tratado como no elemento

  white-space : nowrap;

O elemento não volta atrás nas quebras de linha normais.

Exemplos:

<p style="white-space : pre;">

Isto só se usa para espaços nada mais.

<p style="white-space : nowrap;">

Esta linha não volta atrás e irá forçar o navegador a colocar uma barra de rolamento em baixo se não tiver espaço para a apresentar na totalidade.

Notas:

• normal age como um navegador típico: qualquer sequência de caracteres de espaço em branco é reduzido a um caracter.
• pre age como um elemento pre
• nowrap evita a quebra de linha.

hasLayout

Sumários

Muitas das inconsistências na reprodução pelo Internet Explorer podem ser corrigidas dando a um elemento "layout". John Gallant e Holly Bergevin classificaram estas inconsistências como "erros dimensionais" querendo dizer que podem ser frequentemente resolvidos aplicando uma largura ou uma altura ao elemento. Isto leva a pergunta de porque é que o "layout" pode alterar a reprodução e as relações entre elementos. A questão, embora uma boa questão, é de difícil resposta.

Definição de hasLayout

"Layout" é um conceito proprietário do IEWin que determina como é que os elementos, em analogia com uma janela, desenham e limitam o seu conteúdo, interagindo com e relativamente a outros elementos e reagem ou transmitem eventos da aplicação/utilizador.

Os programadores da Microsoft decidiram que os elementos do tipo caixa devem ser capazes de adquirir uma propriedade (no sentido de programação orientada a objectos) a que se referem como layout, ou em alternativa, hasLayout.

hasLayout provavelmente não é nem uma propriedade nem mesmo um comportamento mas talvez um conceito de engenharia inerente à reprodução que dá uma qualidade a um elemento.

Esta qualidade de reprodução pode, de facto, ser irreversivelmente despoletada para tomar o valor true por algumas propriedades CSS e alguns elementos têm «layout» por omissão.

Nomenclatura

Dizemos que um elemento "tem layout" ou "ganha layout" quando presumimos que a propriedade da Microsoft hasLayout toma o valor true. Um elemento com layout pode ser qualquer elemento que tenha layout por omissão ou que tenha ganho layout pelo estabelecimento de propriedade CSS apropriada.

Elementos sem layout, onde hasLayout não tenha sido despoletada, por exemplo div sem dimensões podem ser ancestrais sem layout.

Dar um aplicar layout a um elemento que por omissão não o tem envolve estabelecer uma propriedade CSS que despolete hasLayout = true ao elemento em questão. Não há maneira de despoletar hasLayout = false a não ser apagar a propriedade CSS que tenha causado o inverso.

Introdução

O problema hasLayout afecta os web designer e os codificadores com todos os níveis de experiência. O Layout tem efeitos inabituais e difíceis de prever sobre o comportamento da reprodução de caixas que têm layout, assim como as implicações para os elementos seus descendentes dentro dessas caixas.

As consequência que podem resultar de um elemento ter ou não layout podem incluir:

• Muitos erros habituais em elementos flutuantes no IE;
• As caixas tratarem cercas propriedades básicas de forma diferente;
• Colapso das margens entre um contentor e os seus descendentes;
• Diferenças no posicionamento de imagens de fundo;
• Diferenças entre navegadores quando se usa scripting.

Esta lista está incompleta.

De onde é que vem o layout

Ao contrário de propriedades padronizadas, ou mesmo de propriedades CSS proprietárias disponíveis nos diversos navegadores o layout não é directamente atribuível via declaração CSS. Por outras palavras, não há propriedade layout. Alguns elementos automaticamente têm layout e é adicionado de forma invisível quando certas declarações CSS são feitas.

Elementos com layout por omissão

Os elementos seguintes parecem ter layout

• <table>
• <td>
• <body>
• <img>
• <hr>
• <input>, <select>, <textarea>, <button>
• <iframe>,
• <embed>, <object>, <applet>
• <marquee>

Propriedades

Os seguintes pares propriedade CSS/valor se aplicados permitem que um elemento ganhe layout

position: absolute

Refer-se ao seu bloco contentor e é aqui que começam alguns problemas.

float: left ou float:right

O elemento flutuante tem diversos detalhes devido a algunas aspectos de um elemento com layout

display: inline-block

Por vezes a cura quando um elemento é de nível em linha e necessita de layout. Aplicar layout é provavelmente o único efeito real desta propriedade. O comportamento de bloco em linha pode ser alcançado de forma independente: IEWin: bloco em linha e tem layout.

width: qq valor

Isto normalmente é uma correcção implícita, frequetemente o gatilho quando hasLayout gera erros.

height: qq valor

Por exemplo usado no Holly Hack.

zoom: qq valor

Proprietária da MS, não valida. zoom: 1 pode ser usado em depuração.

writing-mode: tb-rl

Proprietária da MS, não valida.

Notas sobre elemento ao nível em linha

Para elementos em linha (sejam elementos em linha por omissão como span seja elementos com a regra CSS display: inline:

• width e height despoletam hasLayout no IE5+ só em modo quirks. No IE6 em modo standard os elementos em linha ignoram as propriedades width e heigth e indicar uma largura ou altura para estes elementos não despoletará a propriedade hasLayout.
• zoom irá sempre despoletar hasLayout mas não está disponível em IE5.

Elementos que tenham layout (por omissão) e display:inline comportam-se como indicado nos standards: fluem horizontalmente como palavras num parágrafo, são sensíveis ao alinhamento vertical e aplicam uma forma de envelope ao seu conteúdo. Assim que os elementos em linha tenham layout, agem como bloco em linha, e isto explica porque é que no IEWin os elementos em linha podem conter elementos de nível bloco com mesmo problemas que noutros navegadores, onde display:inline se mantem em linha.

xml:lang e lang

Contexto

Por vezes os documentos contêm ou incluem conteúdo com línguas diferentes. Por vezes é necessário armazenar um valor de língua natural como dado ou metadado sobre algo externo ao documento. Devido a estas diferentes aplicações usarem formatos similares, os conceptores de esquemas por vezes confundem a utilização admissível de xml:lang e quando devem definir os seus próprios elementos/atributos relativos a línguas.

Por exemplo em XHTML 1.0 há um atributo hreflang no elemento e também um xml:lang (ou atributo lang, no caso do HTML 4.0) para o conteúdo de um elemento a:

<a xml:lang="pt" href="xyz" hreflang="de">
   Carregar aqui para versão alemã</a>

O atributo xml:lang descreve uma língua contida pelo elemento a ("Carregar aqui para versão alemã"), enquanto o atributo hreflang é metadado, neste caso descrevendo a língua de um conteúdo externo a esta página web.

Resposta

Quando usar xml:lang

Conteúdo directamente associado ao documento xml (seja contido dentro do documento directamente seja considerado parte de um documento quando processado ou reproduzido) deve usar o atributo xml:lang para indicar a língua desse conteúdo. xml:lang deve ser reservado a autores de conteúdo para etiquetarem directamente qualquer conteúdo em língua natural que tenham.

xml:lang é definido pelo xml 1.0 como um atributo comum que pode ser usado para indicar a língua de qualquer conteúdo de um elemento. Isto inclui texto legível por humanos assim como outro conteúdo (tais como os objectos embebidos, imagens ou ficheiros de som), contidos por um elemento no qual apareça. O valor xml:lang é aplicado a cada um dos sub-elementos contidos pelo elemento. Também se aplica a valores de atributos associados com o elemento e sub-elementos (embora usar língua natural num atributo não seja uma boa prática). O valor de um atributo xml:lang é um dos possíveis indicados no RFC 3066 ou um dos seus sucessores.

Eis um exemplo de xml:lang num elemento t:

   <t xml:lang="pt"> 
   Isto é texto contido num elemento 't'. O uso do atributo
   xml:lang indica que a língua, que por exemplo um corrector 
   ortográfico deve aplicar quando estiver a efectuar uma
   revisão do documento é Português. Se não o indicarmos
   podemos ter problemas se tivermos conteúdo embebido 
   noutra língua como na frase <span xml:lang="fr">
   C'est la vie</span>, que está em francês.
   </t>

Este exemplo mostra a aplicação de xml:lang a um atributo:

 <para>Il faut utiliser 
 <abbr title="Simple Object Access Protocol" xml:lang="en">
 SOAP</abbr></para>

Quando usar o seu próprio elemento ou atributo

Quando o valor da língua é realmente um atributo de ou metadado sobre algum conteúdo externo, então xml:lang não e uma escolha apropriada. Nestes casos deseja guardar informação sobre língua, mas a língua não se refer ao conteúdo do documento xml (ou conteúdo incluído, tal como imagens, que são processadas como parte do documento) directamente. Neste caso deve definir um elemento ou atributo com um nome diferente e não usar o atributo xml:lang. O valor do elemento ou atributo deve usar o RFC 3066, tal como xml:lang.

Alguns exemplos disto podem incluir:

• Um elemento num documento xml descrevendo a sua colecção de DVD's para indicar em que línguas se encontras as canções;
• Um elemento de uma base de dados de clientes com um campo para a língua preferida do cliente;
• Um atributo de um elemento de ligação (tal como o a no xhtml) apontando para uma versão do documento noutra língua.

A razão pela qual optar por criar o seu próprio elemento (ou atributo) é comunicar a língua como um valor (ou parte de uma estrutura de dados ou como metadados sobre um documento externo) em vez de indicar a língua de uma peça específica de conteúdo. Evitar usar xml:lang para descrever valores externos de língua evita criar problemas a autores de conteúdos que necessitem de etiquetar conteúdo com finalidades relativas a processamento de texto.

Por exemplo um documento xml poderá ter o seguinte aspecto:

 <item type="DVD"> 
  <title xml:lang="fr">Cyrano de Bergerac</title>    
  <!-- indic a língua em que o filme se encontra -->
  <duracao value="137" />                        
  <!-- não afectado pela língua -->
  <dialogue>en</dialogue>                            
  <!-- indic a língua do diálogo -->
  <legendas pista="1" lingua="zh-Hant" />         
  <!-- Esta pista contém legendas em chinês tradicional -->
  <legendas pista="2" lingua="zh-Hans" /> 
 </item>

Neste exemoplo o atributo xml:lang comunica informação sobre a língua natural do texto que aparece neste documento. O elemento diálogo e o atributo língua dos elementos legendas são definidos no esquema do documento xml e comunicam um valor de língua natural associado a estes itens. Por exemplo comunica a informação de que as legendas na pista número 1 são escritas ou mostradas em chinês tradicional.

A propósito

É importante lembrar que xml:lang tem âmbito de validade: os elementos de nível inferior herdam o atributo. Isto pode servir para identificar a língua de muito conteúdo (sem ter marcadores de língua redundantes em cada elemento). Por exemplo, é boa prática colocar xml:lang no elemento html no início do documento xhtml e só o voltar a usar quando a língua mudar. Para mais informação ver o artigo: Marcadores de Língua em HTML e XML.

Recursos adicionais

Técnicas de autoria para internacionalização de xhtml e html: Especificação de língua de conteúdo 1.0

Artigos Interessantes

1. Conceber Aplicações com Interface Complexo com Visio de Bill Scott explica como conceber um interface de utilizador para uma aplicação da internet usando uma ferramenta (extensão) produzida para o Visio pelo Bill. No seu blogue, Bill expõe os pontos fracos e fortes da sua extensão. No artigo das caixas e das setas expõe a concepção de um interface de utilizador completo.
2. Como colaborar bem com os restantes responsáveis pelo desenvolvimento de Mike Stenhouse apresenta a sua experiência e pensamento sobre o desenvolvimento de CSS modular e de manutenção simplificada.
3. Rascunho das WCAG 2.0 de Jeffrey Zeldman diz-nos que as directrizes WAI se estão a afinar retirando algumas das ambiguidades que nela figuram actualmente. Acho que qualquer pessoa que deseje começar deve ler os documentos fundamentais mesmo na sua forma de rascunhos para puder avaliar as tendências para o futuro (este comentário é meu).
4. (Modelo de) Caixa de Pandora de Truques CSS e Outra Boas Intenções de Tantek, apresenta-nos a visão que Tantek tem hoje dos truques que se foram aplicando ao código CSS para acomodar não conformidade com as especificações do W3C por parte de alguns navegadores. Tem algum fundo histórico para se perceber qual foi a evolução e a razão do aparecimento destes itens indesejáveis em muitos casos.
5. Padrões e Semântica Web de John Allsopp fála-nos da expressividade baixa do HTML mesmo com as identificações e classes.
6. 24 maneiras de impressionar as suas amigas (desculpem os seus amigos) Mostra-nos uma aplicação de uma infraestrutura JavaScript de Sam Stephenson chamada Prototype
7. Ir à placa giratória (o meu título seria: Alimentos para um junkie da web de Danny Ayer toca mais tecnologias de alimentação de informação do que eu gostaria.

Fora de tópico

Assinalar vulnerabilidades em sistemas de escuta artigo produzido na Universidade da Pensilvânia curioso. Os "maus" parecem poder ter as costa livres.

ALA - 208

Saiu o número 208 do A List Apart.

Neste número temos artigos para audiências diferentes:

Para o tipógrafo que há em si tem:

1. Imprimir um livro com CSS: Boom! Trata-se da apresentação de um método de produção de livros impressos baseado em HTML e CSS mediado pelo Prince para produzir um PDF final para impressão. Boom trata-se de um microformato proposto pelos autores: Bert Bos e Hakon Wium Lie.
2. Poder ao povo de D. Keyth Robinson, que julgo resumir razoavelmente como criar soluções para necessidades de utilizadores fazendo-o de forma mais simples possível. Além disso é bom ouvir os seus utilizadores e/ou visitantes/clientes.
3. O terceiro artigo (o repescado do número 96) A maldição da Concepção da Informação de Scott Jason Cohen, fala das dificuldades colocadas pelos especialistas em acessibilidade e usabilidade e os problemas que algum conservadorismo dos arquitectos de informação pode trazer à evolução da web.

Sítio de Eleição

Por vezes é necessário criar uma visualização de dados complexos e não sabemos como. Aqui http://www.visualcomplexity.com/ poderá encontrar algo para as suas necessidades/desejos.

Erros comuns em XHTML

• Não fechar elementos vazios (elementos sem marcador de final)
  • Incorrecto: <br>
  • Correcto: <br />
• Não fechar elementos não vazios
  • Incorrecto: <p>Isto é um parágrafo.<p>Isto é um outro parágrafo.
  • Correcto: <p>Isto é um parágrafo.</p><p>Isto é outro parágrafo.</p>
• Aninhar elementos de forma imprópria (os elementos têm que ser fechado pela ordem inversa)
  • Incorrecto: <em><strong>Isto é algum texto.</em></strong>
  • Correcto: <em><strong>Isto é algum texto.</strong></em>
• Não especificar texto alternativo para imagens (usar o atributo alt, que ajuda a tornar as páginas acessíveis a utilizadores com dispositivos que não carregam imagens ou têm dificiência visual)
  • Incorrecto: <img src="/peles/comuns/imagens/alimentadoporblabla.png" />
  • Correcto: <img src="/peles/comuns/imagens/alimentadoporblabla.png" alt="Blabla" />
• Colocar texto directamente no corpo do documento (isto não é um erro em XHTML 1.0 Transitional)
  • Incorrecto: <body>Bem vindo à minha página.</body>
  • Correcto: <body><p>Bem vindo à minha página.</p></body>
• Aninhar elementos bloco dentro de elementos em linha
  • Incorrecto: <em><h2>Introdução</h2></em>
  • Correcto: <h2><em>Introduction</em></h2>
• Não colocar pelicas à volta de valores de atributos
  • Incorrecto: <td rowspan=3>
  • Correcto: <td rowspan="3">
• Usar e comercial fora de entidades (usar & para mostrar o caracter «e comercial»)
  • Incorrecto: <title>Carros & Camiões</title>
  • Correcto: <title>Carros &amp; Camiões</title>
• Uso de e comercial fora de entidades em URLs (usar & em vez de & também em ligações)
  • Incorrecto: <a href="index.php?page=noticias&estilo=5">Notícias</a>
  • Correcto: <a href="index.php?page=noticias&amp;estilo=5"gt;News</a>
• Uso de nomes de elementos ou atributos em maísculas
  • Incorrecto: <BODY><P>A Melhor Página de Sempre</P></BODY>
  • Correcto: <body><p>A Melhor Página de Sempre</p></body>
• Minimização de atributo
  • Incorrecto: <textarea readonly>SÓ DE LEITURA</textarea>
  • Correcto: <textarea readonly="readonly">SÓ DE LEITURA</textarea>

Esta é uma lista muito abreviada dos erros encontrados

XHTML para leigos

Se dissermos «qual é a coisa qual é ela que antes de o ser já o era?» Então um ouvinte terá que adivinhar qual será a resposta.

Se dissermos tudo o que sobe tem que cair. Nada de tentar adivinhar, uma frase simples e com início e fim adequados. Faz sentido que algo que seja lançado para o alto tenha que voltar à terra. O não voltar desafia a gravidade não estando de acordo com aquilo que vemos no dia a dia.

Isto é muito semelhante às diferenças entre o XHTML e o HTML 4.01. Em XHTML, tudo o que tem um princípio tem que ter um fim. Em HTML, tal não se passa. Pode começar um parágrafo mas, nunca o acabar. Pode ter uma lista de coisas e nunca terminar cada item. Se tivermos que comunicar com alguém que nunca termina as frases, tal será confuso no mínimo.

Pense nisto da seguinte forma: o HTML foi pensado como um pacote, com uma dobra em cada lado. Contudo mesmo a especificação estrita é tem ainda alguma maleabilidade, ou seja o pacote não necessita estar fechado. Não sei o que é que pensa mas é mais provável comer uma bolacha dum pacote fechado de um aberto sabe quem há quanto tempo.

Exemplos:

Abaixo encontrará um exemplo de código HTML válido mesmo sob o tipo de documento HTML 4.01 estrito:

     <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN" 
                                              "http://www.w3.org/TR/html4/strict.dtd">
     <html>
     <HEAD>
     <meta http-EQUIV="Content-TyPe" content="text/html; 
                                                                CHARSET=utf-8">
     <titlE>Testing HTML 4.01</TITLe>
     </head>
     <body>
     <P>This is some sloppy HTML 4.01!
     <oL>
     <LI>List item one
     <LI>List item two
     <li>List item three</LI>
     </Ol>
     </BODy>
     </HTmL>

Para comparação eis o mesmo reescrito em XHTML 1.1:

     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
     <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
     <head>
     <meta http-equiv="content-type" content="application/xhtml+xml; 
         charset=utf-8" />
     <title>Testing XHTML 1.1</title>
     </head>
     <body>
     <p>This is some clean XHTML 1.1!</p>
     <ol>
     <li>List item one</li>
     <li>List item two</li>
     <li>List item three</li>
     </ol>
     </body>
     </html>

Como pode comprovar o segundo exemplo é mais legível (desde que saiba sintaxe HTML). Tudo excepto o DOCTYPE está em minúsculas e tudo que tem um início tem um fim explicíto. Não é só mais fácil, evita que o navegador faça algum trabalho de adivinhação sobre o local onde seria suposto encontrar-se os marcadores de fecho. Por exemplo um <li> pode ser fechado no final da linha, mas também é possível envolver coisas dentro de itens de lista.

Um navegador não sabe até atingir o marcador de abertura seguinte se deve fechar o marcador anterior ou se o deve deixar aberto. Assim não há só confusão para uma pessoa que leia o código, mas para a reprodução da página. Implicitamente esta lógica extra necessária provoca um aumento do tempo de carregamento, independentemente do caso de uns tantos bytes extra necessários ao fecho dos marcadores de cada vez que são abertos. O código limpor é reproduzido mais rapidamente, ponto parágrafo. Para prova de tal verifique estes artigo (não o código do sítio).

Terminador por si:

No final do Terminator 2, Arnold diz "não posso acabar comigo". No caso do XHTML isto é bom. Se tudo o que começa tem que ser terminado há alguns pontos nos quais o HTML mesmo que bem formado tem uns quantos problemas. No exemplo acima, há um desses pontos no marcador meta descrevendo o tipo de conteúdo.

Em HTML um meta termina com um ">" significando que tecnicamente ele se mantem aberto. O XHTML corrige isto terminando-se a sí próprio o meta com um traço de fracção final "/>". Outros marcadores com o mesmo comportamento são img, br e hr – todos são tipicamente deixados "em aberto" no HTML, terminando-se a sí próprios no XHTML. Isto torna muito mais fácil uma leitura sabendo que sempre que encontrar um "/>" se está na presença do fim do marcador.

Resumo:

Deixando de lado toda a argumentação para servir XHTML como text/html ou como application/xhtml+xml, prefiro XHTML devido à rigidez inerente à sua validação. Isto claro que não quer dizer que o HTML não possa ser escrito com um padrão muito próximo em mente o problema é que não não é exigído. Veja se me entende não estou a dizer que o XHTML é a forma mais apropriada de fazer as coisas.

Isto não é uma atitude pedante. Sei perfeitamente que o HTML pode ser tão estruturado e semântico quando o XHTML. Roger Johansson e Robert Nyman são perítos em desenvolvimento de web e ambos usam HTML 4.01 estrito de maneira adequada. Ambos fecham tudo e usam código em minúsculas. Robert escreveu um artigo sobre html versus xhtml. Roger é claramente um apaixonado pelo fecho adequado dos marcadores como pode ser comprovado no seu artigo.

Doug Bowman, outra lenda no campo usa XHTML 1.0 estrito, mas serve-o como text/html, sem grande problema. Vejo a lógica por detrás dos argumentos de ambos os lados sobre quererem continuar a trabalhar adequadamente com navegadores obsoletos, etc.

Voltemos ao assunto principal: Resolvemos os mistérios da humanidade? Não. Este artigo está aqui para provar as vantagens de um doctype sobre outro? Não. Só quiz dar uma revisão geral sobre o que me levou inicialmente para o XHTML e porque prefiro continuar a usar. O aspecto fundamentar é que independentemente do que escolha se lhe mantenha fiel. Não tente misturar - mantenha os marcadores em minúsculas e feche-os.

Ou seja no fim disto tudo. Faça uma selecção de um standards e depois aja em conformidade com o mesmo. Uma disputa sobre que standard seguir é fútil.

Esquadria azul à volta de uma imagem

Tornar uma imagem a ligação para outra página é muito simples, o HTML que segue trata disso:

 <a href="http://aindaapensar.blogspot.com/">
 <img src="/aindaapensar.png" 

                alt="logotipo de aindaapensar">
 </a>

No entanto irá verificar que aparece uma esquadria azul à volta da imagem. Esta esquadria serve para informar os utilizadores que a imagem é uma ligação. Claro que há algo a dizer para indicar o que é que ou não uma ligação.

Hoje a generalidade dos designers da web tornam óbvio através das concepções do anúncios ou botões de navegação aqueles elementos que são ligações e nos quais se pode carregar. Então como é que apagamos essa esquadria?

Aqueles que gostam de aplicar as recomendações devem usar folhas de estilo e assim o código será algo como:

 <a href="http://aindaapensar.blogspot.com/">
 <img src="/aindaapensar.png" 

             alt="logotipo de aindaapensar" 

             style="border-style: none">
 </a>

Ou ainda melhor remetendo a regra para a folha de estilo separada:

img
{
 border-style: none;
}

E no elemento header da sua página fazer uma menção à folha de estilo:

 <link href="/folha_de_estilo.css" 

                 rel="stylesheet" type="text/css">

Este método irá automaticamente remover a esquadria azul de todas as imagens que usem este ficheiro css e no caso desta regra não ser ultrapassada por outra mais específica.

div versus span

Para quem não sabe um elemento div é um elemento bloco e um elemento span é um elemento em linha.

Para os curiosos podem dirigir-se à fonte do html

O que é que é isso de elemento bloco e elemento em linha?

Campos escaláveis

As listas de discussão podem não ser a leitura mais agradável que se possa ter mas permite que um principiante aprenda umas coisas.

Por exemplo quando o utilizador altera o tamanho do tipo de letra é razoável esperar que o campo de pesquisa também veja o seu tamanho aumentar para que isso suceda basta na nossa folha de estilo incluir algo como:

form input {
      width: 15em;
      height: 1.3em;
      font-size: .9em;
}

Nem todos os navegadores respondem a isto de forma imediata alguns necessitam de ser refrescados para ajustarem a altura por exemplo de um select

Com o código acima aumenta a largura e altura do campo assim como o tamanho do tipo da letra.

RSS

No blogue da equipa de RSS da Microsoft diz-se que:

...a nossa experiência de vários anos com o HTML no IE ensinou-nos os problemas a longo prazo que resultam de sermos demasiado liberais naquilo que aceitamos de terceiros. Assim, adoptamos o seguinte princípio para o IE7 e a plataforma RSS no Windows Vista: só iremos suportar alimento XML bem formado.

O que me der na mona

Estou a experimentar uma alternativa ao blogger, o wordpress em "O que me der na mona". Até agora a primeira coisa que me salta à vista é que o processo de produção de colocação na net de um texto permite uma classificação coisa que este directamente não faz. Assim provavelmente a minha secção de Web Standards em Portugal vai passar para lá ficando neste blogue pequenos excertos de html, javascript, css, ruby e outras coias mais associadas a puro código.

As minhas observações sobre web design, arquitectura de informação, web 2.0 e outras devem passar para lá (claro que mantendo-se aqui o que já cá está.)

background-color e color

background-color e color

Algumas pessoas quando vêm o relatório do validador de CSS acham sem importância os avisos em especial quando estes se referem a cores de texto e cores de fundo (color e background-color).

Quando não se especifica uma ou outra o que pode suceder é que um visitante do sítio ter uma configuração específica em que ambas em determinados elementos sejam coincidentes e nesse caso o visitante deixará de poder ler o conteúdo pois a página lhe vai parecer vazia.

Web Standards em Portugal

Parem a Impressão, parem a impressão! O novo sítio da Universidade de Lisboa passou a validar!

Não sei em que dia é que isto terá sucedido mas o novo sítio da Universidade de Lisboa passou a validar.

A utilização de tabelas para criar a disposição dos vários elementos mantêm-se (mas já esteve mais longe).

Resumindo a componente mecânica já está! Falta a componente mais humana (semântica).

É pena que haja pelo menos uma página na UL(no interior) com erros ligeiros (falta de fecho de parágrafo) quando deviam validar página a página (teste unitário) para saberem o que mudar.

O CSS também valida com alguns avisos em especial com falta de cores de fundo em elementos com cor (de texto) ou vice-versa.

Continuam a usar atributos que já não se esperaria usarem td com width .

Já agora depois de transformarem as tabelas que não são tabelas em div e torna-se em algo importante um sítio de um estabelecimento de ensino superior a seguir as regras.

Verificar CSS

Como é que posso verificar se o CSS está correctamente formado e se está de acordo com os Standards do W3C?

O W3C tem um validador de CSS o qual verifica URL, submissão de um ficheiro (CSS ou HTML com folha de estilos <style> ou cópia de CSS directamente para uma caixa de texto para verificação.

Existe para o Firefox um plug in para responsáveis por desenvolvimento de sítios que tem ligações para uma série de validadores entre eles este.

Como Centrar Conteúdos

Como Centrar Conteúdos

Um problema comum para web designers é centrar conteúdos numa página web

O modelo actual do (X)HTML e do CSS é ver cada documento Web como uma área não limitada e, uma janela de navegador como uma vista para esse documento e não uma parte do mesmo. Daí ser impossível centrar um documento em qualquer janela de navegador.

No entanto por vezes é absolutamente necessário centrar verticalmente uma página ou páginas. Há essencialmente três formas de o fazer: através da combinação de JavaScript e posicionamento absoluto CSS; ou através de métodos arcaicos HTML (usando um arranjo de uma só célula de tabela); ou podemos usar regras de estilo CSS para esticar o documento até 100% da janela do navegador em altura e depois centrar verticalmente o resto da página. O método QuircksMode pode ser usado para esticar o documento. É realmente simples. Só é necessário encontrar o elemento (X)HTML que é para o navegador o equivalente da sua janela - a combinação html e body é suficiente para a generalidade dos principais navegadores e depois definir uma divaninhada com posicionamento absoluto.

(Pode ainda ajustar-se as características desta div com atributos overflow, min/max width/heightetc.)

O código resultante seria algo como (substituir ... por valores adequados ao seu caso):

<... (veja o método QuircksMode para decidir que doctype...>
<html>
   <head>
      <title>Processo de Centragem Vertical da Victoria
                   - Página de Teste</title>
      <style type="text/css">
         html, body   { background-color: blue;
                        height: 100%; 
                        margin: 0;
                        padding: 0;
                        color: yellow; 
                        text-align: center; }
         div#centered { border: 0; 
                        background-color: white;
                        height: 50%;
                        width: 50%;
                        position: absolute;
                        left: 25%;
                        top: 25%;
                        color: black; }
      </style>
   </head>
   <body>
      <div id="centered">
         div centrada verticalmente
            (<a href="http://vmalek.murphy.cz" 
                   title="Processo de Centragem 
                          Vertical da Victoria">
                          Ver comentários acima</a>).
      </div>
   </body>
</html>

Web Standards em Portugual

Para quem ache que tudo o que escrevo é para deitar abaixo, tal não é de facto verdade.

Como já tinha anteriormente dito em Portugal existem responsáveis pelo desenvolvimento de sítios web que levam a sério os web standards.

Hoje irem tentar aqui colocar páginas de entidades que já estejam a aproximar-se desse alvo a atingir, não por si, mas porque isso facilitará a vida as seus visitantes.

• log

  As páginas validam o XHTML e o CSS. Gostaria de perceber porque é que num sítio com padrão elevado (para a média nacional) depois se falha (ou então porque é que se dicide desta forma) nos detalhes. Está quase lá em termos de standards.

  Em termos gráficos já tenho um problema um pouco maior com a página. O sítio é na minha opinião demasiado frio, quase sem grafismos, a não ser os botões de navegação e o próprio logo. Além disso não é suficientemente flexível pois se ampliarmos os tipos o aspecto começa a ficar excessivamente degradado (excepto no Opera claro). Talves fosse melhor começar a treinar as pessoas que desenvolvem sítios torná-los à prova de bala.

  

  Algo curioso é os sítios instituicionais por ela produzidos não alcançarem o padrão em termos de web standards do próprio sítio. Será que o sítio apresenta uma evolução. Por último, foi a única empresa de desenvolvimento, em que vi código tão bom.

Esta lista irá, julgo/espero, crescer à medida que for encontrando sítios assim ou melhores (claro que na minha opinião).

Um Profissional Nunca Pode Deixar de Aprender

Um profissional nunca pode deixar de aprender

Nos últimos tempos tenho lido artigos que levantam o mesmo problema: os profissionais da web que se recusam a actualizar as suas capacidades e insistem em usar métodos desactualizados não se podem chamar a si próprios profissionais da Web.

Há quem me possa achar elitista ao dizê-lo. Mas pense sobre o assunto. Porque é que os profissionais da web não necessitariam de saber sobre o seu metier. Acho esta atitude - tida por muito gente neste meio e por muita gente fora dele - insultuosa para aqueles que diariamente trabalham de forma árdua para se manterem actualizados e ao corrente das melhores práticas.

Gosto que outros expressem as suas opiniões sobre este assunto. Ian Loyd entrevistou Andy Clarke. Eis uma citação que subscrevo:

Há tantos sítios na web, blogues e publicações derigidas para ajudar as pessoas a aprenderem sobre standards e técnicas de acessibilidade que deixou de haver desculpas para não produzir código semântico ou CSS. Pessoas que continuam a produzir disposições de páginas baseadas em tabelas, imagens para espacejamento ou que ignorem a acessibilidade (eu acrescento a usabilidade) não se devem chamar a si próprias profissionais da web.

Esta foi uma forma abreviada de dizer aquilo com que concordo. No caso de desejar comentar esta citação dê um salto a Acessibilidade - Sem luvas

Estou completamente de acordo com o que o Andy diz. Não há razão para tratar alguém como profissional se essa pessa não envida qualquer esforço para aprender e se manter actualizado. Veja bem não estou a apontar o dedo aos que não sabem, aos que são tão novos no meio que ainda não aprenderam mas que estão dispostos a aprender sobre desenvolvimento e concepção modernos para web.

A Molly Holzschlag no seu artigo web standards e novo profissionalismo diz:

O cerne da questão é simples: temos que saber do nosso mêtier! E o que não sabemos, temos que ter disposição para dizer que não conhecemos e que estamos abertos a aprender.

A palavra chave aqui é mêtier. Há tanta gente no meio que parece que não se interessa pelo que faz. Há muitas pessoas que só fazem o que for preciso para que a tarefa termine, que é uma expressão comum para defender o uso de métodos desactualizados.

Estas palavras da Molly surgem num contexto de degradação obervado no sítio da Disney no Reino Unido substituindo um sítio concebido com base em web standards por um sítio concebido com uma grande mixordia de tabelas.

Sei pouco sobre desenvolvimento de web. Mas quando não sei algo, trato de o admitir e ir à procura. Ou pergunto a alguém que o saiba.

Finalmente John Oxton, que exprimiu a citação seguinte em Porque é que agora é ex-html (algumas palavras censuradas):

O que eu desejo é HTML que dê um pontapé no ... se não for tratado de forma adequada. HTML que não tomasse xxxx, com uma mensagem bem destacada (VÁ TRATAR DE APRENDER A USAR-ME!) a pessoas que se recusem a aprender esta linguagem super simples e que não queiram refinar a sua compreenção.

John fala de XHTML servido como XML. Sei que muitos não acreditam no deixar que o navegador (user agent seria um termo mais correcto) apresente mensagens de erro ao visitante de um sítio, em vez de tentar (o user agent), entender o que o autor queria de facto dizer/mostrar. Deixemos de lado esta controvérsia e, imaginemos que todos os navegadores mostram tais mensagens de erro. Não sucederia que muitos dos chamados profissionais da web se preocupariam em aprender como resolver esses erros?

Bem sei que se o HTML tivesses sido tão estrito desde o início, a web não se teria tornado no que é hoje, pois, a curva de aprendizagem, teria sido muito difícil de ultrapassar para muita gente. Mas a web está mais madura agora do que há uma década, quando apareceram os primeiros navegadores gráficos. Chegou a altura para os profissionais da web também amadurecerem.

Alguns dos Grandes Podem Mostrar o Caminho

Amanha veremos como se comportam as empresas em Portugal.

Boas Práticas

Boas práticas de Desenvolvimento

Alguém pergunta se há uma forma correcta de começar um projecto. Acrescenta que o que quer dizer é se se deve começar por escrever o HTML todo e depois escrever as regras CSS ou se se deve fazer as duas coisas de forma alternada? Diz ainda, que está a tentar encontrar um processo lógico a seguir de forma a tornar a tarefa mais fácil de compreender e terminar.

Qual é a minha opinião?

Julgo ser mais fácil desenvolver a totalidade do HTML e documentar a estrutura elementar, as classes e identificações antes de começar o CSS.

Pode parecer aborrecido e pode suceder ser necessário voltar ao HTML mais tarde quando se estiver a resolver problemas levantados por navegadores mal comportados, mas este processo assegura que:

• O nosso HTML fica bem estruturado e faz sentido sem CSS e/ou JavaScript;
• Ficamos com documentação para passar aos responsáveis pela manutenção e mais importante para provar que o nosso código era claro;
• Podemos dar o HTML aos responsáveis pelo desenvolvimento para o transformarem em modelos (templates) ou converterem em ASP.NET, de forma a assegurar que se trabalha em paralelo;
• Alguns sistemas de gestão de conteúdos fornecem diferentes classes aos editores como estilos num editor WYSIWYG, e tal significa que podemos criar um pequeno guia de estilo para ser preenchido mais tarde quando construir o CSS.

Web Standards em Portugual

Sítios Portugueses construídos em conformidade com os web standards

Existe na rede um sítio onde alguns designers se registam dando a conhecer que concebem sítios da web em conformidade com os standards.

Nesse sítio, - W3 Compliant Sites - encontram-se inscritos 1088 designers entre os quais 7 portugueses.

Fiz uma visita a cada um dos sítios por eles indicados como estando em conformidade com os web standards.

Dessas visitas destaco os seguintes designers

1. Carlos Paula Simões
   1. cb2web.com e
   2. Hotel Anjo Azul

   As páginas validam usando as ferramentas clássicas, o código está segregado como é correcto, o design no sítio do hotel é simples e eficaz (mas um pouco apagado não se destacando).

2. Hugo C. Silva
   1. Vigopor

   Apresenta uma página com HTML 4.01 Transitional, mas apresenta alguns problemas. Sem Flash ou sem JavaScript não há navegação. Além disso usa tabelas para criar a disposição do sítio.

3. Ivo Gomes
   1. Portal das Curiosidades
   2. Sítio de Ivo Gomes

   O Design não é há prova de bala, se ampliarmos o texto meia duzia de vezes ficamos com um menu funcional mas com mau aspecto

   Um dos melhores sítios que conheço, por um profissional

   Já agora excelente artigo sobre prototipagem em papel

4. Vitor Costa
   1. Nova Esfera??

   Existem ligações que usam o mesmo texto para apontar para recursos diferentes. Algumas inconsistências no CSS. Não se pode ampliar muito fica tudo sobreposto. O excesso de controlo conduz à sua falta.

Os web designers/responsáveis pelo desenvolvimento de sítios que têm sítios em conformidade poderiam inscrever-se de modo a darem mais visibilidade a esse facto. Aqueles que se tenham inscrito e cujos sítios tenham deixado de estar conformes deviam ter a ombridade de retirarem os seus sítios da lista.

Porque acham que não estou inscrito, porque sei que o design não é meu e porque há páginas que sei de antemão que não estão conformes.

Web e Dislexia

Concepção de páginas web para leitores dislexicos

A chegada da WWW aos ecrãs dos nossos computadores significa que sofre das falhas de qualquer novo meio:

• A generalidade dos sítios web é construído com excesso de pressa
• Os web designer são relativamente novos no meio
• O texto é frequentemente apresentado num formato eligível, mesmo em texto branco/amarelo sobre fundo preto
• Navegar num website não é fácil
• Alguns anunciantes tratam de arranjar algo para chamar à atenção mesmo que seja irritante
• Alguns designers vêm as páginas web como perítos de computadores em vez do ponto de vista de pessoas normais que leem as suas páginas
• Preseume-se que todas as pessoas que visitam as páginas sabem/podem usar deligentemente o seu computador
• Os designers são tentados a criar formas de levar as pessoas a manterem-se no sítio em vez de fornecerem ligações úteis que levem as pessoas a visitar outras fontes de informação
• e em último lugar, a generalidade das páginas na web foi/é construída por homens, (por acaso gostaria de ver mais páginas concebidas por mulheres)! Falta um pouco de percepção feminina e empatia.

Largura de coluna

Nada há de pior do que ler aquele texto que ocupa todo o espaço disponível no ecrã (da ponta esquerda até ao extremo direito). Há medida que os olhos tentam varrer o ecrã torna-se extremamento difícil ler a linha seguinte. O ponto de fuga perde-se no mar de texto. Exemplo 1 Exemplo 2

Claro que é muito mais fácil de ler a coluna mais estreita, com cerca de 60 a 70 caracteres do que o texto mais largo. É por esta razão que os jornais usam colunas.

Justificado ou não?

O Texto justificado é aquele em que as palavras são espacejadas pelo processador de texto de forma a que ambos os lados esquerdo e direito de cada coluna sejam linhas rectas. O texto não justificado - como o desta página - deixa uma arestas escadeada ao longo do lado direito.

Para um leitor dislexico, o texto justificado, que tem espacejamento mal distribuido entre palavras, cria padrões visuais de espaço em branco que são difíceis de ignorar. Esses espaços distraem o leitor que deixa de saber onde está a ler.

O espaço não justificado é muito mais fácil de ler, embora não esteja na moda em algumas revistas de design, ou pretenções a tal.

Cor do fundo

Alguns leitores dislexicos são particularmente sensíveis ao contraste do texto num fundo branco. Isto pode provocar um movimento aparente e a desfocagem do texto.

Pode evitar-se esta dificuldade se não se usar fundo totalmente branco. Algo como backgound-color: #ffffE5; é suficiente. O texto pode ser mais difícil de ler se for escrito sobre um padrão. (Exemplo)

Para páginas que sejam usadas frequentemente por dislexicos adultos ou adolescentes, pode ser adicionado um comutador de fundo de página, como o existente no cimo desta entrada.

Tipos de letra

Infelizmente a generalidade dos programas de computador por omissão usam letras com serif, como a Times New Roman. Este tipo de letra é tradicionalmente associada à impressão. Uma letra com serif é aquela cujas extremidades têm variação de espessura de traço.

A utilização de um tipo de letra como o "Arial" permite uma página mais clara, para dislexicos.

Tamanho do tipo de letra

Os ecrãs estão cada vez maiores, mas a maior parte das pessoas continua a ver às páginas da web em monitores pequenos. É difícil ler um texto com tamanhos demasiadamente pequenos.

Evitar itálicos

As letras em itálico estão ligeiramente deitadas e são normalmente usadas nos livros para dar enfâse a algo. Contudo, quando vistas num monitor por uma pessoa dislexica são difícies de ler.

No caso da letra ser de uma tamanho muito pequeno tornam a sua leitura impossível.

É preferível realçar palavras usando negrito.

Imagens e Fotografias

Não precisa ser disléxico para saber que uma página com imagens é mais agradável de ser vista do que uma só com texto. As imagens ajudam a quebrar a página em pequenas porções e para um disléxico, dão um estímulo visual imediato e uma memória visual para o futuro.

Pode ver a desilusão na cara de uma criança quando chega a uma página sem imagens. Infelizmente desenvolvemos a opinião que livros com imagens/desenhos são para as crianças, os adultos lêm livros sem imagens. Pode ser apropriado em certas circunstâncias, mas mesmo num texto académico é um alívio ver um gráfico! (Mau exemplo)

Caixas de Texto e Balas

• Podem ser usadas caixas de texto e balas de forma a enfatisar ou realçar aspectos importantes.
• Servem ainda para quebrar um secção extensa de texto denso.
• As balas servem ainda para realçar aspectos chave, em especial se estiverem separadas por espaço em branco extra para ajudar a clarificar.

Imagens em movimento

Imagens a piscar distraiem não só pessoas com problemas visuais, mas todos nós.

Um sentido de direcção afecta os leitores dislexicos. Quantas vezes já tivemos problemas com um web designer "excessivamente criativo".

A regra de outro é haver uma lista de ligações simples em cada página ligando a todas as outras páginas ou secções do sítio

Frases curtas

Frases alongadas contêm mais do que uma ideia. É perfeitamente possível repartir frases compridas criando frases mais curtas e simples. Isto não torna as frases intelectualmente inferiores.

As mesmas ideias podem ser traduzidas claramente em frases curtas. Isto dá um intervalo a um leitor dislexico após cada frase. Não há limite de comprimento fixo para uma frase complicada e comprida que de tão comprida o nosso cérebro deixa de interpretar. Um bom exemplo

Parágrafos curtos

Os artigos dos jornais são normalmente bons exemplos de como se deve repartir o texto para melhorar a legibilidade.

Por vezes os artigos são feitos de forma a que haja parágrafos a cada frase.

Tal pode não estar de acordo com as convenções de Português correcto ou de escrita de ensaios, mas tal é outro assunto.

A prioridade quando se lê um jornal ou uma página da web é legibilidade e os parágrafos - mesmo os com uma linha só - devem ser sempre espacejados com uma linha em branco entre cada.

Escrever para programas de leitura (tecnologias assistivas)

Os leitores dislexicos podem ler as suas páginas de web usando leitores de ecrã. Esses programas têm limitações e portanto devem ser seguidas algumas linhas de orientação:

1. Se tiver um ponto final nos cabeçalhos (h1 a h6) tal faz com que a voz faça uma pausa e baixe o tom no final;
3. Use ponto e vírgula, virgulas ou ponto finl após elementos numa lista com balas iniciais, caso contrário podem ser lidas como texto contínuo;
4. Não escreva palavras só com maísculas pois podem ser lidas como letras individuais pelo programa;
5. Separe os elementos de uma lista com balas com espaço adicional;
6. Use um ponto parágrafo após uma ligação para o separar do texto que se lhe segue.

Bibliografia

Guia de Estilo da Associação Britância de Dislexia.

O estilo na qual esta informação foi produzida de forma a facilitar a compreensão pelo leitor. O formato com que se apresenta informação pode torná-la acessível e será vital se a informação contida é para ser compreendida por todos

Uma perspectiva de um disléxico sobre acessibilidade de conteúdo electrónico.

Cobre as quatro áreas principais de acessibilidade: apresentação, conteúdo, estrutura e navegação

10 linhas de orientação para melhorar a acessibilidade para pessoas com dislexia.

Bases para a melhoria da ligebilidade e acessibilidade por pessoas dislexicas

Erros Comuns

Erros Comuns

Quando pertencemos a uma lista de correio tão específica como a CSS-D esperamos não ver a não ser por parte de principiantes (sem desprimor para eles, visto todos o termos sido e alguns assim se manterem), dizia que esperamos não ver código como este

.caixa {
   border: 1px solid black;
}

#azul {
   background-color: blue;
}

#encarnado{
   background-color: red;
}

Pois não será normal só haver um elemento azul e um elemento encarnado numa página, nem será normal dar nomes a class ou id que tenham a haver com o seu aspecto visual, mas sim nomes que tenham a haver com a sua funcionalidade.

Molly Holzschlag mencionou num artigo sobre como atribuía nomes a estes atributos estes atributos indicando no mesmoa livro/artigo as desvantagens de dar nomes de acordo com a apresentação.

Treehouse #2

Saiu o #2 do Treehouse

Neste número são incluídos textos de Ryan Campbell (código), Alex McClung (design), Nathan Smith (negócios), entrevistas com Peter-Paul Koch, Lisa McMillan, Josh Williams e críticas de livros "Foundations of Ajax", "Thinking with Type", "The World is Flat".

Tabelas ou Disposição CSS

Parece haver uma batalha a decorrer entre web designers sobre a utilização de tabelas em arranjos para a web. Os proponentes da utilização de tabelas normalmente referem-se à compatibilidade com os navegadores e à rapidez da concepção dos sites. Os oponentes acham que a utilização de tabelas para arranjos (disposição de elementos visuais) não é conforme os web strandards e a acessibilidade da web. Para se puder perceber como começou esta polémica necessitamos de relembrar a história do HTML e dos arranjos.

O controlo do estilo visual de uma página da web por tabelas nunca foi algo intencional por parte dos criadores do HTML. Na sua opinião só serviam para reproduzir dados com colunas e linhas. Não era um mecanismo para resolver necessidades relativas a arranjos mais elaborados, mas alguns web designers mais inventivos descobriram que podiam usar tabelas para criar arranjos nos quais tivessem mais controlo.

Desde essa altura os web designer têm vindo a usar (incorrectamente) regularmente a linguagem HTML, principalmente por necessidade. Contudo no final dos anos 90 o W3C introduziu as folhas de estilo em cascata (CSS). As CSS tornavam possível a aplicação de estilos a documentos HTML. Os navegadores rapidamente começaram a integrar suporte para as CSS, e os web designers começaram a aplicar estilos simples no seu HTML, como o tipo de letra, a cor, as cores do fundo e as imagens. Contudo o uso de arranjos CSS (em particular arranjos com colunas) não se espalhou até muito mais tarde.

Ao longo dos anos houve um movimento para "purificar" o modo de codificação dos websites. Num esforço de criação de web standards que dão uma abordagem lógica e que dão acessibilidade à web para leitores de texto, bots, dispositivos móveis e muito mais. Um novo padrão foi criado. Um padrão que anda à volta da utilização adequada de XHTML e CSS. O XHTML deve ser codificado de forma a oferecer uma estrutura lógica para o conteúdo enquanto o CSS deve ser usado para criar uma concepção gráfica única.

Há várias razões para que os web designers devamd deixar de usar tabelas para arranjos e adoptarem o uso de CSS para controlo dos arranjos:

• Conformidade com os padrões de web do W3C
• Todos os navegadores modernos suportam CSS para controlo de disposição (embora o IE necessite por vezes de remendos)
• Se bem codificado, as CSS tornam alterações globais fáceis de aplicar
• A implementação adequada de conteúdo em documentos XHTML, com o uso de CSS só para estilo e disposição ajuda a criar websites acessíveis para pessoas com certas incapacidades
• As páginas podem ter muito menos código, tornamdo-as mais ligeiras de for usado XHTMl e CSS (com poucas excepções)
• O principal argumento para continuar a usar tabelas vem dos maus hábitos e de alguma complacência. Normalmente diz-se que é mais fácil usar tabelas em especial pela necessidade de utilizar remendos/truques para uma reprodução adequada no IE, embora sendo verdadeira esta afirmação há um momento a partir do qual temos que começar a usar padrões para "obrigar" os produtores de navegadores a evoluírem.

ALA - 207

A List Apart 207

Saiu o número 207 da A List Apart, para pessoas que constroiem sítios na web. Neste número são apresentadas consequências inesperadas - tanto positivas como negativas - da concepção de interface comum e de selecção de opções de acessibilidade.

Andy Hagans diz-nos não ser coincidência que os motores de busca gostem de sítios da web altamente acessíveis. Ao concebermos sítios acessíveis, estamos já a usar uma técnica de optimização para motor de busca. Hagans explica ainda outra razão para ter em conta a acessibilidade.

Nick Usborne, pergunta-nos se testamos as nossas concepções? Se não, Nick Usborne, gostaria que nos responsabilizassemos pelas opções de concepção e um efeito quantificável que tais opções podem ter nos sítios web e nos negócios.

O artigo repescado é de Kevin Potts e trata de conselhos sobre a criação de um negócio evitando os erros cometidos por ele.

A colheita do dia

Se ontém foi um dia de boa colheita, na minha opinião, hoje parece que não está pior

4 de Novembro de 2004

Dulce Pontes em Stanford

7 de Outubro de 2005

Google Advertising Patents for Behavioral Targeting, Personalization and Profiling

3 de Novembro de 2005

Google Patent : Organic Results Ranked by User Profiling

Sem data inicial

Um interessante projecto de investigação

Sem data inicial

Direitos fundamentais

AJAX-VI

Galeria de Imagens

No sítio DHTML Nirvana colocaram um Guia Ajax que usa ajax para se ir carregando (com um pouco de pisca pisca em alguns navegadores!). O guia começa com os fundamentos das técnicas Ajax e, gradualmente, à medida que as páginas são voltadas, vai caminhando para coisas mais complexas terminando numa galeria de imagens.

AJAX-V

Lista de Tarefas com XForms

Eric Bruchez da Orbeon criou uma aplicação de Lista de Tarefas. Implementa um interface de utilizador dinâmico totalmente criado em XForms, sobre um motor OPS XForms.

Este exemplo ilustra muitas das características do XForms tais como:

• xforms:repeat aninhados
• Uso de "relevant" para reprodução condicional de controles
• Escrita que permite formatação automática de datas
• Uso de xforms:submission com "instance="replace", aqui para chamar um serviço capaz de formatar um documento XML em HTML
• Uso de instâncias múltiplas
• Uso de xforms:setfocus e xforms:setindex

Pode analizar a aplicação: Lista de Tarefas.

Pode ver o código original da aplicação: código original de Lista de Tarefas.

AJAX-IV

Struts

Struts é o avô das infraestruturas Java para web e embora tenha deixado de estar na moda como as infraestruturas JavaServer Faces, WebWork, Tapestry, ... ainda há muita gente a escrever aplicações com Struts.

Paul Browne escreveu um artigo de introdução chamado "Sprinkle Some AJAX Magic in Your Struts Web Application."

O artigo foca o lado do cliente ajax, em vez da integração com Struts.

Concepção da sua Aplicação Ajax

Paul Browne

O rascunho do JavaScript acima pode aceitar o modo de utilização do Struts na maior parte das aplicações incluindo aquelas que são muito mais complexas do que a do nosso exemplo (muito simples). Contudo pode achar que os pontos seguintes podem tornar mais fácil escrever e usar o seu código:

• Para evitar código duplicado, podemos frequentemente usar a mesma "Struts Action" e o JSP para o pedido inicial (isto é mostrar a totalidade da página) e o AJAX (actualizar parte da página and JSP for the initial request (i.e., show full page) and the AJAX (update part of page) requests.
• Na classe comum (controlador), decidir que secções da página JSP (todo o JSP ou só parte dele) necessita de ser enviada ao navegador. Ao estabelecer indicadores seja na sessão do servidor web ou ActionForm, a página JSP sabe que secções necessitam de ser reproduzidas.
• No JSP, usar marcadores Struts ou JSTL para decidir se necessita de reproduzir uma secção HTML ou não. Pode descarregar uma versão deste projecto já com capacidade Ajax aqui: struts-Ajax.zip

AJAX-III

Ajax

Monitorização para usabilidade usando técnicas Ajax

Eric Pascarello recentemente escreveu uma entrada sobre a utilização de técnicas Ajax para monitorização de acções de utilizador para captura/registo de erros. O aspecto básico é que vai contra a corrente normal de que o ajax pode ser usado para praticar o mal "espiar o utilizador" usando o ajax para registar todas as acções do utilizador para poder testar em profundidade quando este visita uma página para testar e detectar erros. Eric está a desenvolver uma ferramenta para reter a totalidade das acções do utilizador, registá-las e potencialmente efectuar uma reprodução das mesmas para ver onde ocorrem erros. Isto pode ajudar a evitar o problema de algué dizer "Não me lembro a aplicação simplesmente rebentou!"

Pode ser uma ferramenta para o laboratório de usabilidade do pobrezinho . Se puder reproduzir a interacção do utilizador com a página, pode observar exactamente onde e o que é que ele clicou e onde é que a sua aplicação funciona e onde é que não. Uma ferramenta deste tipo não deve ser de desenvolvimento simples mas pode ajudar nos testes e monitorização de aplicações Ajax

Que dia

Que dia

netvibes.com start.com live.com Maps Yahoo Infraestruturas AJAX Open Source com Suporte para Serverside Java eHub

Microsoft contra o Vale da Sílica

Produto	Concorrência
Windows Live	Yahoo,Google, AOL,Salesforce.com, Zimbra
Office Live	Google, 37Signals
Live Messenger	Skype-eBay, Friendster, Plaxo, AIM, Google Talk, Yahoo, Google (Sidebar), Apple
Microsoft Gadgets	Widgets
Microsoft Maps	Google, Yahoo, Mapquest*, etc

O único que se pode usar cá mas de facto não tendo interface tão moderno quanto os outros.

AJAX-II

AJAX

Parece que os desktop virtuais estão novamente na moda. Live.com, start.com , netvibes.com, protopage.com, etc...

Visualmente são quase todos funcionais (no caso das entradas da microsoft só parcialmente e num caso não em firefox) e agradáveis. Podemos em todos eles arrastar, largar, adicionar e apagar novas "secções". No caso do protopage e do netvibes a funcionalidade é custumizável e persistente (mantendo-se para as sessões seguintes).

Por enquanto as aplicações são limitadas no caso da protopage a notas (substitutos electrónicos dos post-it), listas de tarefas a executar, ligações favoritas e buscas rápidas, nas ofertas da microsoft podemos ainda assinar notícias, ver a metereologia (inclui Lisboa e outras localidades aqui à volta) e por exemplo embeber o nosso correio (hotmail ou live).

Construção de acessibilidade universal

Construção de acessibilidade universal e lista de verificação

Esta secção trata de assegurar que um website do governo (UK) é desenvolvido para servir a maior audiência possível usando o mais alargado número de sistemas (plataformas de hardware e software) e que as necessidades dos utilizadores com incapacidades são levadas em linha de conta.

Não podemos contar que os nossos utilizadores tenham tecnologia padronizada, assim, para assegurar o acesso à nossa informação na web o ónus está do lado dos nossos administradores da web para levar a mensagem para benefício de todos.

É muito importante que a organização do seu sítio da web seja centrado no utilizador e usável desde o início mas mantenha o nível de acessibilidade e usabilidade ao longo da sua existência.

Utilize cada um dos pontos de verificação para assegurar que as suas páginas de web estão conformes estas directrizes.

Diretrizes Nucleares

Lista de Verificação
• Mantenha as páginas simples
• Seja consistente ao longo de todo o website
• Utilize o HTML como formato de informação por omissão
• Não devem ser usados métodos específicos de um navegador num website
• Usar um mínimo de imagem - usar imagens de pequenas dimensões se possível
• Não dependa da cor para transmitir informação
• A cor do texto deve contrastar sempre com a cor do fundo
• Use HTML para estruturar o documento, não aplique estilo
• Use Folhas de Estilo em Cascata para formatar e dar estilo aos elementos fundamentais do website
• Os tamanhos dos tipos (de letra fonts) devem ser possíveis de alteração pelo utilizador final - não os defina de forma absoluta
• Qualquer cor deve ser passível de alteração pelo utilizador final
• Todas as imagens importantes devem ter um atributo "alt" e descrição
• As descrições do atributo "alt" devem ter significado
• Uma barra de navegação, em texto, deve ser usada ao mesmo tempo que um "salto à navegação"
• Devem ser fornecidos métodos alternativos de navegação para quem não possa usar um dispositivo de orientação
• Se usados imagemaps então têm que ser no formato do lado do cliente
• Deve ser dada uma alternativa em texto se forem usados imagemaps
• É obrigatório fornecer uma versão alternativa em texto de qualquer informação fornecida em formato áudio ou vídeo
• Qualquer informação que seja fornecida que exija um plug-in deve também ser fornecida em HTML
• Todas as páginas devem estar conformes o padrão WAI nível A
• Os logos WAI apropriados devem ser apresentados na página de entrada de uma organização para ilustração da conformidade com as recomendações W3C

Sumário

Existe um mito que o desenvolvimento de websites acessíveis e de páginas inclusivas seja caro, que tenham que ser chatas e aborrecidas, que tenham de ser escritas para o menor denominador comum - tal não é verdade! Também não é verdade que os utilizadores tenham que ver uma página web da forma que um designer a pensou. Com a proliferação de navegadores, tamanhos de ecrãs, profundidades de cor e outras preferências do utilizador não é possível frequentemente que uma página seja vista da mesma forma por todos.

O que é importante é que os utilizadores devem poder ver uma página da forma que desejem ver com o que equipamento que tenham disponível e evitar más experiências que resultem em redução de visitas repetidas.

A integração da acessibilidade no processo de desenvolvimento de websites cria websites de forma eficiente que trabalham correctamente para o maior número de pessoas na maior parte das situações - isto significa mais utilizadores. O desafio aos responsáveis pelo desenvolvimento de web é a criação de páginas que sejam simultaneamente visualmente apelativas e completamente acessíveis para um espectro de utilizadores alargado.

Estamos a entrar num mundo em que gerir um número diferente de versões do mesmo conteúdo se irá torna num padrão. Irá provavelmente fornecer conteúdo diferente a meios diferentes tais como dispositivos móveis. Irá provavlemente conceber e escrever conteúdo de forma a comunicar com diferentes audiencias também. O advento da banda larga significa que o conteúdo multimédia se irá tornar cada vez mais apropriado.

Igualmente, para tornar um website inclusivo, há necessidade de existirem alternativas para suportar pessoas e sistemas com capacidades diferentes. Não se trata só de pessoas com incapacidades. Alguns sistemas corporativos estão protegidos com firewall para extrair conteúdo activo. A acessibilidade é também algo quando se comunica com uma audiência de negócios.

• Se forem usados frames, é necessário usar um elemento noframes e cada frame dentro do frameset deve ter um título.
• Os scripts e as applets devem ser complementadas por um elemento noscript para aqueles utilizadores que acedam com navegadores com scripting indisponível ou com firewalls que o bloqueiem.
• é necessário fornecer equivalentes textuais, ou transcrições a elementos não textuais - multimédia ou informação apresentadas de forma gráfica
• Páginas alternativas textuais devem ser raramente necessárias e não são consideradas boas práticas. Se forem usadas páginas só de texto então o seu conteúdo:
  • Deve ser tão completo e amplo quando a de conteúdo gráfico
  • Deve ser actualizada em simultâneo
• A cor não deve ser usada como única forma de transmitir informação
• Navegação - os utilizadores invisuais devem ter meios alternativos de interação com menus, barras de ferramentas e elevadores, ligações etc

Web Standards em Portugual

Web Standards em Portugal

Por vezes sou um chato em relação à utilização de web standards e da importância dessa utilização. Não me preocupo só com os aspectos formais da questão mas preocupa-me a utilização por exemplo de html (ou xhtml) que não esteja conforme os standard.

O problema é que normalmente a uma má (lei-a-se não conforme os standards) utilização de elementos e/ou atributos no html sucede uma má experiência de utilização por parte dos utilizadores do sítio.

Dizendo de outra forma validar html e/ou css não deve ser um fim mas um meio para alcançar algo. Isto não significa que não possa haver situações onde não haja validação. Agora coisas básicas como um charset mal indicado, um DOCTYPE mal indicado não são aceitáveis.

Por exemplo quando se quer massificar a utilização das declarações electrónicas no ministério das finanças devia ter-se em conta que nem toda gente tem instalado JAVA no seu computador, nem todas as pessoas chegam à página das declarações da mesma forma. A necessidade de scripting aparece como uma mensagem ao visitante "o seu navegador não tem capacidade de scripting ou esta está desactivada". O que devia suceder era haver conteúdo alternativo em seu lugar e não isto (mas é melhor que o caso que me trás hoje aqui). Ao dificultar a um certo número de pessoas a usabilidade do sítio está-se de facto a fomentar a sua não utilização. Se um dia for obrigatória a entrega de todas as declarações por via electrónica espero que se lembrem de todos e não façam como a FEMA nos EUA que usou formulários que só podiam se preenchidos no IE para pessoas que pedissem ajuda na sequência do Katrina.

Se o computador estiver por detrás de uma firewall, que extirpe elementos activos, podem mesmo não ter acesso a nenhum dos conteúdos activos existentes nesta página e não há uma degradação que seja aceitável.

O Ministério da Saúde

O ministério da saúde está agora a construir a sua nova presença na Web, não faço ideia se têm nesta nova versão este tipo de coisas em mente. Espero que não usem a técnica no sítio da Direcção Geral de Saúde, sem javascript, página em branco.

O respectivo construtor masterlink.pt parece ter muito cuidado com o aspecto gráfico esquecendo que a concepção de páginas web ultrapassa em muito o aspecto. Esta estratégia provoca problemas para quem necessitar ampliar o texto, mesmo que tenha o JavaScript activo.

Ou seja o código até pode ser de 1ª água (não sei porque não o verifiquei ainda) mas se verificarem as regras de acessibilidade e usabilidade (quem não tem acesso nem sequer pode usar) é dito que no caso de um conteúdo importante ser obtido com um script se deve fornecer uma alternativa (noscript). Parece-me que o conteúdo (todo neste caso) do sítio é a sua razão de existência, pelo que não me passa sequer pela cabeça que se fez um sítio para só ser visto com JavaScript activo. Por acaso adoraria ser mosca.

Realmente o sítio da Direcção geral é um sítio com frames (gerados pelo JavaScript). Não entendo que razão possa levar uma entidade pública a criar/deixar criar um sítio deste género. Mas deve haver alguma que não seja pura incompetência do dono ou excesso de zelo na obfuscação do conteúdo.

Já repararam que uma das regras básicas de construções de sítios governamentais numa série de países a primeira coisa que têm é uma exigência de simplicidade...como podem ler nesta minha tradução apressada: construção de acessibilidade universal do sítio do governo de sua majestade.