Tableless » html

Declarando idiomas no HTML

Diego Eis — Mon, 09 Jan 2012 10:00:42 +0000

Publicar conteúdo na web definitivamente não é a mesma coisa da publicação de conteúdo nos meios impressos. Quando imprimimos o conteúdo, temos como foco um determinado público de uma determinada região. Eu, estando no Brasil, não vou fazer uma revista em no idioma Japonês. Quando falamos publicação de conteúdo online a coisa muda de cenário. O conteúdo online pode ser acessado no mundo inteiro, não importa seu idioma. Obviamente se você conhece outros idiomas, você amplia suas possibilidades para encontrar conteúdo e novos sites.

Os desenvolvedores do mundo inteiro juntamente com os fabricantes de browsers e outros interessados, querem ter certeza que os navegadores, robôs de busca, leitores de tela e outros sistemas detectem da forma ideal o idioma correto.

A declaração do idioma no código HTML não determina a informação no encoding de caractére do texto nem a direção de leitura do texto em outros idiomas. Essas definições precisam ser declaradas separadamente.

Nós precisamos definir o idioma por alguns motivos:

Melhor pronunciação do texto em leitores de tela.
Para que os buscadores possam indexar o website no buscador do respectivo idioma. Por exemplo: não tem sentido o Google ranqueear muito bem um site em português no Google americano.
Selecionar as fonts corretas para mostrar na tela. Nesse caso para idiomas como Chinês.
Para que os browsers escolham o dicionário correto para a correção gramatical nativa em textos e formulários.
Renderizar a página rapidamente – o browser carrega o documento mais rápido quando o browser sabe qual o idioma nativo.

Definindo o idioma padrão do documento

Existem algumas maneiras que você pode definir o idioma padrão no documento exibido ou em partes do texto para aqueles termos em idiomas diferentes.

Podemos definir diretamente via metatag nativa:

1	<meta http-equiv="Content-Language" content="pt-br">

Pela Metatag podemos definir vários valores no atributo content:

1	<meta http-equiv="Content-Language" content="pt-br, en, fr, it">

Via HTTP Header:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

HTTP/1.1 200 OK
Date: Fri, 30 Dez 2011 10:46:04 GMT
Server: Apache/1.3.28 (Unix) PHP/4.2.3
Content-Location: CSS2-REC.en.html
Vary: negotiate,accept-language,accept-charset
TCN: choice
P3P: policyref=http://www.w3.org/2001/05/P3P/p3p.xml
Cache-Control: max-age=21600
Expires: Wed, 05 Nov 2003 16:46:04 GMT
Last-Modified: Tue, 12 May 1998 22:18:49 GMT
ETag: "3558cac9;36f99e2b"
Accept-Ranges: bytes
Content-Length: 10734
Connection: close
Content-Type: text/html; charset=utf-8
Content-Language: pt-br

Via atributo lang nos elementos do HTML.

1	<p>Nós utilizamos o <span lang="en">mouse</span> para navegar na <span lang="en">web</span> por meios dos <span lang="en">browsers</span>.

Assim indicamos, principalmente para os leitores de tela, quais termos ele deve ler com o idioma nativo do termo.

Temos o costume de indicar o atributo lang no elemento html logo no início do documento para indicar que todo o conteúdo contido dentro do html está escrito em um determinado idioma.

1
2
3
4
5
6
7
8

<html lang="pt-br">
<head>
<title>Título</title>
</head>
<body>
</body>
</html>

Ordem de herança

Os meios de acesso, normalmente browsers, seguem esses passos de verificação para identificar o idioma:

Verifica se elemento HTML que tem o atributo lang, se não,
Verifica se pai mais próximo ao termo que tenha o atributo lang, se não,
Verifica se o documento tem a metatag definida , se não,
Verifica se o HTTP Header Content-Language tem uma tag de idioma definido. Se não,
O idioma é tratado como não reconhecido.

O W3C recomenda que você sempre utilize o lang no elemento html para definir o idioma padrão de todo o conteúdo e também em todo o termo encontrado no texto com idioma diferente do definido como padrão.

Declarações de idioma baseados nestes atributos são importantes para a maioria das aplicações web hoje, que vão desde as corretores ortográficos embutidos diretamente nos browsers até leitores de telas que interpretam as páginas web, etc etc.

