Tableless » Javascript

jQuery: métodos desconhecidos

Davi Ferreira — Tue, 31 Jan 2012 15:30:24 +0000

No meu último artigo falei sobre dicas de otimização e performance de códigos jQuery. Na versão inicial do texto eu havia planejado um tópico sobre os métodos não muito conhecidos, já que alguns, como o ajaxSetup, podem também atuar na performance da sua aplicação.

Acabei descobrindo que este tópico ficaria enorme e, por isso, preferi escrever sobre o assunto em um artigo próprio.

Com vocês, alguns dos métodos menos populares do jQuery!

proxy()

O método proxy() permite executar um outros método forçando um determinado contexto. Seu objetivo principal é evitar a confusão do ‘this’ causada quando um objeto é utilizado dentro de um método de outro objeto.

Por exemplo:

1
2
3
4
5
6
7
8
9
10
11

$(".botao").click(function() {
setTimeout(function() {
console.log(this); //window
}, 400);
});

$(".botao").click(function() {
setTimeout($.proxy(function() {
console.log(this); //.botao
}, this), 400);
});

É possível utilizar o proxy() através de duas assinaturas. A primeira recebe como parâmetros uma função e o escopo. A segunda funciona passando o escopo e o nome do método como uma string.

1 2	$.proxy( funcao(){}, 'objeto' ); $.proxy( 'objeto', 'metodo' );

Quem sabe agora você para de usar o truque do ‘var that = this’, hein?

isArray() e isFunction()

Esses dois métodos fazem parte da família de utilitários do jQuery. Como seus nomes sugerem, o primeiro verifica se o objeto é um array JavaScript e o segundo se o objeto é uma função.

1
2
3
4
5
6

var jogadores = ['Obina', 'Vagner Love', 'Zico'];
var chutar = function(jogador){
console.log("Gol de " + jogadores[jogador]);
};
console.log($.isArray(jogadores)); // true
console.log($.isFunction(chutar)); // true

Uma observação: a função isArray retorna true apenas para verdadeiros Arrays (e não objetos “tipo array”, como um objeto jQuery, por exemplo).

1 2	var jogadores = $('.jogadores'); console.log($.isArray(jogadores)); // false

A lista de utilitários possui outros métodos interessantes, tais como grep(), map(), merge() etc.

queue() e dequeue()

Apesar de terem sido desenvolvidos originalmente para o uso de animações, os métodos queue() e dequeue() podem ser utilizados para qualquer tipo de fila.

A fila padrão é chamada de ‘fx’: essa é a fila das animações. Ela será utilziada caso não seja passado nos parâmetros o nome de uma fila. No exemplo abaixo, estamos criando a fila ‘ajaxRequests’.

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

$(document).queue('ajaxRequests', function(){
$.ajax({
type: 'GET',
url: '/tableless',
complete: function(jqXHR, textStatus){
$(document).dequeue("ajaxRequests");
}
});
});

$(document).queue('ajaxRequests', function(){
$.post('/tableless', {categoria: 'jquery'});
});

Para dar sequência no andamento da fila, você precisa utilizar o método dequeue(). Ele deve ser chamado no final da execução de um processo da fila (e como essa é uma fila de processos AJAX, utilizamos o dequeue no evento complete).

Outro recurso interessante é a possibilidade de saber o tamanho da fila, ou seja, quantos eventos ainda serão executados. Para isso, basta utilizar a propriedade length após o método queue().

1
2
3

$(document).queue('ajaxRequests').length; // 2
$(document).dequeue("ajaxRequests"); // executa fila
$(document).queue('ajaxRequests').length; // 0

detach()

Assim como o remove(), o detach() retira um elemento do DOM. No entanto, esse método guarda as referências, eventos e dados associados ao elemento retornando um objeto jQuery que pode ser re-inserido no DOM.

1
2
3
4
5
6
7
8
9
10
11

$('.link').click(function(e){
e.preventDefault();
console.log('clique');
});
$('.link').click(); // 'clique'
var link = $('.link').detach();
$('body').append(link);
$('.link').click(); // 'clique'
$('.link').remove();
$('body').append('link');
$('.link').click(); // []

ajaxSetup() e afins

Talvez esses sejam os métodos mais injustiçados do jQuery. É muito comum a repetição de chamadas AJAX, incluindo seus parâmetros. Esses métodos de configuração permitem definir valores padrão para qualquer evento AJAX em sua aplicação.

Com o ajaxSetup() é possível, por exemplo, habilitar ou desabilitar o cache e definir o tipo de requisição: POST ou GET.

1
2
3
4
5

$.ajaxSetup({
type: 'POST',
dataType: 'json',
cache: true
});

Você ainda pode configurar uma URL padrão e também parâmetros passados durante a chamada:

1
2
3
4
5
6

$.ajaxSetup({
data: {
origem: 'tableless'
},
url: '/tableless'
});

Para conferir uma lista completa das propriedades configuráveis, visite a página do método AJAX na API do jQuery.

Os callbacks e eventos relacionados à execução de métodos AJAX também podem ser configurados. No entanto, essa configuração deve ser feita através dos seguintes métodos específicos: ajaxStart(), ajaxStop(), ajaxComplete(), ajaxError(), ajaxSuccess() e ajaxSend().

Por exemplo, você poderia utilizar a configuração abaixo para exibir um indicador de carregamento no início da execução de um método AJAX.

1
2
3
4
5
6
7

$('.carregando')
.ajaxStart(function(){
$(this).show();
})
.ajaxStop(function(){
$(this).hide();
});

Você pode associar os eventos a qualquer elemento e o jQuery se encarregará de encontrar e executar todos os métodos associados.

delay()

O método delay() serve para adiar a execução de uma função, método ou animação. Ele é especialmente útil para controlar o tempo de animações.

1	$('.alerta').fadeIn().delay(1000).slideUp();

No exemplo acima, o elemento com a classe “alerta” é exibido através de uma transição fade e, um segundo depois, ocultado através do método slideUp().

replaceWith() e replaceAll()

Imagine que você queira substituir todos os elementos que tenham a classe “pontos”. Com o método replaceWith() fica fácil. O que ele faz é buscar todos os objetos que se encaixem no seletor indicado e substituir seu conteúdo.

1	$('.pontos').replaceWith(' 1 milhão de pontos! ');

O replaceWith() também funciona com elementos que não estejam presentes no DOM, ou seja, você pode criar um objeto jQuery e substituir/manipular seu conteúdo antes de inserí-lo no DOM.

1	$(' ').replaceWith(' Carregando... ');

Da mesma forma, o método replaceAll() também substiui o conteúdo de elementos, mas a origem e o destino são invertidos. Você também pode passar seletores como conteúdo. Nesse caso o funcionamento é um pouco diferente já que o elemento não é clonado e sim movido no DOM.

1 2	$(' Carregamento completo! ').replaceAll('.carregando'); $('.titulo').replaceAll('.carregando');

Note que a diferença dos métodos acima para os métodos tradiconais html() e text() é que o próprio elemento também é substituído e não só o seu conteúdo.

Estes foram alguns métodos que pouca gente conhece ou utiliza. Pode até ser que você nunca tenha sentido falta deles, mas é sempre bom ter umas cartas extras na manga.

E se você gostou, garanto que ao consultar a API do jQuery você descobrirá vários outros métodos desconhecidos, mas que podem ser úteis em algum momento do desenvolvimento dos seus projetos.

Posts Relacionados

Aprenda a programar Javascript no Codecademy

Diego Eis — Tue, 24 Jan 2012 13:04:23 +0000

O Codecademy é um lugar para se aprender a programar:

“Codecademy was created out of the frustrations Zach and Ryan felt with learning how to program. Tired with less effective text and video resources, Ryan and Zach teamed up to create Codecademy, a better, more interactive way to learn programming by actually coding. This is just the beginning. Join us as we make it easy for everyone to love and learn how to code.”

Lá você aprende a programar, se baseando em Javascript, de uma maneira facil e assistida. Você consegue facilmente aprender nos primeiros passos como fazer variáveis, arrays e outros pequenos conceitos que precisamos entender ao programar.

Conforme você vai aprendendo, você desbloqueia badges (Como o Campus Online novo, aguarde! ;-D) e acompanha seu ritmo de aprendizado.

Muito indicado para quem quer aprender a programar ou quer ter alguma noção sobre o assunto! Visite o Codeacademy agora e comece sua jornada!

Mais comentados

Introdução aos padrões de codificação

Diego Eis — Mon, 23 Jan 2012 11:28:41 +0000

Como os idiomas reais, cada linguagem de programação tem suas respectivas regras, individualidades, pontuações, pausas e pontos em comum com outras linguagens. Você precisa conhecer essas peculiaridades para falar fluentemente ou no mínimo ser entendido. Nas linguagens de para web ou qualquer outra linguagem de programação, precisamos seguir algumas regras básicas para que o código não vire uma língua estrangeira no meio do projeto.

Definir padrões é normal para que a equipe inteira escreva o código da mesma maneira. Esse assunto é longo e muito importante para todas as equipes de desenvolvimento. Programadores já quiseram me matar várias vezes porque eu uso TABS em vez de ESPAÇOS em arquivos Python/PHP. Programadores gostam de espaços. Eu não. Mas não é o nosso gosto que vai definir quais os padrões de código que devemos seguir.

Quando definimos padrões e boas práticas, garantimos que todos da equipe conseguirão ter o mínimo de entendimento do código daquele projeto que está na empresa a tempos. Se alguém da equipe adoecer ou precisar ir para o Canadá, outro integrante pode assumir o seu lugar sem precisar se preocupar em aprender novas regras, porque elas devem ser as mesmas do projeto anterior.

É importante que os integrantes da equipe sejam sempre fiéis aos acordos firmados no momento em que combinam esses padrões. É importante também que, caso eles encontrem um integrante fora da lei, que eles forcem o meliante a seguir as regras. Já vi gente perdendo o trabalho de uma semana por que estava trabalhando diretamente pelo FTP e o projeto não estava no GIT. O programador simplesmente APAGOU o projeto da pessoa. Nunca mais ela resolveu editar os arquivos fora do controle de versão. Esse tipo de atitude é perigosa mas muito necessárias às vezes. Devemos forçar as regras num ambiente onde todos devem quem, quando e como as linhas de código do projeto foram escritas.

Alguns pontos para se pensar e combinar:

Identação

Como devemos identar o código? Com espaços ou tabs? Se for com espaços quantos?

Espaços em brancos (Whitespaces)

Espaços devem ser incluídos depois de uma operação condicional? Espaços devem ser colocados entre o seletor e as chaves? E no final de cada linha, precisa?

Nomenclatura

Como as classes, ids e variáveis devem ser nomeadas? E as funções? Vamos usar CamelCase?

Comentários

Como faremos com os comentários? Como serão os delimitadores do comentário? O comentário deve ser completo ou precisa ser algo mais resumido?

Arquivos

Como os arquivos, que não fazem parte da estrutura padrão do CMS, Framework e etc deverão ser chamados? E o nome das pastas? Como as páginas serão chamadas?

Chaves e ponto/vírgula

As chaves deverão ser abertas na mesma linha ou devemos quebrar linhas? Vamos sempre usar ponto/vírgula? Vamos usar o padrão K&R ou Allman?

