HTML5 Selector API – querySelector querySelectorAll

 Quem acompanha O Desenvolvedor já deve ter percebido que eu sou um grande fã do framework jQuery, utilizo-o diariamente no trabalho e nos projetos pessoais.

Desenvolver utilizando jQuery é extremamente produtivo e fácil, visto o sucesso deste framework a W3C resolveu documentar oficialmente seletores no DOM de forma mais fácil: o  querySelector e querySelectorAll.

querySelector e querySelectorAll

O querySelector é uma API de seleção de elementos do DOM que está disponível diretamente no document, isso facilita os seletores tornando-os muito próximos da seleção do jQuery (a W3C assumiu que os seletores vieram da idéia do jQuery, que na verdade é uma biblioteca separada, chamada Sizzle).

A função é bastante simples e o seletor pode ser de classe (exatamente como no jQuery .nome-da-classe ou de elemento, por exemplo p). O resultado do querySelectAll é uma lista com os elementos que casam com o seu seletor e o do querySelector é apenas o primeiro elemento que casar com a seleção passada.

Exemplo

<style>
.zebraon{background:silver}
</style>
<script>
function zebrado(selector){
var zebrar=document.querySelectorAll(selector);
for(var i=0;i<zebrar.length;i+=2)
zebrar[i].className="zebraon"
}


window.onload=function(){
zebrado("p");
zebrado(".zebra tbody tr");
}
</script>

Fiz um teste criando uma função para "zebrar" qualquer elemento da página (tabelas, por exemplo), no exemplo abaixo zebrei todos os parágrafos da página e as linhas da tabela com a classe zebrado. Para isso criei uma função que recebe como parâmetro a seleção, faz a busca usando o querySelectorAll e adiciona a classe "zebraon" que criei.

 

Um exemplo simples mas que mostra um bom amadurecimento na parte de seletores DOM! Antes de levantar qualquer debate – acho que isso não vai acabar com o uso de frameworks, mas provavelmente vai melhorar a performance das bibliotecas como jQuery já que a seleção será nativa, reduzindo parte da magia negra usada atualmente para isso.

E aí, o que acharam?

Formulários em HTML5 – novos tipos de input

Quem já fez validação de formulário (antes do jQuery validate) deve lembrar o inferno que é um formulário gicante para validar – tudo bem que eu era noob no javascript na época, mas com os novos tipos de inputs propostos pela W3C os formulários ficaram mais semânticos e a validação no front-end ficará ainda mais fácil.

O HTML5 está muito mais interativo e muita coisa que nós desenvolvedores já fazemos a muito tempo passou a ser documentada e oficializada pelo W3C, tenho esperança que com o tempo isso reduzirá as gambiarras da programação.

Novos tipos de input no HTML5

Input type color

Ainda não está implementado em nenhum browser, mas a idéia é facilitar os "color picker" tornando-os nativos de cada navegador.

Input type search

Um campo de texto com o diferencial de estar especificado que será de busca, poderá ser explorado por leitores de tela e dispositivos de acessibilidade para facilitar a navegação por buscas.

Input type number

Vai facilitar a validação se ela for implementada diretamente no browser, mas não traz nenhuma grande novidade.

Input type date

Outro input que pode facilitar muito a validação, a recomendação é que seja nativo do navegador um datepicker (com funcionamento semelhante ao calendário do jQuery UI).

Esta recomendação além de acabar com preocupação de validação no front-end para datas elimina a necessidade de implementação do datepicker.

Ponto negativo: acredito que os campos com datepicker, colopicker, etc. se tornatão os novos inputs do tipo "file" no sentido de impossibilidade de alteração de layout.

Espero que os browsers implementem uma forma de usar o CSS para estilizar o datepicker, caso contrário serão necessárias gambiarras e acho que o jeito vai ser manter o datepicker em JS para poder manter o layout, afinal o cliente (e o designer) não quer saber se é do browser e o visual não pode ser alterado, ele quer o checkbox, o radio, o select, o datepicker tudo conforme o layout dele – e com razão.

Input type datetime

A descrição do item anterior serve para este, com o diferencial que os dados desde são no formato datetime (além da data inclue a hora).

Input type datetime-local

Mais um campo bacana para o desenvolvimento de aplicativos web, principalmente quando você tem usuários localizados em fuso horários diversos.

Este campo é do tipo datetime mas com o diferencial que ele utiliza o fuso horário do computador do cliente e quando o form é enviado (submit) é realizado uma conversão para o fuso horário do servidor, acabando também com a necessidade de conversões de datas e horários para diferentes fusos.

Input type email

Sabendo da necessidade constante de validação de e-mail, a W3C implementou este novo type que também é recomendado que a validação seja nativa do browser, outra a menos para se preocupar.

 

Existem também novos eventos para os formulários, mas vai ficar para outro post pois aqui já tem bastante novidade. O que você achou dos novos tipos de input? Compartilhe sua opinião nos comentários!

Para saber mais sobre HTML5 leia também:

HTML5 – section ou article?

Nos blogs que acompanho as discussões mais polvorosas que eu vi acerca do HTML5 eram a respeito da semântica e confusão quanto ao uso do article e do section. A definição dos elementos pela W3C realmente é bastante rasa e permite diversas interpretações:

Article tag

O <article> define conteúdo externo.
O conteúdo externo pode ser um artigo de notícias a partir de um provedor externo, um texto de um blog, um texto de um fórum ou qualquer outro conteúdo de uma fonte externa.

W3C (EN)

