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

• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• Video Tutorial #9 – Implementando a home de um site
• Nem só de client-side vive um site
• Performance do seu CSS

O HTML5 ainda é um rascunho. Ele está sendo discutido entre o WHATWG e o W3C. Diversos pontos podem ser modificados ainda, por isso é interessante que você entenda e fique por dentro das discussões para que você atualize seu código quando necessário.

Um dos grandes objetivos do HTML5 é que ele seja retrocompatível. Isso evita o retrabalho de código e faz com que a web retome o rumo da semântica e do código enxuto. Vamos às mudanças:

O elemento B passa a ter o mesmo nível semântico que um SPAN, mas ainda mantém o estilo de negrito no texto. Contudo, ele não dá nenhuma importância para o text marcado com ele.

O elemento I também passa a ser um SPAN. O texto continua sendo itálico e para usuários de leitores de tela, a voz utilizada é modificada para indicar ênfase. Isso pode ser útil para marcar frases em outros idiomas, termos técnicos e etc.

O interessante é que nestes dois casos houve apenas uma mudança semântica. Provavelmente você não precisará modificar códigos onde estes dois elementos são utilizados.

Voce utilizará o SMALL para fazer literalmente os “letras miúdas” de um documento legal, comentários gerais ou até mesmo aqueles pequenos comentários e dicas que colocamos em campos de formulários e etc.

O HR virou um parágrafo de quebra. Ou seja, ele passa a ter a mesma importância do parágrafo, mas em um nível temático para quebra de linha.

Os elementos abaixo foram descontinuados por que seus efeitos são apenas visuais:

• basefont
• big
• center
• font
• s
• strike
• tt
• u

Como já era conhecido por alguns, os inputs ganharam novos valores no atributo TYPE. Estes novos valores permitem que browsers e outros user-agents melhorem a experiência do usuário, mostrando calendários e permitindo integração com agenda de contatos e etc. Permite também que os dados possam ser submetidos para o servidor com um formato específico. Valores como TEL, URL e EMAIL já tem efeitos em smartphones como iPhone:

• tel
• search
• url
• email
• datetime
• date
• month
• week
• time
• datetime-local
• number
• range
• color

Os elementos abaixo não foram incluídos na especificação porque não tiveram uso entre os desenvolvedores ou porque sua função foi substituída por outro elemento:

• 1

  acronym

  não foi incluído porque criou um bocado de confusão entre os desenvolvedores que preferiram utilizar a tag

  1

  abbr

  .

• 1

  applet

  ficou obsoleto em favor da tag

  1

  object

  .

• 1

  isindex

  foi substituído pelo uso de form controls.

• 1

  dir

  ficou obsoleto em favor da tag

  1

  ul

  .

Este atributos foram descontinuados porque modificam a formatação do elemento e suas funções são melhores controladas pelo CSS:

• 1

  align

  como atributo da tag

  1

  caption

  ,

  1

  iframe

  ,

  1

  img

  ,

  1

  input

  ,

  1

  object

  ,

  1

  legend

  ,

  1

  table

  ,

  1

  hr

  ,

  1

  div

  ,

  1

  h1

  ,

  1

  h2

  ,

  1

  h3

  ,

  1

  h4

  ,

  1

  h5

  ,

  1

  h6

  ,

  1

  p

  ,

  1

  col

  ,

  1

  colgroup

  ,

  1

  tbody

  ,

  1

  td

  ,

  1

  tfoot

  ,

  1

  th

  ,

  1

  thead

  e

  1

  tr

  .

• 1

  alink

  ,

  1

  link

  ,

  1

  text

  e

  1

  vlink

  como atributos da tag

  1

  body

  .

• 1	background

  como atributo da tag

  1

  body

  .

• 1

  bgcolor

  como atributo da tag

  1

  table

  ,

  1

  tr

  ,

  1

  td

  ,

  1

  th

  e

  1

  body

  .

• 1

  border

  como atributo da tag

  1

  table

  e

  1

  object

  .

• 1	cellpadding

  e

  1	cellspacing

  como atributos da tag

  1

  table

  .

• 1

  char

  e

  1

  charoff

  como atributos da tag

  1

  col

  ,

  1

  colgroup

  ,

  1

  tbody

  ,

  1

  td

  ,

  1

  tfoot

  ,

  1

  th

  ,

  1

  thead

  e

  1

  tr

  .

• 1

  clear

  como atributo da tag

  1

  br

  .

• 1

  compact

  como atributo da tag

  1

  dl

  ,

  1

  menu

  ,

  1

  ol

  e

  1

  ul

  .