Quando definimos estas pequenas coisas, diminuímos muitos percalços no meio do caminho. Já vi projetos atrasarem meses por que um palerma abriu e salvou arquivos com o charset diferente do que já tinha sido combinado no início.

“It’s more important for people on a team to agree to a single coding style than it is to find the perfect style.” Building Scalable Web Sites: Building, Scaling, and Optimizing the Next Generation of Web Applications
Indico este livro sobre esse e outros assuntos sobre a construção, desenvolvimento e manutenção de websites

Posts Relacionados

Formulários e o Metawebdesign – Parte 1

Alysson Franklin — Mon, 24 Oct 2011 11:06:00 +0000

O front-end é uma profissão de uma amplitude imensa. Temos profissionais montando mockups/PSDs, especialistas em acessibilidade, usabilidade, arquitetura da informação, integração com aplicações, designers de interface, application developers. Tem até SEO.

O background do profissional neste momento não importa muito, apenas a afirmação que ele está trabalhando na camada de front-end. Só isso basta para confirmar os papéis acima.

Em muitas empresas o front-end é trabalhado de maneira criteriosa, com separação de tarefas em maior ou menor intensidade, de modo que o processo esteja sempre azeitado e atento aos prazos dos outros times que dependem da interface. Em algumas outras, o responsável pelo código é o unico responsável por fazer tudo isso acima. E isso acontece com frequência.

É o famigerado exército-de-um-homem-só, que em um projeto normalmente é responsável por:

Pesquisa: Fornece dados e insights para o desenvolvimento de todo o projeto – sobre o usuário, suas características, hábitos e necessidades. Apesar de orientada a um projeto específico, essa pesquisa também deve ser constante, oferecendo atualização e embasamento para a criação de novas experiências.
Arquitetura da informação: Organização de informação, entendendo o modelo mental do usuário, para que ele se reflita também no produto final.
Design da interação: Desenhar a interação de forma que ela seja consistente, fácil e auto-explicativa. Entende ros requisitos de usabilidade criados na fase de pesquisa e dominar os padrões de interação que a aplicação deve ter, além de saber lidar com a multiplicidade de devices e plataformas onde a interação ocorre.
Design Visual: Balanceando beleza e comunicação, domina tanto a direção de arte do produto que está sendo desenvolvido quanto o acabamento final dos pequenos detalhes da interface.
Redação: Expressar as ideias, simples ou complexas que o cliente passou para o desenvolvedor em palavras simples e que sejam facilmente entendidas pelos usuários do produto. Este conteúdo vem do cliente, mas não é difícil acontecer do desenvolvedor ser responsável por criar algum conteúdo, seja transformando a linguagem do cliente dentro de um contexto web, deixando-a mais dinâmica e convidativa a leitura, seja pequenos conteúdos que devem ditar padrões visuais para interações do usuário.
Prototipagem: Criação da UI. Isso serve tanto para o estágio inicial do projeto (com protótipos de papel, de baixa fidelidade) quanto para o estágio que precede o desenvolvimento, onde o produto já está mais amadurecido e mais próximo do final. Esta etapa pode ser a da criação das páginas em si, uma vez que os modelos de conceito e interação estão prontos e o design está criado ( sites tipicamente estáticos ou de menor porte ) ou pode ser a fase da criação dos protótipos que devem ir para a integração depois (back-end).
Gerenciamento: Garantir o funcionamento de todas as áreas de entrega da melhor e mais produtiva maneira possivel. E ainda ser o ponto focal com cliente e usuário, quando necessário.

Em um departamento multidisciplinar de UX, no melhor dos mundos, temos atribuições diferentes para diferentes profissionais. Muitas vezes, isso não acontece. Outros casos, não raros, a empresa não está interessada na matéria, ou apenas não tem profissionais que atuam nesta área que se preocupam com o código (e design) que entregam. Vai saber. Em empresas com atribuções de projeto mais estruturadas um departamento de UX conversa claramente com outros áreas, como Arquitetura, DBA, Requisitos, Integração, Testes e Gerência.

No FrontInBH, conversando com os desenvolvedores no final do evento, e também em conversas com devs de todos os cantos, é fácil perceber que empresas com equipes de desenvolvimento reduzidas (SMB, agências, pequenos portais) mantém um ou dois especialistas que acabam fazendo todo o serviço. E estes profissionais acabam por andar entre duas profissões distintas: Designer de Interação e Interfaces ou o Desenvolvedor web.

Vale lembrar que estas duas profissões tem backgrounds muito diferentes. Enquanto os designers lidam com abstração, devs costumam lidar com aobjetividade do código. Disciplinas que vão de Teoria de Cores à Orientação a objetos fazem parte do background destes profissionais, porém é com muito trabalho que são desenvolvidos as especialidades, devido a matérias tão antagônicas.

Algumas das disciplinas que um profissional de web hoje deve saber para atender demandas de projeto

Essa diferença de backgrounds acaba por oferecer barreiras que fazem com que o desenvolvimento e a integração das disciplinas seja muito difícil. E com isso temos profissionais que desenham interfaces e interações lindas, mas que não podem funcionar sob conceitos de acessibilidade, ou ainda websites perfeitamente acessíves e fluídos, mas que não tem um design tão impactante.

Diante deste cenário tenho trabalhado para desenvolver um conceito que chamo de Metawebdesign. A proposta é justamente encurtar estes espaços, sem incomodar profissões importantíssimas e já consolidadas, mas que por razões diversas em algumas vezes acabam por ser a mesma coisa no organograma de uma empresa.

Meu primeiro e segundo artigos sobre o assunto vão falar sobre formulários. Muito já foi falado, e não quero repetir o que já sabemos. Porém é importante mostrar como conceitos de design da interação, arquitetura da informação e código são usados para criar aplicações que oferecem uma experiência inesquecível para o usuário. Estes dois posts iniciais sobre o assunto se transformam em um toolkit muito útil aonde você poderá com a parte 1 e 2 escolher usando conceitos de design os melhores elementos de controle e depois entender como codificá-los de acordo com os padrões do W3C, mantendo usabilidade e acessibilidade.

Aplicando o Metawebdesign a formulários: o design da interface

Cedo ou tarde, a aplicação que você esta criando vai precisar perguntar (ou pedir) ao usuário algum tipo de informação. E sob o ponto de vista do usuário, nesse momento a credibilidade de seu design de interação e código estarão em jogo, pois complexidade e simplicidade aqui separam o céu e o inferno.

Todos sabem como usar alguns elementos de controle como input texts, checkboxes, radio e dropdowns – e isso não somos nós desenvolvedores de aplicações web. Isso é consenso, domínio público: um status quo que todo usuário de computador aprendeu a identificar e saber operar. Mesmo novos usuários entendem estes elementos com uma rapidez impressionante. O problema é como agrupar todos eles em torno de um bem comum – o bem sucedido submit. Afinal de contas, fazer um formulário é simples, basta colocar um bando de informações ordenadas de maneira racional, colocá-las na página com alguma ordenação top-bottom e é isso, correto?

Para começarmos a conversa, isso é o que os usuários esperam.

De acordo com o w3c, um formulário HTML (form) é uma seção do documento HTML que pode conter informação estática, elementos de controle (os mesmos mecionados acima e alguns outros que vamos falar aqui) e labels que referenciam estes controles semanticamente. Tudo isso para permitir que o usuário possa responder (ou preencher) uma série de perguntas que a sua aplicação precisa para prosseguir com o fluxo. E o usuário interage com tudo isso alterando elementos de controle.

Bons e maus exemplos:

Bons exemplos de formulário são fáceis: você mesmo deve conhecer vários; são aqueles que você usa diariamente sem gastar muito tempo ou que não entediam durante seu preenchimento. Maus exemplos são fáceis e estão por todos os cantos da internet, não é difícil encontrar um (na verdade não precisamos nem procurar). Só que não é ético questionar o trabalho de ninguém sem saber as variáveis que levaram aquela implementação. Sendo assim, olha que “bonito” esse formulário que está no site da Apple como exemplo de um mau form.

Acredite: foi difícil até colocar tudo isso em um espaço visível. E ainda nao ficou bom.

Antes de entrarmos de cabeça nos elementos e como formulários devem ser criados, precisamos entender alguns principios básicos de um design de form:

Form Design – O básico:

Tenha certeza que o usuário entende o que e o porque você está pedindo ou perguntando algo;
Escreva labels com palavras que seus usuários possam entender facilmente independente de serem usuários frequentes ou novos usuários, tenha cuidado com os jargões ou acrônimos utilizados. Se necessário, desenhe para o usuário.

exemplo 1 : antes de um grande formulário, tome algum espaço da tela para explicar como ele funciona e o porque você precisa de todas aquelas informações.
exemplo 2: Se você precisa colocar um controle na tela que não é imediatamente óbvio dentro de um fluxo da tela, use uma tooltip ou outro tipo de ajuda que mostre ao usuário o que ele deve fazer em seguida.

Se puder, evite a redundância;
Antes de colocar os campos em uma tela, analise a informação e o contexto de cada um deles e se possível, agrupe informações para minimizar o numero de campos a serem preenchidos. Mesmo no melhor dos cenários, gastar tempo preenchendo caixas de texto não é algo divertido.

exemplo 1: se o usuário já preencheu o endereço de entrega no formulário de checkout, você pode reutilizar esta informação para o endereço de cobrança. Basta adicionar um checkbox perguntando se o endereço de entrega e cobrança são os mesmos que em caso de positivo, você já atendeu aos requisitos.
exemplo 2: Se 80% dos seus usuários estão no Brasil, 15% estão na Argentina e 3% nos Estados Unidos, você pode usar um para atender os requisitos de país. As opções seriam Brasil, Argentina, USA e logo após teríamos lista com a ordenação alfabética.
exemplo 3: Para endereços no Brasil, no
de localização, perguntando apenas o CEP podemos recuperar endereço, bairro, cidade e estado. Com isso faz sentido perguntar primeiramente o CEP, recuperar o valor via webservice e após o sucesso automaticamente preencher estes campos para o usuário.
Existem também exceções: A segurança deve ser levada em conta ao ponderar sobre recursos de auto-completion. Não seria ético tampouco legal recuperar os dados do cartão de crédito do usuário para onerá-lo da tarefa de inputar seus dados bancários, uma das partes mais tediosas e passíveis de erro durante a transação de um checkout.

Informações de conhecimento público normalmente são mais acuradas que informações de conhecimento pessoal; Quando perguntamos algo ao usuário, temos que ter em mente que eles podem mentir (everybody lies) ou mesmo errar. Podemos minimizar isso reduzindo problemas. O sistema de auto-completion com o CEP mencionado acima é um exemplo claro. Um erro simples de digitação pode causar um problemão na hora da entrega: a rua Roda dos Ventos pode virar rua Rosa dos Ventos em um clique. Probabilidade altíssima de problemas futuros que você pode evitar usando este tipo de abordagem.
Tenha cuidado ao transformar os requisitos de design em forms;
A maioria dos forms é criada para manipular transações feitas com o banco de dados ou alterar objetos de uma tela. Explore as dependências entre os elementos, procure por similaridades que possam ser agrupadas graficamente, como campos de endereço ou informações pessoais. O exemplo do endereço de entrega versus o endereço de cobrança mencionado na regra #2 pode ser repetido aqui. Porque não habilitar em um form de inserir produto um drag-n-drop para definir a ordenação das imagens de descrição deste produto ao invés de subir as imagens em uma ordem pré definida ou ainda primeiro subir as imagens para só depois ordenar?
Teste, teste novamente e quando achar que está tudo ok, teste de novo; Por alguma razão que nunca vamos descobrir, é incrivelmente fácil desenvolvedores e usuários terem idéias completamente diferentes quando o assunto é preencher um formulário. O mesmo form! Isso pode acontecer pelos mais variados modos:

conhecimento prévio com interações passadas,
respostas possíveis,
fluxo de página que depende de um contexto que o usuário pode entender de maneira diferente dependo de variáveis externas.

Por isso é importante montar o formulário e se certificar que todas as possibilidades de interação do usuário com os elementos da tela estão garantidas:

preenchimento de campos;
clique/toque em botões e objetos de tela;
entrada de dados validados para atender requisitos de design da aplicação;
condições especiais de uso e interação do form.

Isso nos dá evidência empírica do que funciona e o que nao funciona em sua aplicação, além de claramente indicar o caminho a seguir no caso de identificar um problema.

Escolha sabiamente os elementos de controle: eles impactam a expectativa do usuário sobre o que ele está sendo perguntado e como deve responder a isso:

Os usuários tendem a associar o tamanho e forma física dos campos a o que eles imaginam que seja o que estamos perguntando. Só depois desta associação é que os usuários lêem o que o label de um campo está pedindo.
Uma única radio button vai ser algo ditatorial pois sugere a existência de pelo menos duas opções na tela.
Após você estar acostumado com o processo de compra de sua loja online e seu formulário, automaticamente você irá suavizar sua atenção por não ser uma tarefa nova e sim uma repetição (e daí entendemos o porque a estrada para para erramos um formulário que preenchemos “todo dia” é tão curta)

Escolhendo elementos de controle

Quando estamos montando o design do nosso form temos que nos ater a algumas situações que impactam diretamente todo o formulário:

Espaço disponível na tela: não precisamos falar nada sobre isso. Cada pixel conta e sabemos disso muito bem, então escolha sabiamente como usar os elementos para tirar total proveito da sua área de exibição.
Sofisticação no formulário deve respeitar uso geral dos forms: é algo que todos os usuários estão familiarizados a usar e vão fazê-lo bem, mas nem todo mundo estará confortável em usar um slider de range, com acionamento duplo.
O form deve respeitar o conhecimento público nos domínios da sua app: É aceitável você usar um para um campo que aceita valores entre 0 e 1000. Mas isso iria requerer uma validação para certificar que numeros maiores ou negativos fossem inputados. Se a maior base dos seus usuários está confortável com esta regra, não existe o motivo de usarmos o mesmo slider de range mencionado acima, por todos os problemas de implementação, tempo, acessibilidade e principalmente, dificuldade de uso.
Elementos externos criam expectativas que podem ser erradas: Temos o conhecimento que negrito, itálico e sublinhado são iconografias que foram criadas para dar um destaque a alguma palavra. Fica fora de contexto utilizarmos estas formas para exibir labels por exemplo.

Olha o fast-food “encostando uma arma na sua cabeça” ao perguntar o que é mais saudável.
Tecnologia disponível: o HTML e suas APIs oferecem suporte a muitos elementos de controle, e para os que não são suportados nativamente, existe uma grande gama de toolkits e frameworks que vai te ajudar a implementar aparência e controle em situações específicas.

Elementos de controle de Formulários

Para fazer o design de uma tela de formulário, precisamos de elementos de controle. No jargão do HTML, seriam elementos HTML, que nada mais é que o conteúdo que está dentro de uma tag, podendo inclusive ter outros elementos filho caso seja do interesse. Dito isso, fica muito mais fácil entender como o design trabalha com elementos de controle. Após escolher seus elementos na tabela abaixo, tudo que você precisa é codificá-los seguindo os padrões que já conhecemos.

Montar uma tela de formulário não é complicado. Estamos acostumados a fazer isso todos os dias. Porém existem mais coisas entre o céu e a terra do que pode imaginar a nossa vã filosofia. O tópico acima mostra algumas variáveis que as vezes podem passar desapercebido e podem ajudar – e muito na hora de montar o design da sua tela. Você consegue se imaginar trabalhando orientado ao Responsive Webdesign sem utilizar os conceitos básicos mostrados acima? Pode parecer óbvio, mas é importante manter isso em mente ao utilizar a tabela abaixo:

Elementos de controle em um formulário são divididos em:

Causa	Tipo de interação	Elementos aceitáveis	Prós	Contras
Seleções e listas	Escolhas binárias	Checkbox	Simples e pouco espaço utilizado na tela	Checkbox podem ser usadas para múltiplas escolhas, coisa que usuários já estão acostumados ao visualizá-las. Isso pode levar ao erro, uma vez que é necessário entender que este checkbox único compreende uma escolha sim/não
Seleções e listas	Escolhas binárias	Radio button	Duas opções visíveis. Fácil entendimento do usuário	Espaço de tela usado maior que checkboxes únicas
Seleções e listas	Escolhas binárias	Dropdown	Duas opções visíveis. Pouco espaço utilizado na tela. Permite expansão para múltiplas opções facilmente utilizando pouco espaço da tela	Apenas uma opção é visualizada por vez. Requer alguma destreza no uso de formulários. Pode oferecer desafios de acessibilidade a pessoas com deficiência ou que preferem navegação pelo teclado.
Seleções e listas	Escolhas binárias	Toggle Buttons Iconográficos	Mesmos prós do checkbox, desde que a opção seja mostrada como ícone visual	Mesmos contras o checkbox, além do fato que não é uma opção padrão para seleção de texto como checkboxes.
Seleções e listas	Escolhas binárias	Menu com Radio button	Espaço mínimo utilizado na tela uma vez que o menu é encontrado em barras ocultas de menu ou lightboxes.	Requer muita destreza para encontrá-los e utilizá-los. Necessitam de indicações para que sejam fáceis de ser encontrados em uma tela.
Seleções e listas	Escolha 1 de N para poucas opções	Radio button	Todas as opções estão sempre disponíveis na tela.	Utiliza um espaço considerável na tela.
Seleções e listas	Escolha 1 de N para poucas opções	Dropdown	Pouco espaço utilizado na tela.	Enquanto o menu nao está expandido, mostra apenas uma das opções. Novamente requer alguma destreza para operá-lo e pode tambem oferecer desafios de acessibilidade.
Seleções e listas	Escolha 1 de N para poucas opções	Toggle Buttons Iconográficos	Pouco espaço utilizado na tela. Todas as opções estão visíveis na tela.	Os ícones podem precisar de tooltips para descrição, uma vez que a imagem pode não ser de fácil entendimento para todos os usuários.
Seleções e listas	Escolha 1 de N para poucas opções	Menu com Radio button	Espaço mínimo utilizado na tela uma vez que o menu é encontrado em barras ocultas de menu ou lightboxes.	Requer muita destreza para encontrá-los e utilizá-los. Necessitam de indicações para que sejam fáceis de ser encontrados em uma tela.
Seleções e listas	Escolha 1 de N para poucas opções	Listbox	Muitas opções podem ser visíveis. O frame de seleção pode ser reduzido para até 3 items, permitindo scroll	Espaço de tela usado maior que dropdowns ou spinners. Necessita aplicação de padrões de seleção, permitindo seleção única apenas.
Seleções e listas	Escolha 1 de N para poucas opções	Spinner	Pouco espaço utilizado na tela.	Apenas uma opção é visualizada por vez. Requer muita destreza no uso de formulários e conhecimento deste elemento, pouco utilizado até o lançamento dos novos input types no HTML5. Pode oferecer desafios de acessibilidade a pessoas com deficiência, que preferem navegação pelo teclado ou ainda usuários com ponteiros (mouse) já que a área de clique é mínima.
Seleções e listas	Escolha 1 de N para muitas opções	Dropdown	Pouco espaço utilizado na tela.	Apenas uma opção é visualizada por vez. Requer muita destreza no uso de formulários. Pode oferecer desafios de acessibilidade a pessoas com deficiência, que preferem navegação pelo teclado ou ainda usuários com ponteiros (mouse) já que a área de scroll é mínima.
Seleções e listas	Escolha 1 de N para muitas opções	Listbox	Muitas opções podem ser visíveis. O frame de seleção pode ser reduzido para alguns items de modo a ganhar espaço (permitindo scroll)	Espaço de tela usado maior que dropdowns. Necessita aplicação de padrões de seleção, permitindo seleção única apenas.
Seleções e listas	Escolha 1 de N para muitas opções	Treeview	Muitas opções visíveis inicialmente, pode oferecer facilidades na cognição já que seus items estarão categorizados por níveis ou tipos (pastas)	Grande espaço utilizado na tela. Requer muita destreza no uso de formulários.
Seleções e listas	Escolha N de N para muitas opções	Array de checkboxes	Todas as opções estão sempre disponíveis na tela.	Grande espaço utilizado na tela.
Seleções e listas	Escolha N de N para muitas opções	Array de Toggle Buttons Iconográficos	Pouco espaço utilizado na tela. Todas as opções estão visíveis na tela.	Os ícones podem precisar de tooltips para descrição, uma vez que a imagem pode não ser de fácil entendimento para todos os usuários.
Seleções e listas	Escolha N de N para muitas opções	Menus com Checkboxes	Espaço mínimo utilizado na tela uma vez que o menu é encontrado em barras ocultas de menu ou lightboxes.	Requer muita destreza para encontrá-los e utilizá-los. Necessitam de indicações para que sejam fáceis de ser encontrados em uma tela.
Seleções e listas	Escolha N de N para muitas opções	Listbox	Muitas opções podem ser visíveis. O frame de seleção pode ser reduzido para alguns items de modo a ganhar espaço (permitindo scroll)	Todas as opções não estão disponíveis na tela, requerendo scroll. Usuário precisa de indicações de que a caixa permite múltiplas seleções. Requer muita destreza no uso de formulários. Pode oferecer desafios de acessibilidade.
Seleções e listas	Escolha N de N para muitas opções	Treeview	Muitas opções visíveis inicialmente, pode oferecer facilidades na cognição já que seus items estarão categorizados por níveis ou tipos (pastas)	Grande espaço utilizado na tela. Requer muita destreza no uso de formulários.
Seleções e listas	Escolha N de N para muitas opções	Listbuilder	Items selecionados são de fácil visualização. Pode permitir fácil expansão para escolha e ordenação de items. Lida facilmente com grandes listas.	Grande espaço utilizado na tela. Funciona bem para grandes listas com poucas seleções. Muitas seleções oferecem dificuldades na visualização.
Seleções e listas	Criando listas não ordenadas	Caixa com botão de adição/novo	Ação de adicionar registro é visível e óbvia para o usuário	Grande espaço utilizado na tela. Visualmente bagunçado quando usuário insere muitos items.
Seleções e listas	Criando listas não ordenadas	Caixa com edição in-place	Menor uso de tela. A adição é feita in-place, dentro da caixa	Ação de adição não é tão óbvia quanto a caixa com botão de adição
Seleções e listas	Criando listas não ordenadas	Caixa com edição drag-n-drop	Visualmente elegante e de fácil entendimento, uma vez que arrastar é uma ação intuitiva	Necessita de indicações que mostram que na caixa existe uma área de arrastar.
Seleções e listas	Criando listas ordenadas	Caixa com botões acima/abaixo para ordenação	Ações de rearranjo sempre visíveis na página.	Grande espaço utilizado na tela.
Seleções e listas	Criando listas ordenadas	Caixa com drag-n-drop de items	Visualmente elegante e de fácil entendimento, uma vez que arrastar é uma ação intuitiva	Necessita de indicações que mostram que na caixa existe uma área de arrastar.
Texto	Inputs para uma linha de texto	Textbox	–	–
Texto	Múltiplas linhas de texto não formatado	Textarea	–	–
Texto	Múltiplas linhas de texto formatado	Textarea que permite tags inline	Usuários avançados podem evitar o uso da toolbar inputando as tags diretamente	Não é realmente um editor WYSIWYG
Texto	Múltiplas linhas de texto formatado	Editor Rich text	Texto inputado já serve de preview.	Nao permite edição apenas pelo teclado. É necessário o uso da toolbar para adicionar as tags necessárias.
Números	Números com qualquer tipo de formato	Textbox com máscaras	Visualmente elegante e permite qualquer tipo/formato de tipos de dado	Requer validação no back-end.
Números	Números com qualquer tipo de formato	Textbox estruturado e com máscaras	Formato dos dados é explícito, facilitando preenchimento e entendimento do usuário	Pode requerer grande espaço na tela. Também não permite inputs diferentes dos previstos, mesmo que o usuário deseje isso.
Números	Números com qualquer tipo de formato	Spinner	Permite input sem o uso de teclado caso deseje o usuário	Apenas uma opção é visualizada por vez. Requer muita destreza no uso de formulários e conhecimento deste elemento, pouco utilizado até o lançamento dos novos input types no HTML5. Pode oferecer desafios de acessibilidade a pessoas com deficiência, que preferem navegação pelo teclado ou ainda usuários com ponteiros (mouse) já que a área de clique é mínima.
Números	Números dentro de um limite pre-definido	Slider	Metáfora óbvia, valor é mostrado de acordo com a posição do marcador. Usuário não pode inputar números fora deste range	Pode requerer grande espaço na tela. Labels muito grandes podem se transformar em um problema também
Números	Números dentro de um limite pre-definido	Spinner	Pouco espaço utilizado na tela, permite inputs direto pelo teclado e tambem via clique	Não é familiar para todos os usuários. Pode oferecer desafios de acessibilidade a pessoas com deficiência, que preferem navegação pelo teclado ou ainda usuários com ponteiros (mouse) já que a área de clique é mínima. Requer validação no back-end.
Números	Números dentro de um limite pre-definido	Textbox com validação pós-input	Familiar ao usuário, pouco espaço utilizado na tela, acesso via teclado.	Requer validação no back-end. Range não é visível para o usuário, requer indicações dos limites para input.
Números	Números dentro de um limite pre-definido	Slider com textbox	Permite inputs visuais(slide) e numéricos(input manual)	Complexo, requer validação dos inputs no textbox.
Números	Criando um subrange dentro de um range maior	Slider duplo	Menor uso de tela quando comparado com 2 sliders.	Não é familiar para a maioria dos usuários. Problemas graves de acessibilidade porque não permite inputs via teclado.
Números	Criando um subrange dentro de um range maior	2 Sliders	Utilização mais fácil que um slider duplo.	Grande espaço utilizado na tela. Problemas graves de acessibilidade porque não permite acesso via teclado.
Números	Criando um subrange dentro de um range maior	2 Spinners	Pouco espaço utilizado na tela, permite inputs direto pelo teclado e tambem via clique	Não é familiar para todos os usuários. Requer validação no back-end. Não permite visualização do range maior.
Números	Criando um subrange dentro de um range maior	Textbox com validação pós-input	Familiar para o usuário, ocupa menos espaço que sliders	Requer validação e é necessário informar o range de alguma maneira para o usuário.
Data / Horário	–	Textbox com máscaras	Visualmente simples, permite amplo range de formatos. Permite acesso via teclado	Requer validação back-end. Pode causar confusão no formato data/hora por não haver indicações explicitas.
Data / Horário	–	Textbox estruturado e com máscaras	Formato dos dados é explícito, facilitando preenchimento e entendimento do usuário	Pode requerer grande espaço na tela. Também não permite inputs diferentes dos previstos, mesmo que o usuário deseje isso.
Data / Horário	–	Datepicker	Metáfora óbvia, calendário é exibido e a seleção do valor faz o input	Grande espaço utilizado na tela. Pode oferecer problemas de acessibilidade caso não se permita acesso via teclado.