Estas possibilidades são interessantes para que possamos globalizar ainda mais nossos projetos. Imagine por exemplo um website que ensina Russo para Chineses. É interessante que possamos marcar os termos dos dois idiomas de forma que os mecanismos trabalhem adequadamente em diversos meios de acesso. Os browsers precisam identificar quando o texto está em Russo ou quando está em Chinês. Os buscadores também precisam entender essa diferença, bem como os leitores de tela.

Aos poucos vamos padronizando características que antes eram ignoradas no desenvolvimento web. Não são ações muito difíceis de aplicar. Para começar, basta colocar o atributo lang no elemento html dos seus documentos e pronto.

Referências

Artigo que explica os Charsets, encodes e tabelas de caractéres no HTML.

Veja aqui a documentação oficial do W3C que fala sobre este assunto.

O W3Schools tem aqui uma listagem dos códigos de idioma que podem usados.

Posts Relacionados

Guia de Referência de HTML5

Diego Eis — Mon, 02 Jan 2012 15:07:13 +0000

Ter sempre um guia de referência sobre qualquer tipo de linguagem é sempre bom. Ainda mais quando é completo e atual. O pessoal do WDL nos presenteou com uma série de Cheat Sheets sobre HTML5.

Os guias são divididos em 3 gráficos: Um mostra as novas tags, o segundo mostra os eventos e atributos e o terceiro mostra o suporte dos browsers.

Cada Cada um diferencia as características novas, existentes ou não suportadas do HTML5. O visual deles é bem simples e muito fácil de entender. O mais legal é que dá para imprimir e deixar à vista para quando você ou a equipe precisarem.

HTML5 Tags Cheat Sheet

HTML5 Cheat Sheet By InMotion Hosting – A Virtual Private Servers Provider

HTML5 Event Handler Content Attribute Cheat Sheet

HTML5 Cheat Sheet By InMotion Hosting – A Web Hosting Provider

HTML5 Browser Support Cheat Sheet

HTML5 Cheat Sheet By InMotion Hosting – A Dedicated Server Provider

Posts Relacionados

Nem só de client-side vive um site

Diego Eis — Sun, 28 Aug 2011 12:54:24 +0000

Artigo publicado originalmente na revista Wide em Janeiro/Fevereiro de 2011.

Estou feliz porque o mercado de client-side tem amadurecido de forma inteligente no Brasil. Empresas mais espertas entenderam a importância do código HTML/CSS/ JavaScript bem escrito. O problema é que grande parte das empresas, clientes e desenvolvedores acham que o trio HTML/CSS/JavaScript faz milagres. É certo pensar que um código bem escrito traz grandes vantagens para o projeto, mas ele sozinho não faz milages.

É errado pensar que apenas por que você escreveu código HTML semântico seu site aparecerá em primeiro no Google ou ficará mais acessível para deficientes visuais. O código client-side é apenas a porta de entrada para uma série de outras tarefas.

SEO

Para criar um projeto de SEO é preciso seguir uma série de etapas que formam um grande pacote e que só então é possível perceber as vantagens do trabalho do SEO.
O código client-side entrará como uma pequena parte do esforço. De forma bem simples, podemos listar alguns pontos importantes que precisamos tomar atenção além do HTML bem feito:

Estudo de concorrentes;
Definição de diagramação e quantidade de texto nas diversas partes do site;
Estudo de palavras chave e termos de uso;
Planejamento de landing pages, entradas e saídas;
Criação de robot.txt e sitemap.xml;
Monitoramento de palavras, visitação e buscadores;
Estudo de funil e preparação de goals;

Eu não sou um especialista do Google nem nada do gênero, mas sei que estes tópicos são importantes ao manter ou criar um website otimizado. O HTML certamente faz parte destes tópicos, mas ele não invalida nenhum dos outros pontos.
Obviamente não adianta nada fazer um bom estudo de palavraschave e marcá-las de forma errada com HTML.

Acessibilidade

Como em projetos de SEO, o planejamento de Acessibilidade precisa de uma série de etapas funcionar corretamente. No caso da acessibilidade o HTML ocupa um grau de importância muito grande, contudo, há pequenos pontos que o HTML não pode resolver sozinho. Veja alguns exemplos:

Contraste e cores do layout;
Estudo de atalhos de teclado;
Menu de navegação rápida;
Textos em tooltips, titles, alts de imagens etc;
Tamanho de botões e textos;
Arquitetura de Informação sensata e simples;