• 1

  frame

  como atributo da tag

  1

  table

  .

• 1	frameborder

  como atributo da tag

  1

  iframe

  .

• 1

  height

  como atributo da tag

  1

  td

  e

  1

  th

  .

• 1

  hspace

  e

  1

  vspace

  como atributos da tag

  1

  img

  e

  1

  object

  .

• 1	marginheight

  e

  1	marginwidth

  como atributos da tag

  1

  iframe

  .

• 1

  noshade

  como atributo da tag

  1

  hr

  .

• 1

  nowrap

  como atributo da tag

  1

  td

  e

  1

  th

  .

• 1

  rules

  como atributo da tag

  1

  table

  .

• 1

  scrolling

  como atributo da tag

  1

  iframe

  .

• 1

  size

  como atributo da tag

  1

  hr

  .

• 1

  type

  como atributo da tag

  1

  li

  ,

  1

  ol

  e

  1

  ul

  .

• 1

  valign

  como atributo da tag

  1

  col

  ,

  1

  colgroup

  ,

  1

  tbody

  ,

  1

  td

  ,

  1

  tfoot

  ,

  1

  th

  ,

  1

  thead

  e

  1

  tr

  .

• 1

  width

  como atributo da tag

  1

  hr

  ,

  1

  table

  ,

  1

  td

  ,

  1

  th

  ,

  1

  col

  ,

  1

  colgroup

  e

  1

  pre

  .

Alguns atributos do HTML4 não são mais permitidos no HTML5. Se eles tiverem algum impacto negativo na compatibilidade de algum user-agent eles serão discutidos.

• 1

  rev

  e

  1

  charset

  como atributos da tag

  1

  link

  e

  1

  a

  .

• 1

  shape

  e

  1

  coords

  como atributos da tag

  1

  a

  .

• 1

  longdesc

  como atributo da tag

  1

  img

  and

  1

  iframe

  .

• 1

  target

  como atributo da tag

  1

  link

  .

• 1

  nohref

  como atributo da tag

  1

  area

  .

• 1

  profile

  como atributo da tag

  1

  head

  .

• 1

  version

  como atributo da tag

  1

  html

  .

• 1

  name

  como atributo da tag

  1

  img

  (use

  1

  id

  instead).

• 1

  scheme

  como atributo da tag

  1

  meta

  .

• 1

  archive

  ,

  1

  classid

  ,

  1

  codebase

  ,

  1

  codetype

  ,

  1

  declare

  e

  1

  standby

  como atributos da tag

  1

  object

  .

• 1

  valuetype

  e

  1

  type

  como atributos da tag

  1

  param

  .

• 1

  axis

  e

  1

  abbr

  como atributos da tag

  1

  td

  e

  1

  th

  .

• 1

  scope

  como atributo da tag

  1

  td

  .

Há outras mudanças mais profundas, por isso sugiro que você leia esse documento inteiro: W3C HTML5 Diff.

Estes artigos também podem ajudar:

• Conteúdo, Flash e HTML
• Processos de Adoção e Padrões
• HTML5 – Mudanças na estrutura e Semântica
• Ah! O maravilhoso mundo real

Posts Relacionados

• Sections: seções do HTML5 – Parte 1
• Ah, o maravilhoso mundo real
• O que são Media Types do CSS?
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Experiência deve ter começo, meio e fim

Lembrando que você pode fazer isso facilmente com JQuery.

Suponha que você tenha o código HTML:

E o seguinte CSS:

Na linha 6, você faz com que as tags body e html tenham 100% de altura. Isso fará com que o rodapé entenda que o limite dos dois elementos seja o final da janela do navegador.

Na linha 8, defino que a largura mínima do div GERAL, que é o div que envolve todo o site, seja de 100%. E defino um position: relative; para que o footer seja referenciado por ele.

Na linha 14, eu defino um position: absolute; e bottom:0; para footer, forçando sempre para o final do div.
Se houver pouco conteúdo o Rodapé fica lá embaixo, se houver muito, o rodapé desce junto com o conteúdo.

Funciona em IE7+ e em bons browsers.

Link para o arquivo de exemplo: Footer fixo no Rodapé

Posts Relacionados

• Tutorial Tableless Básico em HTML5 – Layout de 3 colunas
• CSS3 – Abas com a pseudo-classe :target
• Convertidos do Tableless
• Introdução ao CSS Animation
• Formulário Básico em 8 minutos – Tableless form