Seleções e listas:

Seleções binárias: sim/não, ativo/inativo, etc;
Escolha de UM item para N com poucas e muitas opções;
Escolha de N items para N com poucas e muitas opções;
Listas não-ordenadas;
Listas ordenadas.

Texto:

uma linha de texto;
múltiplas linhas de texto não formatados e formatados

Números:

com qualquer formato;
dentro de um range (limite);
subrange (sublimite);

Data e hora.

Use a tabela acima para escolher os melhores elementos de tela de acordo com sua necessidade. Você perceberá que as opções cobrem todas as necessidades atuais, alinhadas ao HTML5.

Padrões para Elementos de Controle

Os elementos de controle acima necessitam de padrões de funcionamento. Estes padrões mostram:

Como combinar elementos;
definir relações estruturais entre elementos;
controlar mudanças de valores e como estes valores são alterados

Alguns elementos de controle possuem requisitos de funcionamento que já estão aplicados ao elemento em si (spinners ou datepickers já possuem seu comportamento nativo no elemento graças ao HTML5). Outros necessitam de programação no back-end, seja para validação, seja para a criação de ranges, seja para outras necessidades específicas. Quanto mais versátil o elemento, maior a possibilidade de usá-los. Um bom exemplo seriam input type=”text” que com frequência possuem funcionalidades específicas, alem de aceitar qualquer coisa textual.

Máscaras:

Máscaras permitem texto em qualquer formato ou sintaxe, fazendo com que o input do usuário seja interpretado de maneira inteligente, a medida que é digitado no campo.

Máscaras são usadas quando sua interface necessita de dados que usuários podem inputar usando qualquer tipo específico de conteúdo, porém não possuem a obrigação de conhecer estes formatos automaticamente:

remover espaços,
inserir apenas números (ou texto),
texto sempre em caixa alta (ou caixa baixa),
abreviações, etc.

Usuários querem que a ação (submeter o formulário) aconteça, não querem (nem devem) se preocupar com formatos corretos e interfaces complexas. Jacob Nielsen já dizia que “Usabilidade na web passa pelo fato de que como desenvolvedores de interface, não podemos deixar o usuário pensar demais para fazer uma ação. Ele simplesmente tem que fazê-la de maneira cognitiva”. Máscaras podem inclusive remover a necessidade de dicas no input ou dicas no prompt.

Formato estruturado:

Estruturar um campo de input significa quebrar um campo em vários outros, de modo a facilitar o entendimento do que é esperado que o usuário faça. Um bom exemplo seria quebrar um campo único de CEP por exemplo em dois campos, um para os primeiros 5 números, e outro campo para os 3 restantes. Outros exemplos podem ser mencionados: números de telefone, numeros de cartão de crédito (cartões AMEX tem um numero de caracteres diferente de cartões VISA por exemplo).

Fill-in-the-blanks: Combine um ou mais campos de modo a permitir que o usuário possa categorizar o que está inputando, facilitando a ação do usuário. Um bom exemplo seria um formulário de pesquisa em uma loja virtual:

Usar esta abordagem faz com que a interface seja auto-explicável. Ajuda ao usuário entender o que está acontecendo e o que foi pedido para ele.

Dicas no input: As dicas no input são importantes para fornecer um guideline ao usuário de como ele deve inputar valores dentro de um campo. O exemplo abaixo, retirado de um form do site dos correios para rastreamento de objetos ilustra bem isso.
Placeholder no input: O placeholder é um texto adicionado dentro do input e que automaticamente desaparece quando o usuário posiciona o cursor da tela dentro do campo. Um bom exemplo pode ser visto no form de busca das páginas do portal globo.com.
Auto complete: O nome é auto-explicativo. A medida que o usuário vai digitando caracteres, os termos são auto-completados, fazendo com que o input seja mais rápido caso o resultado esteja disponível no índice usado. Veja o form de search no site do google.com.br
Dropdown chooser: Dropdowns podem ser usadas para acomodar seleções que podem utilizar um grande espaço na tela quando expandidas, porém não tem a necessidade direta de deixar todas as opções disponíveis (que usualmente são muitas). Um bom exemplo é a dropdown de seleção de cores no Google Docs.
Seleção ilustrada: Em alguns casos descrever a opção não é suficiente. É necessário ilustrá-la com uma imagem para facilitar a seleção do usuário. Um bom exemplo é esta dropdown de seleção de papel de parede disponível no site do livro Designing with Progressive Enhancement.
List Builder: Quando você precisa criar uma lista de items oriundos de uma outra lista, o listbuilder é o padrão ideal a ser usado. Duas textareas e programação fazem com que valores possam ser adicionados ou removidos, além de também poderem ser ordenados facilmente. Veja este exemplo de listbuilder para a configuração de uma toolbar:

Mensagens de erro:
Quando o usuário faz algo correto ele recebe um feedback de sucesso, informando que o formulario foi submetido sem problemas. Mas também é necessário informar de maneira clara quando algo dá errado. Mensagens de erro podem ser customizadas de modo a evitar deixar o usuário “no escuro” quando algum erro acontece. Campos obrigatórios precisam de validação (agora mais simples com o atributo required presente no HTML5), mas podem acontecer outros erros que necessitam de feedback claro para indicar quais os próximos passos a seguir.

Você pode usar o poster abaixo como referência para criar suas interfaces. Clique na imagem para vê-la em uma maior resolução.

Na próxima semana, com a Parte 2, a abstração dá o lugar ao código para saber como montar os items que você selecionou para montar seus formulários, transformando os dois posts em um toolkit para o dia-a-dia. Namastê!

Referências

Metawebdesign – Quando o Front-end se encontra com a experiência do usuário: http://www.slideshare.net/AlyssonFranklin/metawebdesign-frontend
O Metawebdesign – http://metawebdesign.org
Designing Interfaces – Second Edition (Jenifer Tidwell- O’Reilly books) http://designinginterfaces.com/
Top-down e bottom-up design: http://en.wikipedia.org/wiki/Top%E2%80%93down_and_bottom%E2%80%93up_design
Everybody lies, uma frase do House: http://www.youtube.com/watch?v=nNOExDrsdbg
W3C sobre formulários: http://www.w3.org/TR/html4/interact/forms.html#h-17.1
http://www.mhavila.com.br/topicos/web/controles.html
Spinner: http://www.jgeppert.com/jquery-spinner/
A Form of madness: http://diveintohtml5.org/forms.html
Responsive webdesign: http://www.alistapart.com/articles/responsive-web-design/
Composição de um time multidisciplinar de UX - http://itweb.com.br/blogs/a-composicao-de-um-time-multidisciplinar-de-ux/
UX Team of One - http://www.slideshare.net/ugleah/how-to-be-a-ux-team-of-one