Embora algumas das tarefas sejam resolvidas com HTML/CSS, as definições e metas são pensadas pelos desenvolvedores. Qual cor, tamanho de botões e etc são decididos pelo designer e não pelo HTML. Não é incomum acharmos que apenas porque o site tem um código bem estruturado e semântico ele será bem acessado por cegos com leitores de tela ou pessoas com outro tipo de necessidade. Há tópicos que se dependem meramente do bom senso.

Se analisarmos bem as disciplinas de Acessibilidade, Usabilidade e Arquitetura de Informação, perceberemos que elas comandam a forma com que o trio HTML/CSS/Javascript devem se comportar. Há várias etapas e decisões que tomamos antes de colocarmos a mão no código. Cada um tem sua importância. Muitos erros de HTML podem ser evitados com um planejamento de Arquitetura de Informação. Muito código CSS pode ser otimizado estudando os wireframes do projeto.

Lembre-se de que o HTML/CSS/Javascript serve o conteúdo e não contrário. Eles devem trabalhar para que a informação seja bem exibida, formatada e que chegue integralmente para o usuário.

Posts Relacionados

Drops 5 – Responsabilidade Dev Front-end

Diego Eis — Wed, 20 Apr 2011 12:00:21 +0000

Qual a responsabilidade do desenvolvedor front-end? Ele precisa ser designer? Tem que aprender a programar?

Se preferir faça o download do arquivo em Mp3 ou OGA.

Se preferir faça o download do arquivo em Mp3 ou OGA. Ou inscreva no iTunes. Feed direto dos Podcasts.

Posts Relacionados

Performance do seu CSS

Diego Eis — Tue, 29 Mar 2011 13:00:27 +0000

Modular seu código CSS é uma boa prática para que o website carregue apenas o código necessário para montar a pagina que o visitante está. Por isso não precisamos carregar o código CSS que monta a página de contato uma vez que o usuário está na home, possibilitando um ganho de performance.
Podemos ainda melhorar um pouco mais nossa performance tendo atenção com a forma que escrevemos os seletores do CSS. Há algumas dicas que podemos seguir para que isso seja possível.

O seletor é a alma do CSS. É com ele que o browser procura e captura o elemento que você deseja formatar. Existem diversos seletores que possibilitam a captura de elementos em diversos cenários e necessidades. Com a atualizações dos browsers em relação a padronização do CSS 2.1 e do CSS 3, os desenvolvedores ganharam novos ferramentas e formas de capturar elementos.

Quero que você entenda que essas dicas são sugestões. Não seja um purista cabeça dura. Seja flexível e tolerante com alguns cenários que podem surgir durante o projeto. É bom sempre procurar o meio termo entre performance e velocidade de produção.

Outro ponto para pensar é que a má performance do CSS pode significar muito pouco perto de outros fatores como servidor, performance server-side, peso de imagens e outros fatores. Por isso é importante que você tenha em mente que fazendo as sugestões abaixo não é garantia de que seu site ficará super ultra rápido. =^)

Processo de leitura

O browser segue um processo de leitura muito fácil de ser entendido.
Todo o seletorer (se voce não sabe o que é um seletor de CSS, recomendo que leia isto e isto antes de continuar).

O sistema de leitura consiste em encontrar o elemento da extrema direita do seletor. Logo a leitura do seletor começa da direita para a esquerda. A medida que o browser lê o seletor, ele vai encontrando os elementos e só pára quando há um erro no seletor ou não encontra o elemento.

Tenha como exemplo este seletor:

1	ul li a {...}

Nesse primeiro momento, ao ler o elemento da direita, o browser seleciona TODOS os elementos A da página, independente se ele está ou não dentro de um LI.

“The style system matches a rule by starting with the rightmost selector and moving to the left through the rule’s selectors. As long as your little subtree continues to check out, the style system will continue moving to the left until it either matches the rule or bails out because of a mismatch.” – David Hyatt

Não use IDs ou Classes ligados a tags

EVITE:

1 2	div.content {...} div#geral {...}

RECOMENDADO:

1 2	.content {...} #geral {...}

Tente especificar os elementos

Sempre que puder tente especificar os elementos com IDs ou Classes em vez de escrever seletores longos.

EVITE:

1	nav#menu ul li a {...}