Você pode ver o menu deles aqui.

O Código HTML do menu deles é:

				


Português
Inglês
Espanhol

Francês

Italiano

Alemão

Eu não encontrei qual seria o pedaço do CSS referente ao menu, por isso eu não vou colar aqui.

O problema da versão do menu deles é que é todo feito com imagens e usa muita tabela. Há também código CSS inline. Isso prejudica leitores de tela, prejudica Google, e manutenção.
A versão que sugerimos é feita utilizando a técnica Image-Replacement. Segue abaixo o código HTML:

Livros

Português
Inglês
Espanhol
Francês
Italiano
Alemão


DVDs
CDs
Games
Sites especiais
Eventos

Abaixo o Código CSS:

* {
	margin:0;
	padding:0;
	list-style:none;
}

.nav {padding:10px;}

.nav ul li {float:left; position:relative;}

/* Define que todos os submenus aparecem quando passarmos o mouse no LI "pai" */
.nav ul li:hover ul {display:block;}

/* Define o estilo dos links */
.nav ul li a {
	float:left;
	height:22px;
	text-indent:-9999px;
	overflow:hidden;
	background-position:center center;
	background-repeat:no-repeat;
}

/* Adiciona o background e a largura nos elementos do menu */
.nav ul li.navlivros a {width:79px; background-image:url(imagem/_topo/abas/novo_livros.gif);}
.nav ul li.navdvd a {width:79px; background-image:url(imagem/_topo/abas/b_dvds2.gif);}
.nav ul li.navcd a {width:79px; background-image:url(imagem/_topo/abas/b_cds2.gif);}
.nav ul li.navgames a {width:79px; background-image:url(imagem/_topo/abas/b_games2.gif);}
.nav ul li.navsitesesp a {width:149px; background-image:url(imagem/_topo/abas/novo_sitesesp.gif);}
.nav ul li.naveventos a {width:109px; background-image:url(imagem/_topo/abas/novo_eventos.gif);}

/** Define que a UL do submenu está escondida por default. E define o visual do submenu */
.nav ul li ul {
	display:none;
	background:#00A2B0;
	width:70px;
	position:absolute; top:22px; left:0px;
	padding:4px;
}

/* Resetamos todo o estilo dos links do submenu. Isso poderia ser evitado se o IE7 conhecesse seletores complexos ou com JQuery */
.nav ul li ul li a {
	font:13px verdana, arial, tahoma, sans-serif;
	background-image:none !important;
	text-indent:0;
	float:none;
	color:white;
}

.nav ul li ul li a:hover {text-decoration:none;}

Veja o resultado do menu reconstruído aqui.

O Submenu na versão original, eu fiz utilizando apenas CSS. Testei em Firefox e IE7/8. Funciona que é uma beleza. Sem Javascript, sem JQuery, nem nada.
Se o IE7 já conhecesse seletores complexos, não precisaríamos resetar todos os links dos submenus como fizemos na linha 35.
O Código CSS, embora pareça longo, ele está organizado para ser fácil de adicionar outros elementos.

Sempre que escrever um CSS, pense sempre no futuro. Um CSS para resolver um problema imediato, normalmente tem menos código. Mas ele resolve apenas aquele problema específico. Se você fizer um CSS abrangente e pensando no futuro, seu código fatalmente vai ficar maior. Mas você terá menos retrabalho ao fazer as alterações futuras. Eu prefiro.

Pegue aqui os dois códigos para estudar: Reconstrução Menu Livraria Cultura

Posts Relacionados

• Convertidos do Tableless
• Image-Replacement x Imagens
• O que são Media Types do CSS?
• Tutorial Tableless Básico em HTML5 – Layout de 3 colunas
• Navegabilidade em Dispositivos Móveis

Em primeiro lugar, é importante distinguir o ideal daquilo que é possível fazer. Li um bocado sobre RDF e ontologias há uns dez anos. Li “A Revolução Inacabada”, vi o RSS nascer e se tornar popular, vi as primeiras aplicações entenderem o formato. RDF falhou. Dez anos se passaram e continuamos escrevendo HTML para ser lido por navegadores e só. Há poucos exemplos de aplicações semânticas na vida real, e a maioria seria desenvolvida de uma forma ou de outra.

Há muita gente, por exemplo, definindo seu próprio padrão de XML para trocar dados com sistemas parceiros. Quantos desses estão usando RDF, com uma ontologia interpretada automaticamente por sistemas que “descobrem” os serviços um do outro? Ou seja, não há novidades nisso nos últimos dez anos.