Posts Relacionados

Utilizando a Biblioteca Modernizr

Diego Eis — Mon, 17 Oct 2011 13:52:28 +0000

Problemas de compatibilidade

Quando produzimos um site os problemas de compatibilidade fazem parte da regra do jogo. Para tentar contornar estes problemas utilizamos hacks, comentários condicionais, sniffing de browsers e outras coisas, que muitas vezes mais prejudicam do que ajudam.

Para ajudar mais ainda o CSS3 e o HTML5 apareceram derrubando tudo, e o problema de compatibilidade que já era chato, ficou mais chato que meia molhada. Embora os browsers estejam muito mais atuais e suportando propriedades avançadas de CSS3 e HTML5, não é garantia que todos eles suportem as mesmas propriedades. E é aqui que começamos a ter problemas novamente, como no passado.

Como você consegue reconhecer quem um determinado browser suporta CSS Animation? Como você sabe que o browser conhece LocalStorage do HTML5? Você não vai ficar olhando numa tabelinha toda vez que tiver essas dúvidas para fazer um visual ou uma solução alternativa para tais browsers.

É por essas e outras que você utilizará a Modernizr.

O que é a Modernizr

Modernizr é uma pequena biblioteca Javascript que detecta a disponibilidade das novas características do HTML5 e CSS3 nos browsers. Muitas destas características já estão implementadas nos browsers, mas é muito chato você decorar quais novidades os browsers já estão suportando. O que a Modernizr faz é simples: ela te diz quais features um determinado browser suporta e insere classes no HTML para que você possa utilizar para fazer uma versão alternativa de visual ou solução.

Entenda que a Modernizr não é um sniffing de browser. Ela é diferente. A Modernizr faz o trabalho de detectar das seguintes formas:

Ela testa 40 features de CSS3 e HTML5 em alguns milisegundos.
Depois ela cria objetos javascript que contém os resultados destes testes.
Aí são adicionadas classes no elemento HTML descrevendo exatamente quais propriedades e novidades são ou não nativamente suportadas.
Depois disso você consegue ter os resultados descritos nos navegadores dinamicamente e então pode tomar decisões criando alternativas para aquelas propriedades não suportadas pelos browsers antigos.

Como funciona

É simples: primeiro você baixa a versão mais atual da biblioteca no endereço http://www.modernizr.com/. O interessante é que você tem a opção para personalizar a biblioteca, indicando quais features você quer que a Modernizr teste no seu projeto.

Depois você inclui esse pacote no seu HTML:

1
2
3
4
5
6
7
8
9
10
11
12

<html lang="pt-br">
<head>
<meta charset="utf-8">
<title>Teste de Modernizr</title>
<script src="modernizr-2.0.6.js"></script>
</head>
<body>

</body>
</html>

Feito isso, insira uma classe no-js no elemento HTML:

1	<html class="no-js" lang="pt-br">

Quando a Modernizr rodar, ela irá substituir essa classe para uma js se o browser estiver com o Javascript ligado, já te dando um feedback para tomar alguma atitude se o usuário estiver com o Javascript desligado.

Junto com essa mudança são adicionadas outras classes, indicando o que o browser aceita nativamente ou o que ele não aceita. Ficará algo parecido com isso:

O browser que eu utilizei é o Safari/Mac. Pelo visto ele aceita bastante coisa.
O que o browser não aceita, a Modernizr insere uma classe com o prefixo no- antes da classe, por exemplo: no-boxshadow, no-geolocation, no-touch etc.

A Modernizr também cria um objeto Javascript contendo um valor booleano para cada uma dessas features, possibilitando a criação de testes. Um exemplo:

1
2
3
4
5

if (Modernizr.geolocation) {
alert("Aceita")
} else {
alert("Não Aceita")
}

Exemplos de utilidade

Exemplo bem básico: imagine que você queira utilizar o box-shadow em seu projeto. Browsers como o IE6,7,8 não reconhecem essa feature, então seria interessante darmos uma alternativa, como por exemplo, colocando uma borda em vez de sombra. Assim o elemento não fica tão diferente do que deveria.

Como a Modernizr colocou uma classe no elemento HTML referente a aceitação das features, podemos utilizá-la fazendo assim:

1
2
3
4
5
6
7
8

.loginBox {
box-shadow:0 10px 10px rgba(0, 0, 0, 0.3);
}

.no-boxshadow .loginBox {
border: 1px solid #CCC;
border-bottom: 3px solid #CCC;
}

Assim, se o browser não aceitar a propriedade box-shadow o usuário verá uma borda no lugar. Você pode fazer isso com praticamente qualquer nova feature do CSS3 e do HTML5. Uma listagem completa dessas features suportadas está aqui.

Ah, mais uma coisa: provavelmente você já utiliza um scriptzinho html5.js para fazer com o que os Internet Explorers reconheçam as tags do HTML5, correto? O Modernizr já faz isso automaticamente. Sugiro que pare de utilizar o html5.js e passe a utilizar a Modernizr somente.

A Modernizr facilita demais as coisas. A ideia é que você não prive seus projetos da utilização de features novas. A produção vai ficar mais eficaz e seu projeto sempre estará atualizado com as melhores práticas do mercado. Adote a Modernizr e seja feliz.

Sugiro que você dê uma lida na documentação da Modernizr. Tem bastante coisa interessante lá que você deveria saber.

Posts Relacionados

Testando seu código jQuery com Jasmine – Parte 2

Davi Ferreira — Tue, 04 Oct 2011 14:12:30 +0000

Jasmine é um framework para testes focado em BDD (Behavior Driven Development). Na primeira parte deste artigo aprendemos seus métodos básicos e realizamos alguns testes simples. Agora chegou a hora de ir um pouco além e conhecer técnicas mais avançadas.

Vale lembrar que, em nossos exemplos, utilizamos uma versão modificada da biblioteca, adaptada para jQuery: jasmine-jquery.

Utilizaremos os dados de um outro artigo, Conteúdo sob demanda com jQuery. O objetivo é testar as solicitações AJAX do carregamento da lista de tweets do Tableless.

Fixtures

Antes dos testes propriamente ditos vamos conhecer uma forma prática de carregar nosso conteúdo HTM. Fixtures são arquivos carregados através do método loadFixtures. Esta funcionalidade, aliás, está disponível apenas no jasmine-jquery.

Vamos salvar o código HTML abaixo no arquivo tweets.html, dentro do diretório de fixtures.

1
2
3
4
5

id="container">
>Tweets do Tableless>
id="lista-tweets">>
> href="#" id="carrega-tweets" data-pagina="1">Mais!>>
>

Por padrão, o jasmine-jquery procura as fixtures no diretório spec/javascripts/fixtures. Como na primeira parte do artigo indicamos uma estrutura diferente, utilizando o diretório spec/fixtures, precisamos atualizar a propriedade fixturesPath nas configurações do Jasmine.

1
2
3
4
5
6
7
8
9
10
11

jasmine.getFixtures().fixturesPath = 'spec/fixtures/';

describe('Exibição dos últimos tweets do Tableless', function(){
beforeEach(function(){
loadFixtures('tweets.html');
});

it('Deve carregar na primeira página', function(){
expect($('#carrega-tweets').data('pagina')).toEqual(1);
});
});

Outra forma de utilizarmos fixtures é carregando diretamente no código, sem a necessidade de um arquivo HTML. Esse caso é mais indicado para templates mais simples, com poucos elementos.

1	setFixtures(' ');

Testando código assíncrono

Testar código AJAX pode ser um pouco mais complicado. No nosso exemplo, como acessamos uma URL externa à nossa aplicação, o tempo de resposta vai depender de vários fatores, como velocidade da conexão, estabilidade do Twitter etc.

Os métodos runs e waits são úteis para tentar simular esse tempo de carregamento. O runs executa os testes e funções um escopo próprio e, além disso, são executados em sequência (quando um termina, o outro começa). Já o método waits funciona como uma espécie de pausa/sleep e recebe como parâmetro o tempo em milissegundos.

1
2
3
4
5
6
7
8
9

it('Deve carregar os últimos 20 tweets', function(){
runs(function(){
Tableless.retorna_tweets(1);
});
waits(1500);
runs(function(){
expect($('#lista-tweets li').length).toEqual(20);
});
});

Espionando métodos

Às vezes precisamos testar se um método de um objeto é chamado (e com que parâmetros) — e não testar apenas seu resultado. O Jasmine oferece a função spyOn para capturar e validar essas chamadas. O spyOn recebe dois parâmetros: o objeto e o nome do método.

1
2
3
4
5

it('Deve executar função para retornar tweets', function(){
spyOn(Tableless, 'retorna_tweets');
Tableless.retorna_tweets(1);
expect(Tableless.retorna_tweets).toHaveBeenCalledWith(1);
});

Acima testamos se o método foi chamado com o parâmetro 1 (página). Poderíamos ter utilizado também toHaveBeenCalled, testando apenas a chamada. As funções de spy podem ainda ser combinadas com o not, por exemplo:

1	expect(Tableless.retorna_tweets).not.toHaveBeenCalled();

Matchers personalizados

Outra funcionalidade poderosa do Jasmine é a possibilidade de criação de matchers personalizados. Os matchers são asserts para seus tests. No exemplo abaixo, criamos o matcher toBeATweet para validar se um elemento possui a classe “tweet”.

1
2
3
4
5
6
7

beforeEach(function(){
this.addMatchers({
toBeATweet: function(){
return this.actual.hasClass('tweet');
}
});
});

1	expect($('#lista-tweets li:first')).toBeATweet();

O método addMatchers deve ser executado dentro do beforeEach, utilizando o Jasmine como contexto. Notem que ele recebe um objeto que pode conter um ou mais matchers personalizados. No código, this.actual representa a variável, elemento, ou objeto que estará sendo passado ao expect.

Outros projetos utilizando Jasmine

Nesses dois artigos vocês conheceram o jasmine-jquery, mas existem diversos outros projetos baseados no framework Jasmine, incluindo adaptações para NodeJS, Rails e iPhone e snippets para Vim e TextMate. A lista completa você confere no wiki do projeto no Github.

Referências

Posts Relacionados

Testando seu código jQuery com Jasmine – Parte 1

Testando seu código jQuery com Jasmine – Parte 1

Davi Ferreira — Mon, 12 Sep 2011 14:08:39 +0000

Durante muito tempo testar/debugar JavaScript era uma tarefa árdua (infelizmente, em alguns navegadores, ainda é). Quem aí se lembra do tempo em que não existia Firebug, por exemplo? E o tamanho dos scripts? Um simples menu drop-drown possuía umas 1.500 linhas de código. Não existia jQuery ou qualquer outro tipo de framework. Tempos difíceis.