RECOMENDADO:

1	.menuitem {...}

Eu não gosto muito desta sugestão porque teríamos de colocar uma classe “menuitem” em cada um dos ítens do menu. O HTML ficaria horrível. Prefiro fazer como abaixo. Não é a melhor forma (como eu cito no próximo tópico), mas é um meio termo entre performance, flexibilidade e produção de código:

1	#menu a {...}

Não misture IDs com nomes de tags e classes

EVITE:

1 2	button#botaoverde {...} .menu#menuPrincipal {…}

RECOMENDADO

1 2	#botaoverde {...} #menuPrincipal {…}

Não coloque nomes de tags nos nomes de classes

Muita gente relaciona o nome da tag ao nome da class ou id do CSS. Essa prática pode confundir posteriormente tanto na manutenção quanto no processo de produção por pelo menos dois motivos: 1. Você pode atribuir essa classe a elementos diferentes e não somente aquele que você relacionou no nome. 2. A classe pode fazer muito mais do que estava descrito inicialmente.
Por isso é interessante que cada nome de Classe seja ÚNICA e não seja relacionada a nenhum elemento em específico.

EVITE:

1	li.selected {...}

Bom, mas não muito:

1	.liselected {...}

RECOMENDADO:

1	.selected {...}

Evite seletores filhos

Sempre tente evitar declarar hierarquia nos seletores. Sempre que puder, coloque o nome do elemento diretamente por meio de class ou id. Mesmo assim tenha em mente a limpeza do seu HTML. Se você já aplicou boa parte dessas sugestões no resto do site, você pode abrir mão em alguns lugares que poderão ser úteis como na criação de um menu.

EVITE:

1	section form#cadastro fieldset label input.Text {...}

RECOMENDADO:

1	input[type="text"] {...}

Evite seletores descendentes

Os seletores descendentes são os seletores tem menos performance no CSS.

EVITE:

1	section article h1 {...}

É bom, mas nem tanto:

1	section > article > h1 {...}

RECOMENDADO:

1	.tituloh1 {...}

Claro que é muito complexo colocar uma classe nos títulos do site, ainda mais se os títulos são gerados por outras pessoas. Por isso prefiro, dependendo do site, dependendo do cliente, dependendo de como eu acordar de manhã, utilizar a primeira sugestão, que está marcada para EVITAR. Lembre-se ache o meio termo.

Referências:

Posts Relacionados

Convertidos do Tableless

Diego Eis — Mon, 21 Mar 2011 04:47:10 +0000

Quem acompanha o Tableless desde o começo conhece a história de como este humilde website nasceu. Eu estudava e aprendia CSS com HTML de uma única maneira: praticando. Eu convertia para tableless a home de alguns grandes sites just for fun. Só para provar que a técnica era real, possível e muito melhor que tabelas. O Tableless nasceu quando eu decidi compartilhar este material para outros desenvolvedores.

Este material não estava publicado porque uma das empresas que eu utilizei como estudo me mandou uma simpática carta extrajudicial dizendo que eu estava fazendo cópia indevida e todo aquele blá blá blá e que eu devia tirar o materia deles imediatamente do ar… Eles com certeza não eram bem humorados. Com medo de outras empresas fazerem o mesmo, tirei logo todos os exemplos publicados.

Neste fim de semana estava jogando algumas coisas fora e encontrei um CD com alguns documentos destes websites convertidos. Você pode verificar e baixar os arquivos nesta página. Até segunda ordem.

Atenção:

Se você é um troll babaca que vai analisar o código só para criticar como foi feito, entenda que o código mais antigo é de pelo menos uns 6 ou 7 anos atrás… Eu faria tudo diferente.

Se você pertence a alguma empresa listada nos exemplos, tenha em mente que esse material é utilizado apenas para estudo.

Posts Relacionados

Drops 2 – A palavra Marcação do HTML

Diego Eis — Mon, 31 Jan 2011 16:07:07 +0000

Você já parou para pensar o que significa a palavra marcação da abreviação do HTML?

Se preferir faça o download do arquivo em Mp3 ou OGA.

Se preferir faça o download do arquivo em Mp3 ou OGA. Ou inscreva no iTunes.

Posts Relacionados

Escalabilidade client-side

Diego Eis — Thu, 06 Jan 2011 11:12:23 +0000

