Tableless » tableless

Boas práticas de Acessibilidade

Diego Eis — Mon, 23 Jan 2012 16:14:18 +0000

Preparei uma pequena (nem tão pequena assim) apresentação que mostra algumas boas práticas e técnicas sobre acessibilidade para sistemas e websites. São pequenos ajustes que podemos incorporar mesmo depois de todo o desenvolvimento pronto e que dão resultados importantes para adequação dos seus sites ou sistemas.

Apresentancao acessibilidade

Veja mais apresentações de Diego Eis

Posts Relacionados

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

Experiência deve ter começo, meio e fim

Diego Eis — Mon, 28 Nov 2011 23:55:31 +0000

Esse artigo pode parecer meio confuso, mas é apenas um pensamento que estive matutando. Não ligue se a ordem das ideias estiverem tortas e sinuosas.

Tive uma experiência muito ruim no primeiro dia de 2010: pulei na piscina com meu iPhone no bolso.
Ok, pode me xingar agora.

Depois da tragédia, ele durou rápidos 5 segundos, e faleceu. Não ligava, não apitava, não fazia nada. “Paciência”, falei para mim mesmo. No dia seguinte peguei um celular reserva que eu tinha guardado: um HTC Touch, com Windows Mobile 6 (não Windows Phone). Foi então que eu notei o porque o trabalho da Apple vicia os consumidores.

Estamos bem acostumados a utilizar um notebook ou um computador desktop, com monitor, teclado e mouse. A interface do sistema muitas vezes parece desaparecer quando se abre o navegador. A experiência de uso dos periféricos já é bastante conhecida e isso facilita muito a forma com que o usuário interaje com a interface. Há uma harmonia, se é que você me entende. A mesma coisa é dificil de acontecer quando utilizamos um dispositivo mobile. Em um dispositivo móvel você precisa de foco. Não há espaço para milhares de botões com dezenas de ações. É SIM e NÃO. É OK ou CANCELAR e mais nada. O que não é o caso do Windows Mobile. O Windows Mobile foi feito daquele jeito Microsoft. Muito, mas muito diferente do Windows Phone que está um primor. Com uma interface totalmente repensada, do zero, onde seu visual se integra com os outros sistemas da marca. Há uma homogeneidade na experiência do usuário quando ele usa a Live do XBOX, o Windows Phone e o Windows 8. A experiência é cross-platform. A Apple faz isso durante anos. E durante todos estes anos esse foi seu segredo. O famoso “eco sistema Apple”. Tudo funciona muito bem quando estamos com nossos iPhones, iPads, MacBooks e iPods. Se eu tenho um iPad, mas utilizo um PC, algo fica estranho. Funciona, mas fica estranho.

Assim como sistema dos mobiles, os sites precisam seguir a mesma fórmula de simplicidade e foco. Por isso, criar sites para mobiles é uma arte. É um jogo de prioridades. Você precisa saber o que é importante na página e focar naquilo. Há um bom trabalho de arquitetura de informação que precisa ser feito. E não se engane, as vezes é muito mais dificil desenvolver um projeto de arquitetura para mobiles do que para versões full.

O iPhone, e agora o Windows Phone, se destacam muito por conta dessa harmonia que citei acima. Há uma ligação em tudo ali. Quando você aciona o Safari, ele tem uma interface intuitiva, bem acabada e que não agride a usabilidade do site. O iPhone tem um browser 100% atualizado com os Padrões Web e isso ajuda um bocado o desenvolvimento de interfaces inteligentes.
E a Apple se preocupa com essa harmonia da qual estamos falando, ela prepara uma série de materiais que ajudam os desenvolvedores. São guias de desenvolvimento e referência com os princípios de design e usabilidade que garantem a experiência completa. Por causa disso os desenvolvedores e designers fazem ótimos apps, tornando a experiência do usuário completa e uniforme durante o uso do dispositivo.