Escrever HTML bom é importante, porque vai ajudar o Google a indexar seu site e vai facilitar a vida de quem tentar HTML parsing nele. Mas, seja sincero, você tem mesmo esperanças de que alguém vá lê-lo como XML? Vê alguma vantagem real em validar seu código como XHTML, além de provar a si próprio que fez tudo direito? E onde está a promessa dos microformats? Microformats só fazem diferença se forem usados por muita gente. Ninguém vai fazer um parser de um formato usado em apenas um site. Você consegue citar, de cabeça, cinco sites que usem microformats e não foram feitos por você? Ah, claro, não vale incluir na lista o microformats.org.

Nem RSS é um bom exemplo de aplicação de semântica XML. Existem pelo menos dois formatos populares do padrão, além do padrão Atom, que serve para a mesma coisa. E não sei de nenhum leitor de RSS de sucesso que faça parsing dos feeds como XML. O que todos fazem é ler e interpretar a string. É isso mesmo que você entendeu, quase tão bom quanto um CSV! Outro exemplo digno de nota é o SOAP, que foi criado para fornecer aos webservices a capacidade de “autodescoberta”. Você conhece alguém que use isso de verdade? Já viu algum robô que varre a web em busca de serviços e entende sozinho como usá-los? SOAP só tem a vantagem de oferecer tooltips para ajudar os programadores .Net que usam Visual Studio. Enquanto isso, lá fora, XMLRPC e REST (com JSON) estão mudando o mundo.

Por que essas tecnologias falharam, embora pareçam todas boas idéias? Meu palpite é que elas exigiam um raciocínio de longo prazo, um tipo de aposta, que é muito difícil de conseguir. Embora XHTML, Microformats ou SOAP sejam idéias muito boas, aplicá-las em seu site só vai ter valor se muito mais gente o fizer. Se você aplicar o formato sozinho vai perder seu tempo.

O que é muito diferente de, por exemplo, deixar de usar tabelas para layout, escrever bom HTML ou usar jQuery. Essas coisas lhe devolvem um benefício imediato. Se deixar de usar tabelas para layout vai ter um site mais leve e vai perder muito menos tempo quando tiver que mudar o layout, se escrever HTML bom vai ter menos trabalho para escrever CSS, para fazer o CSS mobile e o de impressão, e se usar jQuery vai escrever javascript em um terço do tempo.

Note que esses três exemplos também tiram benefícios do fato de muita gente estar usando. Há muitos bons lugares para se aprender HTML e CSS, há muitos sistemas Open Source que já trabalham gerando código bom e os buscadores entendem a semântica do bom HTML. Mas você não depende desses benefícios para tomar a decisão de uso. Quando começamos, há dez anos, a fazer layouts tableless, não aparecíamos melhor no Google e praticamente não havia sistemas gerando HTML direito. Mas o fizemos assim mesmo porque os benefícios imediatos compensavam o esforço.

É por isso que eu temo que nunca teremos uma web semântica de verdade, e estamos condenados a fazer HTML parsing para sempre.

Há exceções. RSS, por exemplo. RSS é uma sombra do que poderia, mas é um padrão de sucesso, amplamente adotado. E não pode ser explicado com minha teoria do benefício individual imediato. Se você estiver usando RSS sozinho no mundo, não terá nenhum benefício. Talvez o sucesso do RSS se deva ao fato de precisar de uma pequena rede de usuários para oferecer um grande benefício.

Você já se perguntou como foram vendidos os primeiros aparelhos de FAX? Ter um FAX só faz sentido se mais gente tiver. Foram vendidos aos pares. As empresas o compravam para trocar documentos entre a matriz e as filiais. O fato de poder trocar documentos com o resto do mundo era, no início, um “benefício adicional”. Se você precisa trocar conteúdo com um site parceiro e vocês forem os únicos usuários de RSS no mundo, terá valido a pena. Conforme a comunidade de usuários aumentava, o valor de ter RSS crescia. Muita gente começou a usar Bloglines e todo mundo queria entrar na festa.

Há alguns anos eu percorri o país com o pessoal da Locaweb comparando o modelo de adoção do RSS com o que eu imaginava que seriam os microformats. Eu estava errado. Pense um segundo no formato de reviews dos microformats. Qual o real benefício de usá-lo? Há alguma aplicação indispensável, onde você realmente quer estar, baseada em hReview? Para que você vai perder seu tempo?