Desenvolvedores server-side estão acostumados a planejar todo o ambiente onde o sistema estará instalado. Há um bom planejamento de servidores, banco, estrutura de framework, regras de negócio e etc. Todo esse planejamento é para impedir que o projeto fique complicado e claro, funcione. Serve para que se o projeto ele passar por várias mãos, o código ainda fique legível, fique flexível e com boa performance. Na área de client-side isso quase nunca acontece. Embora a área de client-side seja bem mais simples que server-side, os problemas podem ser mais duradouros e trazer uma dor de cabeça sem fim.

Quando há um grande projeto ou sistema onde o código passará por várias pessoas, invariavelmente este código ficará complicado. Tenha em mente que complexidade não é a mesma coisa que complicado. O código pode ser complexo, o que ele não pode ser é complicado. Você tem que conseguir escalar seu código sem precisar de nenhuma (ou o mínimo) modificação na estrutura do HTML.

Existem algumas precauções que nos ajudam a manter o controle durante todo o projeto. Cada projeto merece adaptações destas precauções. Citarei aqui algumas que costumamos utilizar na Visie.

Estruturando o HTML

Não é muito difícil estruturar o HTML. Na verdade tudo o que você precisa está no wireframe. O wireframe te fornece a visão de como será o código HTML puro e simples. A estrutura básica do seu código pode ser baseada no wireframe oficial do layout onde haverá todos os elementos semânticos e importantes necessários para a produção da estrutura principal. Não há ali marcações visuais como degrades, backgrounds e etc. Você consegue enxergar o website de uma maneira enxuta. Obviamente você precisará melhorar o código posteriormente. O wireframe não te dá detalhes como: onde tem um background, onde há um gradiente etc. Por isso, o código criado no wireframe, embora seja um código simples e enxuto, pode ser que precisem de modificações.

Parece óbvio, mas eu preciso dizer que o código desta estrutura precisa ser a mais simples possível porque ela será utilizada em todo o site.

Validação inicial

Depois que este primeiro código foi feito, é necessário que haja uma validação. Essa validação pode ser feita pelo validador do W3C e por um profissional que avaliará a semântica dos elementos escritos.

Muitos desenvolvedores acham que a validação do W3C inútil. Outros são fanáticos demais e dizem que se um site não é válido ele não tem o direito de ser publicado. Os dois extremos estão errados.
Tenha em mente que o validador do W3C apenas avalia a sintaxe do seu código. Ele não avalia por exemplo a qualidade da semântica do código, logo, ele não te diz se você utilizou as tags da forma mais corret.
Mesmo assim é interessante que você valide o código logo na primera versão escrita. Assim há a certeza de que todas as outras páginas estarão sem erros, já que o código inicial será reproduzido no resto do site. Se houver algum tipo de erro ali, ele será multiplicado por todo o site e você não saberá onde se originou.

Nomenclatura de class e id

Assim como é importante ter um código HTML legível, ter um código CSS bem organizado pode ajudá-lo a produzir páginas mais rapidamente. A criação de uma nomenclatura inteligente é o ponto chave para termos velocidade na produção de novas páginas ou na manutenção das páginas existentes.

Já vi desenvolvedores que colocam nomes estranhos para elementos da estrutura principal do site como se ninguém mais fosse ler aquele código. Muitas vezes esse alguém pode ser você mesmo dali alguns meses tentando resolver um problema importante e não conseguindo porque colocou nomes nos elementos de forma aleatória.

O nome do elemento (class ou id) deve estar relacionado com o conteúdo deste elemento. Se você fará um elemento NAV que produza um menu lateral, é melhor que seu nome seja “menulareral” e não “listagemdelinks”.

Modularização do CSS

O código CSS pode aumentar de uma hora para outra. Seu arquivo pode passar de 100 linhas para 1500 em um piscar olhos. É importante que você tenha os códigos que serão utilizados na estrutura global do site em arquivos separados. Existem muitas formas para modular seu código CSS, cabe a você decidir como fazer isso de acordo com a necessidade do projeto. Sentar-se com toda equipe envolvida na produção deste código pode ajudar bastante a boa evolução do projeto.

A modularização CSS melhora a velocidade do site, já que o browser apenas carregará o código de estilo necessário para formatar a página visitada.

Criando elementos com Javascript