É por isso que a vale a pena municiar os desenvolvedores e designers do mundo todo, para que a experiência não termine quando o consumidor feche o seu aplicativo ou abra o navegador. Experiência tem começo, meio e fim. A Apple se preocupa com essas etapas. Ela sabe que se o site abrir “quebrado” o consumidor vai xingar primeiro o aparelho e não site. Tudo é uma única experiência. Começa no sistema do aparelho e termina no site de um terceiro.

O resto dos aparelhos começam pecando por ter um browser ruim ou uma interface de uso complicada. Na maioria os browsers não dão suporte algum aos Padrões. Isso é um pecado. Se eu tenho um Smartphone, eu passarei mais tempo na internet, conectado, do que falando ao telefone. Esse é apenas um ponto sobre o porque um dispositivo móvel precisa ter um browser decente.

O usuário tem uma boa experiência quando consegue com sucesso a informação que procurava, sem bloqueios. Se ele consegue passar esse processo com sucesso, como se o dispositivo (mobile, desktop, notebook, leitor e tela etc) e o site/sistema fossem transparentes, aí cumprimos com o nosso dever.

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

CSS3 – Abas com a pseudo-classe :target

Diego Eis — Mon, 21 Mar 2011 17:30:03 +0000

O CSS está cada vez mais facilitando as coisas. Alguns problemas que eram resolvidos apenas via Javascript já podem ser resolvidos inteiramente com CSS. Obviamente que para alguns browsers temos que usar algum script para conseguir a compatibilidade. Mesmo assim, se for já possível utilizar as novas maravilhas do CSS 3 e outras compatibilidades que estão surgindo do CSS 2.1, faça-o já. Você com certeza vai se agradecer um tempo próximo!

Um caso muito comum na produção de sites é a construção de tabs. Todo desenvolvedor já deve ter feito pelo menos uma vez na vida um script de tabs. Com a pseudo-classe :target seus problemas acabaram.

Quando queremos relacionar um link na própria página, utilizamos o recurso de “âncora”. Quando colocamos um link com o valor assim:

Link

Falamos para o browser que ao clicar no LINK, ele deve encontrar um ponto na página chamado, nesse exemplo, nome-da-ancora. Ele vai encontrar o elemento na página que tenha um ID com esse nome e navegará a barra de rolagem até a posição deste elemento. Você já deve saber disso e já deve ter visto funcionando.

Com a pseudo-classe :target isso ganha nova vida. O :target consegue relacionar isso a um objeto de forma que se você estiver criando abas (tabs), ele mostra automaticamente a aba relacionada. Vamos ao exemplo. Primeiro faça um HTML como o abaixo.


Aba 1
Aba 2
Aba 3



		Primeira Aba
	

		Primeira Aba 2
	

		Primeira Aba 3

Note um detalhe muito importante: o valor do HREF dos links é exatamente o nome do ID dos DIVs referente ao conteúdo das abas.

Agora, para formatar e deixar bonitinho:

	* {margin:0; padding:0;}
	body {
		font:13px verdana, arial, tahoma;
	}

	ul { margin:20px 20px 0; list-style:none;}
	li {float:left;}
	.itens a {
		float:left;
		border:1px solid black;
		background:gray;
		padding:5px 15px;
		color:#FFF;
		text-decoration:none;
	}

	.itens a:focus {background:red;}

	.aba { padding:0 20px;width:400px; clear:both;}
	.aba div {
		background:white;
		border:1px solid black;
		padding:10px;
		width:100%;
		display:none;
	}

	.aba div:first-child {
		display:block;
	}

Note que a última linha está dizendo para que os DIVs referentes às tabs fiquem escondidas e que só a primeira apareça.

A coisa toda acontece aqui, com uma linha de código:

	.aba div:target {
		display:block;
	}

Essa linha entende o valor do HREF do link, capturando o ID referente ao div que o browser deve mostrar.

Veja o exemplo completo aqui.

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

PDF – Browsers antigos: guerra contra o terror

Diego Eis — Wed, 09 Mar 2011 14:46:33 +0000