Será que não estamos resolvendo o problema errado? Quando o Diego diz que bordas arredondadas são mais importantes que RDF, será que ele não tem razão? Para meus clientes, hoje, bordas arredondadas com CSS significam um site mais rápido, mais barato (menos tempo gasto recortando imagens) e, para os sites muito visitados, economia de banda. É uma diferença pequena, mas é uma vantagem. E RDF? Além de oferecer RSS, que nem vai ser lido como XML, o que eu posso fazer de real hoje com RDF para meus clientes?

Desculpe se meu raciocínio parece mesquinho. Ele é. Estou tentando ser realista. Uma das principais influências sobre as decisões humanas é a inércia, e não acredito que o mundo vá, num futuro próximo, adotar de maneira revolucionária o RDF ou mesmo o XHTML. Ainda acho essas idéias fantásticas, só não sei se são possíveis.

O realismo também me faz crer que a nova estratégia de especificações modulares do W3C é uma coisa boa. Sofremos décadas com implementações parciais do HTML 4 e do CSS 2. Agora vamos assumir a realidade inevitável. Os desenvolvedores de navegador se sentirão mais à vontade para dizer a você o que funciona ou não. E não precisamos esperar anos para a definição de um padrão. Podemos usar os recursos com os quais o consórcio já concordou hoje. Leva mesmo alguns anos para o W3C bater o martelo sobre determinado padrão, e as especificações modulares representam um ciclo de releases muito mais dinâmico.

Já temos um acordo sobre CSS Transform, bordas arredondadas, múltiplos backgrounds, repetição no DOM, validadores de formulários, SVG, DOM Storage, querySelectors e uma série de outros recursos legais. Por que esperar até a próxima Olimpíada para dizer aos desenvolvedores de browsers: “Ok, pessoal, fechamos tudo, HTML 5 e CSS 3 já são padrões, podem implementar”? De qualquer maneira, a adoção modular das especificações do W3C é inevitável. Embora a especificação tenha saído inteira, a adoção foi modular no HTML 3, no HTML 4, no CSS 2. Sabendo que não vai ser diferente mesmo, não é melhor que tenhamos bonitas tabelas de compatibilidade entre o que existe e o que cada navegador suporta?

Dá uma olhada na lista de módulos do CSS3. Você não quer esperar isso tudo ficar pronto para ter bordas arredondadas.

Posts Relacionados

• O Caminho Suave para o Tableless
• O que é Tableless?
• Sobre Internet Explorer para Mobile – Breve impressão
• Não “otimize” seu código
• O que são Media Types do CSS?

CSS Animation permite que modifiquemos propriedades do CSS e tenhamos o resultado ali, na hora.
Para isso, usaremos uma propriedade chamada transition. Essa propriedade é divida em 3 propriedades: transition-property que é a propriedade que deverá ser animada, transition-duration é quanto tempo a transição irá durar, e transition-timing-function é o tipo de transição.

Imagine o seguinte código:

O código acima faz com que quando o usuário passe o mouse em cima do DIV, o background mude de cor.

Vamos adicionar a propriedade transition agora. Note o código abaixo:

O CSS Animation entrará em ação com a propriedade transition.
Note que a propriedade tem o prefixo do Webkit, indicando que isso só funciona em browsers com este motor.

A propriedade transition tem 3 valores: o primeiro valor é a propriedade que você quer alterar. O segundo valor é o tempo que essa animação durará. O terceiro valor é tipo de transição.

Você pode fazer várias transições em, separando os valores por vírgulas. Veja o exemplo:

Neste caso, iremos animar a largura do DIV e ao mesmo tempo, mudaremos a cor de background.

Exemplo de CSS Animation

CSS Transform

Tudo isso fica mais interessante se utilizarmos algumas propriedades do CSS Transform.
O CSS Transform é uma das características do CSS que tranformam a forma original dos elementos do HTML. Por exemplo, inclinação. Veja abaixo:

No código acima, utilizei a propriedade transform com o valor rotate. Este valor rotaciona o elemento em sentido horário para um determinado grau. No caso acima, ele está inclinando o elemento com o valor de 3 graus.

Podemos fazer uma animação interessante utilizando o transform: rotate. Teste o código CSS abaixo:

O código acima fará com que o elemento gire 360 graus.

Testei no iPhone

Fiz um teste rápido no iPhone. No iPhone, a função de HOVER é acionada quando o elemento é clicado. As animações funcionam perfeitamente, com exceção do giro de 360 graus que pára no meio e o elemento volta a posição normal.

Quem tiver algum celular Nokia com browser baseado em Webkit, faça uns testes e comenta com a galera os resultados.