Existem muitas ocasiões em que é necessário escrever código HTML que servirá apenas para ajudar a formatar elementos complexos. Infelizmente ainda temos que utilizar estes elementos para dar suporte a compatibilidade visual entre os diversos navegadores. Estes elementos extras fatalmente deixarão seu código mais sujo. Uma opção interessante é que este código seja criado via Javascript evitando que o código HTML original – onde a programação server-side é aplicada e também o código que os leitores de tela e os sistemas leem – seja prejudicado. Isso nos leva a outro nível de controle que é a separação do código Javascript, modularizando os scripts que criarão o HTML dinamicamente.
Normalmente utilizo o jQuery para manipular e criar estes elementos.
Como os robôs de busca e leitores de telas para cegos não entendem Javascript, eles renderizarão apenas o código puro do seu HTML, ignorando o código criado via Javascript. Embora essa prática seja bem confortável, o seu uso não pode ser exagerado. Sugiro que você use somente para criar detalhes visuais que o CSS não dê conta sozinho ou se o site precisar funcionar em navegadores antigos.

Concluindo

Os pontos que citei ajudam a ter um código client-side sustentável por todo o processo. Em cada projeto há maneiras de aperfeiçoar estas táticas. Tente utilizá-las de forma que ajude toda a equipe envolvida e que o legado seja simples de migrar ou executar manutenções. Lembre-se que o código client-side deve ser legível e simples o suficiente para que a sua leitura em diversos meios de acesso seja possível. Lembre-se também que você não está sozinho no projeto e que diversas outras pessoas terão contato com o código nas fases subsequentes.

Posts Relacionados

Navegabilidade em Dispositivos Móveis

Talita Pagani — Wed, 17 Nov 2010 11:11:13 +0000

Um dos principais desafios ao projetar um site ou um sistema web para mobile é o tamanho em KB do conteúdo. Internet pelo celular ainda é cobrada por KB utilizados por muitas operadoras e o custo ainda é muito elevado no Brasil. Além disso, temos um espaço muito pequeno para mostrar o conteúdo. Mesmo os melhores smartphones touch-screen têm telas relativamente pequenas se compararmos com um monitor convencional ou notebook, o que cria um esforço de interação maior.

O princípio de acessibilidade para sites visualizados em dispositivos móveis é a apresentação sucinta de informações e para isso uma diretriz fundamental é utilizar corretamente as tags do HTML e fazer uma marcação adequada e semântica. Por exemplo, utilizar corretamente as tags de cabeçalho para estruturar títulos, P para parágrafos e outras recomendações que são comuns também aos sites convencionais.

Porém, deve ser minimizado o uso de tags, utilizando apenas as que forem necessárias. Por termos um conteúdo resumido e mais verticalizado, não há necessidade de muitas tags para estruturação e posicionamento do conteúdo. E, nesse ponto, entra outra questão: muitos sites disponibilizam o mesmo layout para web e para mobile, apenas acrescentando uma folha de estilo com atributo mediatype=”handheld” para adaptar a apresentação do conteúdo aos dispositivos móveis.

O mais adequado é prover uma página alternativa, com HTML e CSS próprios para a visualização neste tipo de dispositivo. Existem verificações server-side (depende da linguagem utilizada) que permitem identificar se o usuário está acessando o site a partir de um dispositivo móvel e então fazer o redirecionamento para a versão mobile.

Desenvolver uma versão mobile de seu website implica também em reduzir as informações que são apresentadas, disponibilizando apenas textos, links e imagens que sejam mais relevantes. Fazendo isto, reduzimos a densidade informacional e possibilitamos que os usuários encontrem mais facilmente as informações. Além disso, conseguimos reduzir o tráfego de conteúdo por diminuir o tamanho da página.

Outras dicas importantes sobre acessibilidade (e também usabilidade) para dispositivos móveis:

Evite o uso de javascript e flash, ainda há dispositivos que não suportam corretamente estes elementos. Mesmo para dispositivos que suportem scripts, eles devem ser utilizados apenas caso não haja outra forma de realizar uma determinada função. Scripts aumentam o consumo de energia.
O título das páginas deve ser curto e descritivo, para que o usuário identifique a página que ele está;
Prover, sempre que possível, pré-seleção para valores em campos de formulário, pois isto minimiza a quantidade de entrada de dados que o usuário deve fazer.
Quando possível, utilizar também listas de seleção, radio buttons e outros controles que não requerem digitação.
Garantir que cada formulário presente tenha um botão submit, evitando submissões por de javascript através de um evento no campo de formulário.
Reduza a quantidade de seletores e propriedades em seu CSS e, se possível, coloque declarações em uma única linha para reduzir o tamanho dos arquivos. Você também pode optar por utilizar script server-side para a compressão das folhas de estilo.
Para os textos, evite medidas absolutas e em pixels, permitindo que os navegadores ajustem o conteúdo à tela. No CSS, utilize porcentagens e medidas relativas como em, ex, bolder, larger e thick.
Especificar as dimensões exatas da imagem em pixels ajuda o navegador a continuar o carregamento da página e evitar o recarregamento depois da página ter sido exibida por completo. Os dispositivos podem perceber melhor as intenções do desenvolvedor se as margens, bordas e espaçamentos forem especificados em pixels.

Algumas destas recomendações foram obtidas no site ready.mobi com base em diretrizes do W3C.

Posts Relacionados

Afinal, o que muda com o HTML 5?

Thaiana Poplade — Wed, 15 Sep 2010 12:07:23 +0000

Você desenvolvedor web, antenado, com certeza vem acompanhando a evolução, as críticas, as observações, os elogios e, claro, os tutoriais para entender um pouco mais do que efetivamente significa esta versão “5” do HTML.
Já você desenvolvedor, que limita-se a saber que uma nova versão está a caminho, talvez ainda não tenha tido a chance de conhecer quais serão essas importantes mudanças e o que trarão de novo para as bases do desenvolvimento web.

Aproveitando esta lacuna de compreensão do assunto procuro explanar, abaixo, sobre algumas mudanças que vão ocorrer tanto nas estruturas técnicas do desenvolvimento de webpages quanto na postura e parâmetros que este profissional deverá apresentar na criação de um website.

Lendo um “guia de aprendizado rápido para HTML5”, em meio à tantas outras informações que recebo todos os dias a respeito (desde jogos à músicas), percebi que além das diversas sinalizações quanto à nova estrutura que os códigos html vão apresentar, vai ficar cada vez mais claro que o trabalho do Htmler ou Front-End Engineer estará diretamente ligado à arquitetura de exibição de informação, já que no HTML5 vamos agrupar as informações de acordo com a sua relevância tanto para o usuário, quanto para os mecanismos de busca.
Aproveitando, deixo a primeira dica: este processo vai exigir que seja realizado um estudo sobre a importância e a hierarquia das informações e como elas devem ser exibidas no site, por isso caro desenvolvedor, ampliar seu leque para conhecer o gigante mundo da arquitetura de informação para websites, pode ser um grande diferencial em seu currículo.
Além disso, conhecer um pouco melhor o conteúdo do site, sem limitar-se à ao “Loren Ipsun” no HTML5, auxiliará na construção da semântica do código e numa comunicação mais direta com os mecanismos de busca, como por exemplo, conseguir perceber mais claramente se numa lista usaremos os tipos UL, OL ou DL, levando em consideração principalmente a ordenação e subordinação das informações na tela e na leitura dos mecanismos.

Talvez caro leitor, você esteja pensando: “mas hoje, isso já é possível e deve ser feito” então, lhe explico o porque de ressaltar a importância de um cuidado com a semântica da informação nos websites: infelizmente muitos desenvolvedores limitam-se a conhecer apenas o uso de DIV’s em substituição às tabelas, afim de resolver “problemas” de diagramação de imagens e textos quando feito o cross-browsers, bem como ignoram qualquer estrutura hierárquica que a informação exibida possa ter no site, e com o HTML5, isso não poderá mais ser ignorado assim
como as incompatibilidades entre browers, também devem diminuir.

Em termos técnicos no html5, teremos a tag

que poderá ser utilizada para toda informação introdutória ou elementos de auxílio a navegação como H1, H2, etc; a tag

para utilizar em estruturas que representem a navegação do site, como os menus; as tags

para as secções da página; as tags

que vão representar uma parte do conteúdo como notícias ou novos posts de um blog; as tags

que vão representar um grupo de conteúdo com pouca relação ao conteúdo principal, mas de considerável relevância para estar presente na página – neste caso, o exemplo que podemos citar são os sidebar’s com banners ou informações de atendimento à clientes ao lado do conteúdo principal e por fim e não menos importante, as tags