É muito difícil tomar a decisão de não suportar browsers antigos ao produzir um grande site. Sempre há um número que se elevado a milhões de usuários o problema pode se agravar. Para uma grande empresa que tem 8 milhões de clientes, ignorar 1% destes usuários é algo realmente fora de questão. O ponto é que você não precisa ignorar estes valiosos 1%. Mas também não precisa gastar milhões nem perder muito tempo tentando resolver os problemas que estes usuários trazem para a produção. Nossa ideia aqui é dar a melhor experiência que eles podem ter sem prejudicar os outros 99%.  

Com este pensamento, criei um PDF simples, onde cito os principais problemas se prever o desenvolvimento para browsers ou meios de acesso antigos. É um documento onde você poderá imprimir e dar para o seu chefe e integrantes da sua equipe. É uma ferramenta para que você tenha alguma munição para te ajudar a convencer aqueles que tentam insistir no erro de manter uma compatibilidade perfeita entre browsers atuais e browsers de 12 anos.

Baixar o PDF – Guerra contra o Terror

Update A Microsoft anunciou sue a partir de 2012 o IE terá atualização automática nos sistemas Windows XP, Windows Vista e Windows 7. Isso quer dizer que estamos mais perto da salvação.

Posts Relacionados

The IE6 Countdown – O ultimato da Microsoft

Diego Eis — Sun, 06 Mar 2011 00:56:57 +0000

A Microsoft acaba de publicar um website chamado IE6 Countdown, onde ela incentiva a descontinuação do Internet Explorer 6. Esqueça qualquer campanha iniciada por qualquer um… Essa campanha é definitiva e iniciada pela própria Microsoft. Claro, a Microsoft está fazendo com que os usuários migrem do IE6 para o IE8. Ela não indica nenhum outro browser concorrente. Mas realmente isso não importa… O que importa é que os usuários ouçam a voz da Microsoft e parem, defintivamente de utilizar o Internet Explorer.

No site, a Microsoft publica um tabela demonsrativa, onde é comparado as versões do IE, mostrando quais são as vantagens de se fazer o upgrade. Eles também disponibilizam uma barra que você pode colocar em seu site ou em seu projeto incentivando os seus visitantes a atualizarem o browser.

O que eu achei mais importante da iniciativa, é que a Microsoft sabe que algumas empresas tem grandes restrições de atualização de software e por isso eles disponibilizam algum material para facilitar a vida das equipes de TI dessas empresas. Há alguns casos de estudo como a da Dell, Wunderman e Indiana Office of Technology. Juntamente com estes casos de estudo, eles publicaram um estudo de impacto ecônomico referente a migração do IE6 para o IE8.

No último mês, de acordo com a Net Applications, o IE6 detem 12% de marketshare. A Microsoft quer este número reduzido para 1% ou menos.

Essa é a hora de colocarmos força nessa campanha. Mostre para seu chefe. Para aquele seu amigo desenvolvedor cabeça dura que ainda insiste em utilizar o IE6. Mostrei para aquele cliente, grande ou pequeno, que é perda de tempo suportar o IE6 ou qualquer outro browser antigo. Essa é a hora.

Eu iria esperar até o final do carnaval, mas como essa notícia foi muito inesperada, estou publicando agora um PDF simples, onde você pode publicar para qualquer um, principalmente para seu chefe, as desvantagens de suportar o IE6, outros browsers ou meios de acesso antigos, que prejudicam a produção de um projeto. Fique à vontade em baixar este PDF aqui.

Posts Relacionados

HTML 5, novos elementos e atributos.

Thaiana Poplade — Mon, 28 Feb 2011 12:00:53 +0000

Tags, mídia, interação usuário x website, relevância nos resultados de busca, usabilidade e acessibilidade são as grandes definições do poder de transformação que o HTML 5 promete estabelecer quando desenvolvedores web puderem utilizá-lo e como já mencionado em outro artigo, especializações na área devem surgir com esta nova versão, ou seja, você terá a possibilidade de escolher em qual das vertentes citadas acima vai deter maior conhecimento. Ainda assim, é fato que a construção de códigos para interfaces continuará sendo tarefa geral do desenvolvedor Front-End e saber quais tags utilizar e de que forma as utilizar continuará sendo conhecimento básico no desenvolvimento de códigos de marcação.