Ainda é um rascunho no W3C

Tudo isso ainda é um rascunho lá no W3C. Mas a Apple já propôs sua idéia de como poderia ser o funcionamento do CSS Transformations aqui:
Apple’s Proposal for CSS Transformations.

O interessante é que os browsers hoje em dia estão andando com as próprias pernas. Na verdade não apenas os browsers, mas todos os desenvolvedores. Ninguém está esperando o W3C para implementar e inventar coisas. Todos estão ajudando a pensar como pode ser o desenvolvimento web de amanhã. O trabalho do W3C está se resumindo em estudar, incluir e modificar as idéias da comunidade e de suas equipes – que por sinal, estão em mais espertas e rápidas agora.

A documentação do rascunho do W3C está disponível aqui:
http://www.w3.org/TR/css3-animations/

Há bastante coisa para se ler aqui:

• Webkit Blog: CSS Animation
• Webkit Blog: CSS Transforms
• CSS: Transition Timing Functions

Posts Relacionados

• CSS3 – Abas com a pseudo-classe :target
• Drops 3 – Duas formas de modular seu CSS
• Colocar Rodapé fixo no fim da página
• Image-Replacement x Imagens
• Centralizando um objeto na Horizontal e Vertical com CSS

Todos os dias sites e mais sites são publicados na internet e nenhum deles com um padrão de nomenclatura de classes e ids que possamos utilizar para extrair informação de maneira inteligente. O HTML 4.01 é a versão atual da linguagem básica da Web, e não é atualizado a alguns anos. Esses detalhes de semântica não podem ser supridos para sempre por tecnologias como o Microformats. A versão 5 do HTML tende a suprimir essas necessidades e também atualizar pontos antigos do HTML 4, por exemplo, formulários.

Como disse no começo deste post, a estrutura de um site não é óbvia para as máquinas. Não existe nenhum padrão de construção dos elementos para indicar o que é o cabeçalho e o que é o rodapé, por exemplo. No HTML 5, iremos utilizar um padrão de tags que nos ajudará a marcar estas estruturas. Uma estrutura conhecida é mais ou menos assim:

...
...
...
...
...

Na estrutura acima, utilizei alguns nomes de classes e ids que costumamos utilizar no dia-a-dia. eu mesmo não utilizo a classe POST, uso mais CONTENT ou algo parecido. A estrutura do HTML acabará com isso. A idéia é substituir esse amontoado de DIVS por elementos que se encarreguem dessas funções, um exemplo da estrutura serial esse:

...



      ...
  

• O elemento header define o cabeçalho. Nav define o menu ou a navegação do site.
• Article define uma parte da página que tem uma composição de formulários, textos etc. Por exemplo, pode ser um post de forum, blog, comentários etc.
• O elemento Section define uma seção do layout em um determinado element. Ele pode conter um header e também um footer se preciso.
• O elemento aside consiste em envolver informações que tem algo a ver com o conteúdo principal do site. Pode ser um menu lateral, um sidebar padrão com menu, banner, busca etc…
• Footer define o rodapé do elemento ou do layout.

Entenda que agora, qualquer elemento pode ter seu conteúdo separado por seções com o elemento section. Note também que os elementos podem ter também um header e um footer independentes do resto do layout. Como na imagem.

Uma dúvida comum entre os desenvolvedores é como fazer a estruturação e distribuição das tags de títulos (h1 até h6). Por exemplo, se eu utilizei já a tag H1 no logo do site, poderei utilizar para o título do artigo? Se repetirmos muitas vezes as mesmas tags de títulos, a importância que cada título tem sobre o outro se perderá. O Google poderá indexar de forma diferente e etc.
No HTML 5 esse problema ser resolverá, porque cada section que você inicia, você poderá começar novamente uma nova ordem de títulos. Por exemplo:

Logo


Título do artigo

texto
Subtitulo

Mais texto

Dessa forma você conseguirá definir exatamente qual a importância de cada título e os leitores de tela, sistemas de busca e outras aplicações conseguirão fazer uma separação mais eficaz dos elementos textuais.

Entenda que os divs não irão deixar de existir. Você os usará em casos muito específicos, por exemplo, para fazer caixas de destaque:

Destaque 1

Texto


Destaque 1

Texto

Nesse caso estou usando os DIVs apenas por motivos de formatação. Ali não caberia um article, porque o conteúdo não é uma redação de um post, artigo e etc… Também não caberia uma section porque eu já agrupei este conteúdo dentro de uma section pai.