Hoje a tarefa do desenvolvedor é muito mais fácil. Para debug temos o já citado Firebug e o Developer Tools do Chrome, entre outros. Nos testes, além do Jasmine, outro framework bem legal é o QUnit. O Jasmine, por focar em BDD, possui uma sintaxe mais fluida. Quem programa em Ruby/Rails vai notar a enorme semelhança com a ferramenta RSpec.

Nos exemplos vou utilizar uma versão modificada do Jasmine, jasmine-jquery. Ela possui alguns métodos próprios para o framework além de funções para carregar fixtures (templates).

Baby steps

Começar a trabalhar com uma cultura de testar sempre antes de desenvolver é bem difícil, principalmente para quem já está acostumado a programar antes e testar depois (manualmente). Comece devagar, sem medo. No início as coisas serão um pouco confusas, mas depois de adotar essa prática, você vai se perguntar como era possível programar sem testes.

O que testar e que testes escrever? Isso também vem com o tempo. Comece testando uma ou outra funcionalidade principal de um aplicativo já existente. Entenda como funciona a sua ferramenta de testes. Depois de um tempo comece a acreditar e confiar na sua intuição.

Procure sempre utilizar um conjunto variado de possibilidades, desde as mais óbvias até as mais inusitadas. Pense nos diferentes contextos, em tudo que interage com seu aplicativo: navegadores, sistemas operacionais, usuários, dados de entrada, scripts de terceiros etc.

Testes não evitam que seu software, uma vez finalizado, tenha bugs; não são a solução para todos os seus problemas de deploy, mas facilitam bastante essas etapas.

Red → Green → Refactor

O padrão básico a ser seguido é o seguinte:

Escreva o teste — naturalmente, ele vai falhar;
Escreva, sem se preocupar muito com qualidade, o código mais simples, que faça o teste passar;
Reescreva seu código, implementando melhorias de performance, escalabilidade e removendo duplicidades.

Configurando o jasmine-jquery

Baixe a última versão do jasmine-jquery e vamos começar com nossos primeiros testes. A estrutura de pastas do nosso aplicativo deve ficar da seguinte maneira:

1
2
3
4
5
6
7
8
9
10

- /
- /tests
- /lib
- /spec
- /fixtures
- /suites
- saudacao-spec.js
- /vendor
- SpecRunner.html
- tableless.js

Note que criamos um diretório “tests” onde ficarão todos os arquivos dos nossos testes, incluindo a biblioteca Jasmine. O arquivo SpecRunner.html é o responsável por executar e exibir os resultados dos testes, basta abri-lo no navegador. Dentro do diretório “tests/spec” ficarão nossos conjuntos de testes (suites) e nossos templates HTML (fixtures).

No início do SpecRunner ficam as chamadas para os testes:

1	<script type="text/javascript" src="spec/suites/saudacao-spec.js">script>

Você também pode incluir aqui qualquer javascript personalizado necessário para os testes. No nosso caso vamos incluir o arquivo tableless.js, que fica na raiz do nosso aplicativo.

1	<script type="text/javascript" src="../tableless.js">script>

Nosso primeiro teste

Vamos supor o seguinte: uma página deve exibir uma mensagem de boas-vindas para o usuário que varia de acordo com o horário. De 5 da manhã ao meio-dia, exibe “Bom dia!”; de meio-dia até 6 da tarde, exibe “Boa tarde!”; de 6 à meia-noite, exibe “Boa noite!”; e, por fim, de meia-noite até 6 da manhã exibe “Dormir é para os fracos!”. A mensagem fica sempre dentro de um elemento div com id “mensagem”. Os horários vão desde a hora inicial (incluída) até a hora final. A função pode receber como parâmetro uma hora no formato hh:mm ou, caso não receba nada, exibe a mensagem de acordo com a hora do usuário.

Esse é um bom começo para seus testes, tente escrever, em um parágrafo, o que deve ser executado e o que é esperado. Trabalhe sempre com um pedaço de papel por perto, para rascunhos.

Vejamos como ficaria o desenho inicial dos nossos testes. Crie o arquivo /tests/spec/suites/saudacao-spec.js e digite o seguinte código:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