Depois de ler algumas outras definições externas minha compreensão foi que o source do conteúdo não precisa ser uma fonte externa, mas o article é um conteúdo independente, o conteúdo que teria no feed daquela página, ou como o @elcio bem definiu: o "filézinho do conteúdo".

Section tag

O <section> define as seções em um documento.
Tal como capítulos, cabeçalhos, rodapés ou outras seções do documento.

W3C (EN)

São as seções genéricas do documento, podem estar dentro de um article (dividido em capítulos, por exemplo) ou para separar seções na home do site, por exemplo.

Percebam que a definição oficial é um pouco confusa – e foi o que causou um pouco de pânico enquanto a documentação do HTML5 era escrita. Agora a comunidade está um pouco mais calma acerca do assunto e resolvi dar meus pitacos, já que esclareci algumas dúvidas no curso da W3C de HTML5.

 

A maioria parte das tags html tem uma nomenclatura "técnica", um dos pontos que percebi nas leituras (em inglês a maioria) era que o nome com palavras que existem no idioma (inglês) causam confusão na hora de definir onde a tag será usada. 

Um texto interessante sobre o assunto é o Article vs. Section: We"ve Finally Gone Mad (EN) que dá uma brincada com algumas questões destas dúvidas, e este também fala sobre o assunto e exemplifica o uso de article e section.

Quando usar article e quando usar section?

Você já deve ter entendido, o article é seu conteúdo principal – aquilo que o usuário entrou para ler. O post no seu blog, a notícia, a seção de fotos (?), vídeo (?). Article é o conteúdo que seu usuário gostaria de ter no feed.

Eu li sobre o uso de article para os comentários, porém seguindo esta definição acima não é o correto (e eu jamais faria isso pensando em SEO).  Comentários normalmente não são conteúdo principal – é um conteúdo tangencial – e está relacionado ao conteúdo, portanto faz sentido utilizar o <aside>.

O section é um elemento genérico, "a nova div" como foi comentado no curso. Não é exatamente a "nova div", divs devem continuar existindo para quando for necessário alguma formatação específica para layout apenas (sem peso semântico), porém quando esta formatação for de uma seção da página a div deve ser trocada pelo <section>! 🙂

Uso errado do section

Um exemplo de uso errado do section seria  como a div "principal" da página, normalmente  usada para centralização de todo o site. Não é correto pois semânticamente trata o site como uma "seção", neste caso o correto é o uso de div – dica do próprio @diegoeis, que disse que <div> é coisa do passado e rebeldia no twitter.

 

Leia mais sobre HTML5:

 

HTML5 meta – Charset

Estou agora no curso de HTML5 da W3C e vou inicar uma série de posts sobre as idéias e definições do HTML5 passadas por aqui.

Depois de colocar o doctype correto o HTML5 mantém as tags <meta>, mas com algumas novidades que nos permitem especificar algumas coisas de forma mais intuitiva.

Setando o charset no HTML5

Inconsistência de charset é um problema muito comum e que causa dor de cabeça monstruosa entre os desenvolvedores – acentuação com problema, caracteres especiais que não são imprimidos na tela, etc. Tudo isso normalmente é relacionado a problemas de charset.

Alguns destes problemas acontecem por esquecimento de explicitar o charset, por usar um charset errado… no HTML4 tínhamos o seguinte:

<META http-equiv="Content-Type" content="text/html; charset=UTF-8">

Não existia uma meta especificando o charset e como a tag content-type enviada como cabeçalho pelo servidor era mandatória o charset era sobreposto pelo servidor – muitos desenvolvedores (como eu) não sabiam disso, setavam um charset no documento, ele não funcionava e ficávamos quebrando a cabeça para descobrir que diabos estava acontecendo se o charset "estava certo".

No HTML5 temos uma meta específica para especificar o nosso charset:

<meta charset="UTF-8">

Agora seu navegador realmente sabe com qual charset ele deve tratar o documento, pois a regra do servidor não irá sobrepor a do seu documento, mas não se esqueça que para inserir esta meta tag você precisa especificar corretamente o doctype.

Leia mais sobre HTML5:

E também a documentação das meta tags no W3C.

HTML5 – Tag aside

Dando continuidade as explicações sobre as novas tags do HTML5, você já sabe especificar o doctype, já fez o seu menu utilizando a tag nav, como você deve classificar o conteúdo relacionado ao seu conteúdo principal?

aside – conteúdo relacionado

A tag <aside> não é para fazer colunas como eu já li por aí, nas dicas para escrever um bom HTML eu falei: semântica na escrita, ignore o layout.

A tag aside define uma área de conteúdo relacionado ao seu conteúdo principal (que provavelmente será um article, o "filé do conteúdo" – vou tratar em outro post já começado), então pode fazer sentido você utilizar isso para uma barra lateral – desde que o conteúdo esteja relacionado ao seu conteúdo principal.

Um exemplo do @elcio no curso da W3C é o uso do aside para as listas de comentário. Isto resolve a dúvida do uso de sectionou article para comentários. Desde que li as definições eu tenho em mente usar apenas um article por página – pensando em SEO, este article está reservado para o conteúdo principal, que eu quero que seja indexado e considerado importante pelos buscadores, pois ele é o conteúdo mais importante para o meu usuário.

Vou continuar escrevendo diversos posts sobre HTML5 durante o curso, para quem quiser acompanhar mais de perto sigam @odesenvolvedor que estou pulicando as dicas rápidas por lá!

(Os posts feitos durante o curso serão atualizados com as correções, estou "correndo" para não perder nada de conteúdo do curso).