Para saber mais sobre isso, leia: The Elements Of HTML 5.
Irei escrever outros artigos sobre a inserção de vídeo e audio no código e uma série de outros assuntos interessantes sobre HTML 5. E o que você acha disso tudo? Deixe seu comentário!

Posts Relacionados

• Ah, o maravilhoso mundo real
• HTML 5, novos elementos e atributos.
• Sections: elemento article – Parte 4
• Sections: elemento nav – Parte 2
• Sections: seções do HTML5 – Parte 1

Hoje em dia, a maioria dessa informação tem significado. Leitores de tela e o Google conseguem distinguir o que é um título, parágrafo, ênfase, listas, etc… Mas como eles sabem o que é um telefone? Ah, sim, fazendo microformatos. Mas microformatos é uma tecnologia que veio para tapar um buraco de semântica do HTML. E esse é um assunto interessante.

Na nova versão do HTML, a 5, o pessoal do W3C está estudando novas formas de inserir significado no HTML. Hoje, só o básico é feito. Você define o que é título, parágrafo, links, endereços, e só. Com algum microformato, você consegue definir um contato, localização e outras informações.

Abaixo, segue uma lista de alguns elementos que podemos utilizar no nosso dia-a-dia para trazer mais significado para a informação dos seus sites:

a

Define a ancora de um elemento.

abbr

Define uma abreviação.

acronym

Indica um acrônimo.

address

A tag address é utilizada para conter informações de endereço e contatos.

blockquote

Blockquote define longos blocos de citação.

cite

Define uma citação ou referência a outra fonte

code

Define que aquele texto é um código.

dfn

Define que certo texto é a definição de um termo.

div, span

Div e Span definem a estrutura dos elementos. Div é um elemento de bloco e Span um elemento de linha.

dl, dd, dt

Listas de definição são feitas para criar um grupo de termos e definições. Muito usada para fazer glossários, dicionários ou entrevistas textuais.

del, ins

INS é utilizado para mostrar que certo texto foi inserido e DEL define o texto que foi deletado da redação. Isso é bastante utilizado para corrigir artigos, textos e etc.

em

Como o strong, indica uma ênfase no texto.

h1 .. h6

Grupo de títulos definidos por importância, onde o H1 é o mais importante e o H6 o menos importante.

ul, ol, li

Listas ordenadas (OL) e listas não ordenadas (UL) são utilizadas para definir e criar listas de itens.

p

Define um parágrafo.

q

Define uma citação ou reposta que não necessita de quebra de linha ou marcação de um parágrafo.

strong

Define uma ênfase, como o EM.

var

Indica uma instância de uma variavel ou argumento de programa.

Além dessas tags, podemos também trabalhar com a semântica com atributos. Alguns deles: Alt, Title, classe, cite, id, lang, longdesc, rev, rel.
Tudo isso traz mais significado ao HTML. Mas ainda não é o bastante.

Como o John Allsopp disse em seu artigo no A List a Part. Nós precisamos de tipos de mecanismos no HTML, que solucionem a necessidade dos desenvolvedores de enriquecer as informações exibidas no HTML dando significado inteligentes para os elementos. Essa é a verdadeira meta do HTML 5.

Infelizmente a adoção do HTML 5 não é tão simples assim. Temos que lembrar da regra Don´t Break the Web. Esse suporte deve ser leve, caso contrários, browsers como o Internet Explorer 6 ou 7 podem sofrer com a falta de compatibilidade com as novas características.

Posts Relacionados

• Ah, o maravilhoso mundo real
• Escrevendo um XHTML válido
• Sections: elemento nav – Parte 2
• Processos e Adoção de Padrões
• HTML 5 – Mudanças na estrutura e semântica

Essa minha iniciativa me gerou um conhecimento terrível sobre o assunto. Eu sabia muito bem o que funcionava e o que deixava de funcionar em diversos tipos de layouts. Eu descobri que TUDO é possível com CSS, em uma época que todo mundo falava que ele era limitado.
A maior parte dos problemas que eu enfrentei de compatibilidades de browsers em layouts em projetos de clientes, eu já tinha solucionado nos layouts que implementei nos estudos. E isso foi ótimo. Eu me valorizei como profissional, e depois até me chamavam de especialista… Veja só que honra. Tudo isso, porque eu não fiquei de nhê nhê nhê como alguns por aí.