describe('Exibição da mensagem de boas-vindas', function(){
beforeEach(function(){
setFixtures('

');
this.mensagem = $('#mensagem');
});

afterEach(function(){
this.horas = [];
});

it("Deve exibir 'Bom-dia!' entre 5:00 e 11:59", function(){
});

it("Deve exibir 'Boa-tarde!' entre 12:00 e 17:59", function(){
});

it("Deve exibir 'Boa-noite!' entre 18:00 e 23:59", function(){
});

it("Deve exibir 'Dormir é para os fracos!' de 00:00 a 04:59", function(){
});

it("Deve exibir, por padrão, a mensagem de acordo com a hora do cliente", function(){
});
});

Na raiz do aplicativo, crie um arquivo chamado “tableless.js”. Nele nós escreveremos nossa função para exibir a mensagem de acordo com a hora. Sua estrutura inicial é a seguinte:

1
2
3

function saudacao(hora_atual){
var hora;
}

Os conceitos básicos dos nossos testes giram em torno de três funções: describe, it e expect. Outras funções úteis, mas que nem sempre estarão presentes, são as funções beforeEach e afterEach. Também trabalhamos com uma função do jasmine-jquery, a setFixtures — falarei mais sobre ela na parte 2, por enquanto você só precisa saber que ela define templates/elementos no DOM.

describe — representa um conjunto de testes/comportamentos. Podem existir situações dentro de situações, por exemplo:
1
2
3
4
5
6
7
describe('Login', function(){
describe('Sucesso', function(){
});

describe('Falha', function(){
});
});
it — define um teste, uma ação. Por exemplo, “It should validate the username”, ou, “Deve validar o nome do usuário”, seria uma boa situação para nosso teste de login.
expect — espera que alguma variável ou retorno de função seja igual a alguma coisa, ou verdadeiro, ou falso etc. Nos testes acima utilizamos apenas um tipo de validação, o matcher “toEqual”. Todo o teste deve ser chamado com a função expect, utilizando um dos matchers disponíveis (mais sobre eles na parte 2). Os principais são: toEqual, toContains, toBeTruthy e toBeFalsy.
beforeEach — executada antes de cada teste dentro de um conjunto, muito útil para configurar elementos.
afterEach — executada depois de cada teste dentro de um conjunto, ideal para reiniciar variáveis.

Escrevendo os testes

Agora chegou a hora de preencher os nossos testes. Os testes que verificam a mensagem entre uma hora e outra seguirão um mesmo padrão. Dado um conjunto de horas válidas, a função saudacao deve retornar a mensagem correta.

1
2
3
4
5
6
7

it("Deve exibir 'Bom-dia!' entre 5:00 e 11:59", function(){
this.horas = ['05:00', '09:33', '10:22', '11:59'];
for(i in this.horas){
saudacao(this.horas[i]);
expect(this.mensagem.text()).toEqual('Bom-dia!');
}
});

O teste que valida o retorno da função saudacao sem passagem de parâmetro busca a hora do cliente e exibe a mensagem de acordo com ela.

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

it("Deve exibir, por padrão, a mensagem de acordo com a hora do cliente", function(){
var data = new Date;
data.setTime(data.getTime());
var hora = data.getHours();

saudacao();

var texto = this.mensagem.text();
if(hora < 5)
expect(texto).toEqual('Dormir é para os fracos!');
if(hora < 12)
expect(texto).toEqual('Bom-dia!');
else if(hora < 18)
expect(texto).toEqual('Boa-tarde!');
else
expect(texto).toEqual('Boa-noite!');
});

Nesse momento, abrindo o SpecRunner no navegador, todos os nossos testes estarão falhando. Lembra da nossa regra? Red (falhou), Green (passou) e Refactor.

A função saudacao()

Abaixo segue a minha implementação da função saudacao(). Não me preocupei muito com repetições e performance. Meu objetivo principal era fazer o teste passar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Atualizando nossa SpecRunner veremos agora que todos os testes estão passando. Você pode (e deve) desenvolver aos poucos. Valide um teste de cada vez. Desenvolva com calma.

Melhorando nosso código

Como de praxe, vou deixar um dever de casa para vocês: a etapa de refactoring. O que podemos melhorar na nossa função saudacao()? E se o usuário passar uma hora atualmente inválida para nossa função, como “meio-dia”, “nove horas” etc. E se quisermos mudar o id do elemento #mensagem? E se quisermos exibir a saudação em mais de um elemento? Podemos melhorar algum nome de variável? Podemos reduzir o tamanho da nossa função? Nossa função está cumprindo seu objetivo? Tem algum código/texto repetido? E nossos testes? Estão cobrindo tudo? Prevendo todos os cenários?

O que não falta é opção para um bom refactoring.

Na segunda parte veremos a função spy, além de mais sobre fixtures, matchers personalizados e outros recursos avançados.

Referências

Posts Relacionados

Alternativas ao jQuery

Davi Ferreira — Wed, 17 Aug 2011 13:00:51 +0000

Apesar de toda a sua popularidade, não são poucas as alternativas para quem procura bibliotecas mais específicas, mais eficientes em certos aspectos e mais enxutas do que o jQuery.

Algumas foram a raiz do novo estilo de desenvolvimento JavaScript, visando uma maior legibilidade e facilidade de aprendizado e acabaram sendo responsáveis pelo atual estado das bibliotecas e frameworks JavaScript.

A curta curva de aprendizado e o leque de plugins fazem do jQuery um concorrente imbatível (com atualmente 50% do “mercado”), no entanto, bibliotecas como ExtJS, MooTools e Prototype possuem uma base fiel de usuários e mostram-se alternativas altamente viáveis para a implementação de JavaScript em suas aplicações.

MooTools + mocha(ui)

mootools.net
mochaui.org

Esse talvez seja o maior “rival” do jQuery. MooTools é a biblioteca favorita dos desenvolvedores e a disputa até resultou em um site bastante informativo, jQuery vs. MooTools.

Enquanto jQuery é um framework mais focado em HTML/CSS e animações, o objetivo do MooTools é oferecer mais poder para desenvolvedores, com foco em modularidade, orientação a objetos, flexibilidade. MooTools é voltado pra quem já desenvolve em JavaScript.

Assim como o jQuery possui o pacote jQuery UI, mocha(ui) é a biblioteca MooTools para interfaces, com opções de abas, dialogs, widgets etc.

ExtJS 4

sencha.com/products/extjs

Antes conhecido por YUI-ext (por ter sido baseado na biblioteca do Yahoo), o framework ExtJS pode ser bem complicado no início, mas é de todos o mais robusto no que diz respeito a interfaces de aplicações com opções para grids, layout, botões, gráficos e janelas.

Atualmente mantido pela empresa Sencha, o ExtJS vem nos sabores open source e comercial. Possui uma comunidade fortíssima com uma vasta documentação e, assim como o MooTools, é indicado para desenvolvedores com conhecimento em JavaScript.

Nesse link você confere algumas aplicações desenvolvidas em ExtJS, como, por exemplo, um leitor de feeds, um desktop web e um visualizador de imagens.

Prototype + Script.aculo.us

prototypejs.org
script.aculo.us

Prototype pode ser considerado o avô dos frameworks JavaScript. Alguns dizem que seu sucesso ocorreu por ter sido escolhido como a biblioteca padrão do Rails, mas o Prototype ficou conhecido mesmo através do plugin Lightbox, que acabou engolindo o próprio framework.

O Prototype conta com uma biblioteca a parte para efeitos visuais, a Script.aculo.us.

Os desenvoldeores do framework perderam a oportunidade de colocar o Prototype no topo da cadeia de desenvolvimento JavaScript. Seu código acabou ficando muito complicado perto de códigos desenvolvidos com jQuery e MooTools.

YUI 3

developer.yahoo.com/yui/3/

A biblioteca YUI (Yahoo User Interface) também foi pioneira e o seu diferencial sempre foi a gama de widgets, além, é claro, de ser a biblioteca oficial do Yahoo.

Como o próprio nome sugere, é focada na interface com usuário e foi uma das primeiras a oferecer scripts e módulos para abas, janelas, botões entre outros elementos.

Apesar de não estar relacionado com JavaScript, outro recurso que a deixou famosa foi o seu reset de CSS.

Dojo Toolkit

dojotoolkit.org

Biblioteca que melhor aplica os princípios da orientação a objetos e, por isso, é uma das mais indicadas para desenvolvedores e para projetos maiores.

Um dos seus principais destaques é o alto nível de modularização, permitindo até o carregamento de módulos somente quando eles forem necessários (lazy loading).

John Resig sobre as bibliotecas JavaScript

Para concluir, segue uma apresentação do criador do jQuery que, apesar de um pouco antiga (2008), é bem legal e fala sobre o framework e suas alternativas.

Posts Relacionados

Tenha o DOM

Alysson Franklin — Mon, 25 Jul 2011 16:35:41 +0000

Muito ja foi falado sobre DOM e posso estar sendo repetitivo aqui, mas é importante falar deste assunto que em dias de manipulação pesada de seletores, percebo que pouca atenção é dada. Temos muita literatura boa sobre o assunto mas muitas vezes o foco acaba sendo o novo plugin que saiu e faz mais-do-mesmo-no-front-end-só-que-mais-fácil (E se você tiver sorte ele é free).

Entender realmente como um navegador funciona é importante, e garante seu entendimento do real dos problemas que está enfrentando no código que está implementando. Tem mais! Criar um código que manipula o layout (leia-se DOM) fica mais fácil, é uma relação win-win.

Criado pelo W3C, O DOM é uma multi-plataforma que representa como as marcações em HTML, XHTML e XML são organizadas e lidas pelo navegador que você usa. Uma vez indexadas, estas marcações se transformam em elementos de uma árvore que você pode manipular via API – que é o que fazemos quando usamos programas ou scripts para alterar funcionalidades de uma página: conteudo, estrutura ou folha de estilo.

Um pouco de história

Não tem graça falar sobre o assunto sem mostrar como ele surgiu. Isso só reforça ainda mais a importância de conhecermos bem o assunto pois mostra sua relevância (e porque falar de browser wars é bem legal, apesar de evidenciar os cabelos brancos).

Netscape e Microsoft guerreavam com Netscape 2 e IE3.0 lá em 1996 e enquanto a Netscape lançava o Javascript a Microsoft lançava o JScript. A diferença entre um e outro não é nada mais além do nome – acredite! Por razões comerciais devido as “sangrentas” browser wars as empresas decidiram adotar nomes diferentes para a mesma coisa – que na verdade era (e continua sendo) o ECMAScript, a linguagem que comecou a ser criada em 1994 quando o W3C colocou na mesma mesa as duas empresas e várias outras para desenvolver um padrão para linguagens de script para os navegadores. Javascript, JScript e ActionScript não são nada mais que dialetos de ECMAScript.

O DOM em sua forma e como é reconhecido pelos navegadores

Representação de um documento HTML e sua árvore DOM

A figura acima mostra a estrutura de uma árvore DOM, a linearização das marcações de modo que ela possa ser montada inicialmente por um navegador. Esta estrutura não será o que veremos no navegador – o layout em si. O DOM é a base para uma outra árvore que é o que realmente um browser monta na tela, a Árvore de Renderização - aka Render Tree.

A base para todos os nós da árvore DOM é o base class chamado Node.h. Ele possui várias categorias, e as relevantes para renderizarmos código no navegador são os nós de documentos, elementos e texto.

Documentos é o nó mais importante do DOM, com três classes diferentes: Document, que é usado por todos os documentos XML e outros que não sejam SVG (que também é um XML, porém com marcação já padronizada), HTMLDocument que como o nome diz, cuida de documentos HTML e SVGDocument, responsável pelos documentos SVG e tambem por outros documentos herdados da classe Document (Como o Document.h e o HTMLDocument.h).
Elementos são todas as tags que estão em arquivos HTML ou XML se transformam em elementos da árvore DOM. Considerando a renderização do navegador, um elemento é um nó com uma tag que pode ser usada para fazer subclasses específicas que podem ser processadas de acordo com as necessidades da Render Tree (Element.h).
Texto: É o texto que vai entre os elementos. Todo o conteúdo das tags (
Isto é um text node
). O nó de Texto guarda basicamente texto puro, que pode ser renderizado ou trabalhado via script.

A Render Tree

Como a render tree é montada

A Render Tree é a parte mais importante do processo de renderização. Bem parecida com a árvore DOM, cada objeto corresponde a nós de Documentos, Elementos ou Texto. A diferença é que q Render Tree possui tambem objetos que não possuem nós na árvore DOM, como scripts e folhas de estilos.

O processo de criação da Render Tree passa pelos seguintes passos:

Attachment: Após finalizar o parse do DOM e a criação de seus nós, os navegadores chamam um método chamado attach para começar a renderização. O attach adiciona primeiramente as folhas de estilo a árvore DOM e começa a estilização da página. Um bom exemplo é o uso das propriedades CSS display x visibility: Caso um elemento da árvore DOM tenha uma propriedade display:none, este elemento (e seus nós filhos) não será criado na Render Tree. Ao contrário do uso de visibility:hidden, que vai renderizar o elemento na árvore, porém ele irá remover (ou adicionar quando visibility:visible) via Repaint as cores (ou propriedades) que formam este elemento. Vale lembrar também que este processo de attach é top down, criando sempre inicialmente os nós parent e depois seus descendentes (nós filhos). (Para saber mais sobre Repaint e Reflows, veja este outro artigo)
RenderStyle.h: Durante o processo de attach um método é criado, o RenderStyle.h que vai guardar objetos de referência com cada uma das propriedades CSS do documento. O nó criado no DOM é verificado no documento de CSS e caso existam propriedades que incidam naquele elemento, ela é aplicada. Esta propriedade fica salva dentro da Render Tree até que ela seja destruída ou que este valor seja alterado por algum script.
CSS Box Model: Após o método RenderStyle ser criado, ele é acessado via RenderObject. O Box model é usado para posicionar um elemento dentro da página, oferecendo suporte para o conteúdo, padding, bordas e margens que envolvem este elemento

Destruindo (ou atualizando) a Render Tree

A Render Tree é destruída quando nós da árvore DOM são removidos, causando a necessidade de um novo parse no DOM, ou quando uma tab do navegador com a árvore DOM usada é fechada. Após o refresh da árvore DOM, todo o processo acima é refeito, com attach chamando o RenderStyle, que montado chama o método style() do RenderObject que acessa o CSS BOX model.

Como os navegadores interpretam todos estes elementos criados por DOM e Render Tree antes de aplicar o estilo?

Todo navegador tem uma lista de elementos HTML suportados. Quando o seu markup possui tags presentes na lista, a árvore DOM é montada e o processo de attachment começa logo na sequência e os estilos são aplicados, dando continuidade a criação da Render tree.

O grande problema é que cada navegador tem a sua própria lista, que trata situações similares de maneiras diferentes. Obviamente já sabemos que o navegador que mais apresenta problemas para as situações acima é o Internet Explorer, mas acredite, todos os navegadores apresentam problemas quando um elemento não está em sua lista de elementos permitidos, e precisa de um trabalho para fazer tudo acontecer na Render Tree como deve ser feito.

Elementos fora desta lista são tratados como Elementos desconhecidos. E eles são uma grande fonte de problemas:

Como estilizar este elemento?Por exemplo, a tag
tem por padrão espacamento no topo e bottom,
possui uma indentação automática adicionando uma margem à esquerda ou
tem uma fonte maior que o
por ser um cabeçalho. Tudo isso esta padronizado, mas como cuidar de algo que não existe?
Como este elemento deve aparecer na árvore DOM?Os navegadores também possuem uma lista que mostra quais elementos podem ser filhos de outros elementos. Por exemplo, se você adiciona por engano no seu markup
o segundo paragrafo implicitamente fechará o primeiro
, fazendo que os dois elementos sejam irmãos (no mesmo nível na árvore DOM) e nao como nós filhos como de maneira linear pode parecer. Porém se vc adiciona um
, este paragrafo inicial não será fechado, porque o navegador permite que seja filho de elementos de paragrafo, fazendo assim o ser nó filho de

Para elementos desconhecidos, a ideia é não estilizar. Caso queira algum estilo em elementos desconhecidos, você deve colocá-lo no nó acima (se necessário um wrapper), para fazer com que ele herde o estilo.

Perceba a sutileza de como isso funciona. Os dois diagramas mostram uma árvore DOM, montada por um navegador suporte HTML5 nativo e o Internet Explorer 8 (navegadores que não suportam HTML5 tem funcionamento semelhante):

Arvore DOM com suporte HTML5

Arvore DOM IE e outros navegadores sem suporte HTML5

É por essas e outras que a gente usa o modernizr, o HTML5shiv ou um simples document.create(“SECTION”) / document.create(“ARTICLE”). E é isso que acontece quando navegadores interpretam elementos desconhecidos. Eles desconsideram o nó real aonde o elemento está, e o reconhece como filho de . E por favor, sem trocadilhos com o filho dos outros.

Ver como uma árvore DOM é montada e como a Render tree é feita nos dá idéia do quão importante é ter um documento semântico. Realmente semântico. Uma vez entendidos os conceitos, a manipulação e a programação dos elementos fica mais fácil.

E você começa a entender como os navegadores funcionam.

Referências

Entendendo os Reflows por Alysson Franklin

Modernizr para suporte HTML5

HTML5shiv para suporte HTML5

Browser Wars pela Wikipedia

ECMAScript pela Wikipedia

Javascript pela Wikipedia

JScript pela Wikipedia

CSS Box model pelo W3C

DOM pela wikipedia

Renderização no webkit, o básico pela webkit

W3C Overview do DOM

Declaração de atividades do DOM pelo W3C

Uma discussão sobre como Navegadores entendem elementos desconhecidos por Mark Pilgrim

Traversing the DOM by Mike West

Progressive enhancement demystified by Aaron Gustafson

DOM, HTML5, CSS3 e Performance – Slides por Paul Irish

E também o @mariocaixa, esse cara tem o DOM!

Posts Relacionados

Entendendo os Reflows

Alysson Franklin — Mon, 18 Jul 2011 13:00:02 +0000

Reflow é um assunto extenso e necessário. Ele sempre vai existir nos navegadores, então temos que entendê-lo para saber como utilizá-lo de maneira racional. O mais legal é entender todo o contexto sobre o que são e como funcionam, para a partir daí repensar o código que renderizamos no navegador para obtermos maior performance.

Reflow é o resultado de um evento que desencadeia mudanças no jeito que a pagina deve ser renderizada, tomando tempo para cálculo e reposicionamento de elementos.

Para explicar como isso acontece, o importante é entender como um navegador renderiza uma página web.

DOM

Document Object Model (DOM) é uma interface independente de linguagem e plataforma para representar e interagir com objetos em HTML, XHTML e XML. Mas o DOM é mais que isso; toda linguagem estruturada tem uma arvore DOM.

Exemplo de arvore DOM para documento HTML

Mas sobre o DOM podemos dizer que programas ou scripts podem dinamicamente acessar elementos na árvore DOM e alterar seu conteúdo, estrutura e estilo. Adicional ao estado inicial da pagina, estas alterações são agregadas a árvore DOM. O resultado é a renderização - o que nós vemos em um navegador. Mas a nossa Render Tree tem mais que isso:

Render Tree e como realmente entender display X visibility

Como a render tree é montada

O DOM é resultado do parse do markup HTML que você montou dentro de um navegador. Só que dentro de um HTML você não tem apenas a estrutura do documento, estilos em CSS e funcionalidades em javascript também estarão no seu markup. E a Render tree é a soma de DOM mais estilos, que depois podem ser manipulados (seus scripts).

Pode parecer estranho, mas para mim a melhor maneira de entender as diferencas entre DOM e Render Tree é encarar esta última como um individuo narcisista. Isso mesmo: A Render Tree gosta de aparecer, é o que vemos no browser. O DOM acontece por trás das cortinas. À Render tree, o palco. (Para saber mais sobre o DOM, veja este outro artigo)

Uma página que tem controles de show/hide mostra isso muito bem. Enquanto todo o conteúdo da página está presente na árvore DOM, apenas alguns itens estarão disponíveis na Render Tree – os visíveis na página (display:block). Alterar os elementos display:none vão disparar mudanças na render tree, e não na árvore DOM.

Já tentou entender as diferenças entre display:none e visibility:hidden? A maioria das explicações que vemos é que um “deixa de mostrar o elemento totalmente, incluindo seu espaço em tela” e o outro “deixa de mostrar o elemento visual, mas sua área de exibição continua sendo utilizada”. Esta explicação não está incorreta, mas seria melhor dizer que a propriedade display altera a estrutura da render tree, adicionando algo que antes não estava ali, enquanto visibility não faz alterações, apenas o câmbio de mostrar ou não um elemento que já esta na render tree.

Repaint

Entendido as diferenças entre display e visibility, além do contexto de área do elemento, conseguimos explicar o Repaint. Uma ação que faça alteração de propriedades de background sem alterar dimensões ou outras propriedades do elemento não causam o reflow, apenas o repaint, que seria a atualização da propriedade de cor ou da imagem – literalmente pintar novamente o elemento. Repaints gastam menos CPU que reflows.

Como um navegador monta seu documento HTML

Esses vídeos são sensacionais. Eles explicam o que são os reflows e dai como minimizá-los durante a fase de desenvolvimento do documento (sempre usando Progressive Enhancement quando possível) é mais fácil..

Esta é uma representação de como a página da Mozilla é montada. Quer mais? Veja também como a Wikipedia e a página do Google no Japão são renderizadas.

Analisando o primeiro vídeo, perceba que ao finalizar a montagem do rodapé, “algo mais” acontece (a partir de 12seg). São os Reflows. A maioria dos elementos são recalculados e reposicionados. Se ponderarmos que o rodapé acaba de ser montado aos 14 segundos e a renderização termina aos 26 segundos da pagina, estamos falando quase de 50% do tempo de renderização sendo gasto com Reflows, o que é muito, dependendo do que a sua página deve fazer.

O que causam exatamente os reflows?

1
2
3
4
5
6
7
8
var bstyle = document.body.style; // cache
bstyle.padding = "20px"; // reflow, repaint
bstyle.border = "10px solid red"; // outro reflow e repaint
bstyle.color = "blue"; // repaint
bstyle.backgroundColor = "#fad"; // repaint
bstyle.fontSize = "2em"; // reflow, repaint
// novo elemento DOM - reflow, repaint
document.body.appendChild(document.createTextNode('Leeento'));

Reflows são excessivamente pesados e para reduzir efeitos uma das táticas que navegadores usam é processar nossos scripts em lote. Uma fila é criada para todos os comandos que causam reflow sejam processados de uma única vez. Porém o foco é entender o que causa um reflow e tentar minimizar o seu uso para ganhar performance na aplicação.

Este assunto é novo, e com certeza, A lista que mostro abaixo deve crescer. É importante mantermos a atenção a este assunto porque pequenos cuidados podem significar muito. Em um site web visualizado em desktops a diferença é óbvia sobre o tempo de renderização. Mas isso implica em outras coisas, que podem fazer a diferença não apenas em montar uma página mais rápido, mas também para menor gasto de processamento, o que garante também mais tempo de bateria em mobiles e tablets por exemplo.

Adicionar, remover ou atualizar o DOM;
Esconder nós do DOM usando display:none;
Mover e animar o DOM na página;
Adicionar folhas de estilo on-the-fly que mudem o comportamento dos elementos;
Redimensionar janelas;
Alterar tamanho de fontes;
Scroll de página;

Em um dos posts sobre o assunto, Tony G mapeou pesquisas prévias e montou a seguinte tabela, que também está sendo constantemente atualizada.

Element

Frame, Image

Range

SVGLocatable

SVGTextContent

SVGUse

window

clientHeight,
clientLeft,
clientTop,
clientWidth,
focus(), getBoundingClientRect(), getClientRects(), innerText,
offsetHeight,
offsetLeft,
offsetParent,
offsetTop,
offsetWidth,
outerText,
scrollByLines(), scrollByPages(), scrollHeight, scrollIntoView(), scrollIntoViewIfNeeded(), scrollLeft,
scrollTop,
scrollWidth

height, width

getBoundingClientRect(), getClientRects()

computeCTM(), getBBox()

getCharNumAtPosition(), getComputedTextLength(), getEndPositionOfChar(), getExtentOfChar(), getNumberOfChars(), getRotationOfChar(), getStartPositionOfChar(), getSubStringLength(), selectSubString()

instanceRoot

getComputedStyle(),
scrollBy(),
scrollTo(),
scrollX,
scrollY, webkitConvertPointFromNodeToPage(), webkitConvertPointFromPageToNode()

Como melhorar o meu código para minimizar os reflows?

É simples. Basta minimizar o uso de requisições de estilo, que façam o navegador executar reflows ou repaints.

Planejar a sua aplicação e entender como plugins e scripts criados vão se comportar em relação a reflow e repaints. Arquitetar o uso de plugins de acordo com a personalização que deve ser feita. Minimize o uso de alteração de estilos on-the-fly.
Quando precisar alterar a propriedade de um estilo, troque o nome da classe, planeje a existência deste estado e adicione-o ao CSS previamente. Se o valor desta nova classe for dinâmica, use cssText. Evite alterar a propriedade diretamente para qualquer mudança.
Pense como suas mudanças afetam a render tree e o quanto precisará ser revalidado depois desta mudanca. Se você usa position:absolute em um elemento, ele deixa de pertencer ao nó que está, e passa a ser filho do BODY. Alterá-lo então, não será tão custoso em termos de performance. Mesmo que alterações neste nó sobreponha outras areas, o reflow acontecerá apenas neste nó, e não em toda a render tree.
Limpe seu CSS. Classes não utilizadas devem ser removidas.
Reduza o número de mudanças no DOM. Ele vai causar mudanças estruturais em todas as outras etapas. E mais tempo de reflow.
Animações na página, transições? Pondere sobre posicioná-la de maneira absoluta e trabalhar com ela a partir do BODY.
Vá com calma nos seletores CSS – os descendentes em particular – pois usam maior poder de CPU para executar a tarefa (CPU = Bateria).

Referências

DOM pela wikipedia
Gecko Reflow
DOM, HTML5, CSS3 e Performance – Slides por Paul Irish
Reflow pelo Mozilla Labs
Reflow e Repaint na Ajaxian
Reflow pelo Google Code
W3C Overview do DOM
1 dia de javascript com Alex Russel: Como Navegadores Veem as suas Apps
Como (não) criar um layout no webkit por Tony G
Usando a timeline panel em navegadores webkit
The book of Speed
Reflow/Repaint por Stoyan Stefanov
Inconsistências dos navegadores em Reflows por Stoyan Stefanov
BrowserScope tests para reflows
Browsers para Web Developers David Baron da Mozilla labs
Renderização no webkit, o básico

Tableless » Javascript

jQuery: métodos desconhecidos

proxy()

isArray() e isFunction()

queue() e dequeue()

detach()

ajaxSetup() e afins

delay()

replaceWith() e replaceAll()

1 milhão de pontos!

Carregamento completo!

Posts Relacionados

Aprenda a programar Javascript no Codecademy

Mais comentados

Introdução aos padrões de codificação

Identação

Espaços em brancos (Whitespaces)

Nomenclatura

Comentários

Arquivos

Chaves e ponto/vírgula

Posts Relacionados

Formulários e o Metawebdesign – Parte 1

Aplicando o Metawebdesign a formulários: o design da interface

Bons e maus exemplos:

Form Design – O básico:

Escolhendo elementos de controle

Elementos de controle de Formulários

Causa

Tipo de interação

Elementos aceitáveis

Prós

Contras

Padrões para Elementos de Controle

Referências

Posts Relacionados

Utilizando a Biblioteca Modernizr

Problemas de compatibilidade

O que é a Modernizr

Como funciona

Exemplos de utilidade

Posts Relacionados

Testando seu código jQuery com Jasmine – Parte 2

Fixtures

Testando código assíncrono

Espionando métodos

Matchers personalizados

Outros projetos utilizando Jasmine

Referências

Posts Relacionados

Testando seu código jQuery com Jasmine – Parte 1

Baby steps

Red → Green → Refactor

Configurando o jasmine-jquery

Nosso primeiro teste

Escrevendo os testes

A função saudacao()

Melhorando nosso código

Referências

Posts Relacionados

Alternativas ao jQuery

MooTools + mocha(ui)

ExtJS 4

Prototype + Script.aculo.us

YUI 3

Dojo Toolkit

John Resig sobre as bibliotecas JavaScript

Posts Relacionados

Tenha o DOM

Um pouco de história

O DOM em sua forma e como é reconhecido pelos navegadores

A Render Tree

Destruindo (ou atualizando) a Render Tree

Como os navegadores interpretam todos estes elementos criados por DOM e Render Tree antes de aplicar o estilo?

tem uma fonte maior que o por ser um cabeçalho. Tudo isso esta padronizado, mas como cuidar de algo que não existe?

Referências

Posts Relacionados

Entendendo os Reflows

DOM

Render Tree e como realmente entender display X visibility

tem uma fonte maior que o
por ser um cabeçalho. Tudo isso esta padronizado, mas como cuidar de algo que não existe?