Determinar como distribuir informação será o grande objetivo no planejamento de construção de seu código html na versão 5. Esta hoje, acaba sendo uma das tarefas de um profissional SEO, mas acredita-se que com uso das novas tags desenvolvedores Front-End terão conhecimento e possibilidades de participar deste planejamento.
Desta forma, o conselho é: você desenvolvedor não familiarizado com algumas destas técnicas de construção semântica de códigos html priorizando informação, pode fazer algumas leituras complementares a respeito, como por exemplo, o uso de Microdata no HTML 5 – explanado pela Talita Pagani. Este com certeza, será um diferencial no perfil de um profissional Front-End.

Novos elementos

Além das tags de mídia (

audio

vídeo

), a incansavelmente comentada

canvas

e das novas tags de estrutura:

section

article

nav

aside

header

footer

, teremos também, de acordo com a W3C, ainda outras novas tags que determinarão o tipo de informação que estará sendo exibida na tela. Um exemplo são as tags:

embed

que será usada para pluggins e a tag

progress

que representará dados em progresso como o download de um arquivo.
Outro exemplo de novos elementos, será a tag

time

utilizada para informações de dia e hora que poderão situar o usuário quanto ao horário e data de navegação ou apenas quanto a periodicidade de um novo post em um blog ou de um novo comentário. Abaixo, 3 exemplos de como aplicar esta tag:

Para determinar hora:


Postado às 09:00hs

Para determinar a data [ através do uso do atributo datetime]:


Postado em  13 de fevereiro de 2011

Ou para determinar data e hora de um local específico:


Postado em  13 de fevereiro de 2011 às 09:00hs

Neste último exemplo, a informação referente ao horário é separada da informação de data através do separador “T” (obrigatório caso ambas as informações sejam declaradas). Logo após é possível adicionar a informação de fuso horário

[+03:00]

- declarada para situar o local onde este horário está sendo determinado – em nosso exemplo: regiões Nordeste / Sul e Sudeste do Brasil, de acordo com o ponto referencial – Meridiano de Greenwich.

Novos atributos

Com o HTML 5, novos atributos à elementos que já existentes também foram criados.
Uma das possibilidades que está entusiasmando desenvolvedores é quanto a criação de formulários sem a necessidade de scripts externos para validação das informação que serão “inputadas” pelos usuários.
Por exemplo, o elemento

input

poderá receber atributos como

tel

[para número de telefones],

[para campos de busca],

month

date

time

[para informações referentes a tempo e data],

[para endereços eletrônicos], entre outros. Saiba mais sobre a construção de formulários em HTML 5.
Outros novos atributos que também prometem revolucionar são:

1	placeholder

que poderá ser declarado nos elementos

input

textarea

, utilizado para validar o tipo de informação a ser inserida. Por exemplo:

1	<input type=”email” placeholder=”a@b.com.br” />

E o atributo

required

que poderá ser declarado aos campos de um formulário exigindo preenchimento.

Elementos Alterados

Alguns elementos terão sua significancia alterada no HTML 5. Como por exemplo, o elemento

que não representará nada além de uma informação em negrito na tela e o elemento

que representará informações em outras línguas ou um novo tom de voz para leitores de tela.

Elementos eliminados

E como não poderia deixar de ser, alguns elementos não deverão mais ser utilizados, como por exemplo os elementos

center

frame

noframes

. Inevitavelmente, algumas das técnicas de acessibilidade que utilizamos hoje, deverão ser revistas bem como a busca por novas alternativas para esta nova versão.

Muito do que foi descrito acima, ainda está em estudo e aprendizado. Alguns testes já podem ser feitos em navegadores como o Chrome e Opera e, em algumas semanas, Firefox 4, e são essenciais para um entendimento mais direto das limitações e possibilidades que teremos. Sem descartar claro, que a troca de informações entre profissionais do desenvolvimento web será essencial, portanto comente, observe e sugira maneiras de utilização e saiba, este é só o começo do quanto o HTML 5 pretende revolucionar o que conhecemos por “construção de websites”.