Como programar, implementar XHTML/CSS também é de graça! Não tem desculpa.
Não há nada que te impeça de sentar o bundão na cadeira e escrever código. Nada.
Mas aí você pode dar a desculpa de: “- Naquele tempo nenhum site era escrito nos padrões, hoje todos são Tableless!” E eu digo: “- E daí?”.
Será que são escritos de forma semântica? Será que não tem muito código? Não há solução melhor?

A minha revolta aqui é contra aqueles profissionais que não fazem questão de aprender mais. Que simplesmente fazem apenas o que mandam e não tem o desejo de mudar o mundo em nenhum sentido.

Posts Relacionados

• Ah, o maravilhoso mundo real
• Não “otimize” seu código
• Formulário Básico em 8 minutos – Tableless form
• Informação e Formatação; As duas camadas de desenvolvimento web
• Fiat Uno e Peugeot 206

O código era o grande problema. A quantidade de código interferia diretamente na performance do site. E isso fez com que os desenvolvedores encontrassem saídas não muito agradáveis.

Era comum fazer códigos como o de baixo:

Produto
Preço


Tênis
R$230

Se transformarem em verdadeiros monstros:

Produto
Preço


Tênis
R$230

Isso tudo para economizar alguns bytes, que dependendo do site, significavam teras e teras de banda por mês. Naquele tempo, fazer isso era totalmente justificável. Precisávamos de alguma forma diminuir esse código para que o site ficasse mais rápido para o usuário e as requisições não sobrecarregassem o servidor.

Hoje isso é totalmente dispensável.

Aprendemos a utilizar o CSS e sabemos escrever HTML semântico.
A utilização dos Padrões trazem uma série de vantagens, e uma grande parte dessas vantagens são por causa da diminuição do código. Com o desenvolvimento de camadas e principalmente por causa do uso do CSS, não precisamos mais “otimizar” o código.

Mas parece que os desenvolvedores gostam de coisas complicadas. Esse mal costume de otimização de código ainda existe, e hoje querem otimizar o CSS. Eu acho totalmente inútil. O CSS foi feito para controlar o visual do site inteiro. Ele tirou a responsabilidade de formatação que colocávamos no HTML. Seu trabalho é exclusivamente esse: controlar o visual e diagramação do site.
É normal ele ficar grande, enorme, bizarro! Sim, haverão alguns casos que o tamanho superará mais de 1000, 2000, 3000, 4000 linhas.
Dá para evitar? Claro que dá! Pense simples. Module os arquivos. Faça um planejamento. Mas NUNCA faça com que um CSS escrito assim:

div {
 padding: 10px;
 border: 1px solid #CCC;
 width: 485px;
 height: 37px;
 background: #EEE;
}

Fique assim:

div{padding:10px;border:1px solid #CCC;width:485px;height:37px;background:#EEE}

Tenha dó do seu próximo e tenha dó de você mesmo.

Se você escreve o código de acordo com os Padrões, já economizou código suficiente. Não prejudique a manutenção do site por conta dessa neura. Escreva código legível!

Há outro ponto que devemos levar em consideração: imagine que o site pese 40Kb. Estes 40Kb são compostos por 20Kb de CSS e 20Kb de HTML. O CSS tem uma característica interessante: ele é cacheado pelo browser quando visitante entra no site.
Na primeira visita do usuário ele baixará 40Kb de uma vez. Já na segunda visita ele baixará apenas 20Kb relativos ao HTML. Ele não precisará baixar os 20Kb de CSS porque o arquivo já está cacheado pelo browser.

Não “otimize” seu código CSS, nem seu código HTML. Faça apenas com Padrões Web e siga categoricamente a semântica. É a melhor otimização que você pode conseguir.

O Leonardo Caineli escreveu um artigo sobre isso. Claro, discordo da opinião dele.

[update]Depois do post o pessoal chamou a atenção para essa prática em empresas grandes. Notei que no post eu não falei nada sobre isso. Sim, concordo que essa prática, só nessa hipótese, é totalmente considerável.

Quando treinei a primeira equipe do Terra – da época do site laranjão, lembra-se? – a primeira coisa que eles fizeram foi converter a home, e eles ainda sim queriam colocar todo o CSS em apenas uma linha.

Realmente 1Kb multiplicado por milhões é coisa para caramba e não há banda que agüente. Por isso, é totalmente aceitável que sites com um porte muito grande, “otimizem” seu código. [/update]

Posts Relacionados

• Ah, o maravilhoso mundo real
• O Caminho Suave para o Tableless
• Implementar XHTML/CSS é grátis
• Tabelas semânticas
• Informação e Formatação; As duas camadas de desenvolvimento web