Padrões de código & melhores práticas em Front-end

Visão geral

Este documento contêm diretrizes para aplicações web construídas pela Creative Technology (engenharia front-end) práticas da Isobar US e está prontamente disponível para qualquer um que deseja acompanhar o progresso iterativo de nossas melhores práticas. Caso tenha algum feedback favor deixar um comentário no post de apresentação do nosso blog.

As principais motivações deste documento são: 1) consistência de código 2) melhores práticas. Por manter consistência nos estilos e convenções do código, nós podemos diminuir o fardo de manter código legado e mitigar o risco de problemas futuros. Ao aderir às melhores práticas, nós asseguramos o carregamento otimizado, performance e código de fácil manutenção.

{}

Diretrizes gerais

Pilares do desenvolvimento Front-end

  1. Separação de apresentação, conteúdo e comportamento..
  2. Marcação bem formada, semanticamente correta e geralmente válida.
  3. Javascript deve melhorar progressivamente a experiência do usuário.

Práticas Gerais

Identação

Para todas as linguagens, nós obrigamos o uso da identação por soft tabs (usando caracteres de espaço). Apertando Tab no seu editor de texto deve ser equivalente a quatro espaços.

Legibilidade vs Compactação

Nós preferimos a legibilidade ao invés de economizar no tamanho do arquivo. A abundância de espaçamento é encorajada, bem como arte em ASCII, quando for apropriado. Não há necessidade nenhuma do desenvolvedor comprimir o HTML ou CSS, ou obfuscar o JavaScript. Nós utilizaremos processos no lado do servidor para automaticamente minificar e comprimir todos os arquivos do lado do cliente.

{}

Marcação

O primeiro componente de qualquer página web é a linguagem de marcação HTML. A Linguagem de Marcação de Hiper Texto (do inglês HTML) tem uma história sórdida, mas iniciou uma nova nos últimos anos. Após uma longa experimentação de uma variante baseada em XML (XHTML), a indústria aceitou que HTML é o futuro da web.

A marcação define a estrutura e os elementos do documento, oferecendo um conteúdo estruturado. A marcação não tem intenção de definir o visual do conteúdo da página, além dos conceitos rudimentares, como cabeçalhos, parágrafos e listas. Os atributos de apresentação do HTML foram dados obsoletos e o estilo deve estar contido nas folhas de estilo.

HTML5

HTML5 é uma nova versão do HTML e do XHTML. O rascunho das especificações do HTML5 definem uma única linguagem que pode ser escrita em HTML e XML. Esta procura resolver problemas encontrados em iterações anteriores do HTML, que endereçam as necessidades de uma aplicação web, uma área previamente não coberta pelo HTML.

Nós utilizaremos o doctype do HTML5 bem como seus recursos quando apropriado.

Nós testaremos nossa marcação com a ferramenta de validação da W3C, para assegurar sua boa formação. Código 100% válido não é fundamental, mas a validação certamente ajuda na manutenção do código, bem como na sua depuração. Isobar não garante código 100% válido, em contrapartida investe numa experiêcia entre navegadores mais consistente.

Modelo

Para documentos HTML5 nós utilizamos o modelo H5BP modificado para as necessidades do projeto. Repósitorio no GitHub.

Doctype

Um doctype apropriado que ativa o modo de renderização padrão do seu navegador sempre deve ser usado.

Um ótimo aspecto do HTML5 é que ele dinamiza a quantidade de de código necessário. Atributos incoerentes foram deixados e a declaração de doctype foi simplicada. Além disso, não há necessidade do uso de CDATA para interpolar JavaScript, antes um requisito do XHTML.

HTML5 Doctype

Codificação de caracteres

Todo marcação deve ser codificada em UTF-8, por ser o mais amigável para internacionalização, e isto, deve estar tanto no cabeçalho da página quanto no cabeçalho de resposta da requisição HTTP.

Ajustando a codificação de caracteres usando o elemento <meta>.

Em HTML5, apenas use:

Diretrizes Gerais de Marcação

Abaixo estão as regras gerais de estruturação do HTML. Profissionais devem ser lembrados de usar marcação semântica, que representa o significado do conteúdo a ser criado.

  • Use o elemento <p> para parágrafos ao invés de duplo <br>.
  • Faça o uso de <dl> (lista de definição) e <blockquote>, quando apropriado.
  • Listas devem ser sempre representadas por uma <ul>, <ol>, ou <dl>, nunca um conjunto de <div> ou <p>.
  • Use a tag <label> para rotular cada campo de um formulário, o atributo for deve associar o rótulo ao campo, para que os usuários possam clicar no rótulo e assim dar foco no campo associado. cursor:pointer; no rótulo é desejável. nota 1 nota 2
  • Não use o atributo size nos seus campos. O atributo size é relativo ao tamanho da fonte do campo de texto. Ao invés disso, use a propriedade width do CSS.
  • Escreva comentários no fechamento de <div> indicando qual é o elemento que está sendo fechado (id ou class). Isso ajudará quando existir muitos elementos aninhados e muita identação.
  • Tabelas não devem ser utilizadas para layouts de página.
  • Use microformats e ou Microdata quando for apropriado, especialmente hCard e adr.
  • Faça o uso dos elementos <thead>, <tbody> e <th> (e o atributo scope) quando apropriado.
    Marcação de tabela com a sintaxe adequada (<thead>, <tbody>, <th>, scope).
  • Utilize iniciais maiúsculas para cabeçalhos e títulos. Nunca use apenas caixa alta ou baixa na marcação de títulos, utilize a propriedade CSS text-transform:uppercase/lowercase para isso.

Notação de atributos

Apesar da especificação do HTML5 definir aspas em volta de atributos como opcional, para manter a consistência, todos os atributos devem utilizar aspas.

{}

CSS

O segundo componente de uma página web é a informação de apresentação contida na Folha de Estilo em Cascata (do inglês CSS). A implementação bem sucedida de CSS nos navegadores deu um controle abrangente sobre o aspecto visual de seus sites a uma geração inteira de profissionais web.

Assim como a informação da página é semânticamente descrita pela marcação HTML, o CSS define todos os aspectos de apresentação atráves da descrição de suas propriedades visuais. CSS é poderoso, pois suas propriedades são misturadas e combinadas por identificadores que controlam o layout e as características visuais da página, formando camadas de regras de estilo (a "cascata").

Principios Gerais de Codificação

  • Carregue seu CSS através de arquivos externos, utilizando o menor número de arquivos possível, e sempre de dentro do elemento <head> da página.
  • Use o elemento <link>, nunca @import.
  • Incluindo a folha de estilo
    Nunca utilize estilo em linha (inline)
  • Não inclua estilos em linha (inline) no documento, nem elementos <style>. Fica mais difícil rastrear as regras.
  • Use um CSS reset (como o presente no H5BP ou o Eric Meyers reset) para equalizar as diferenças entre os navegadores.
  • Use um arquivo de normalização de fonte como o YUI fonts.css.
  • Elementos que ocorrem uma única vez dentro de um documento devem utilizar ID, os demais devem utilizam classes.
  • Entenda cascata e especificidade de seletores para que você possa escrever um código mais conciso e efetivo.
  • Escreva seletores que são otimizados para performance. Onde possível, evite seletores caros, como por exemplo o seletor curinga - *. Evite também qualificar seletores de ID - div#myid, ou seletores de classe table.results. Isso é especialmente importante em aplicações web onde performance é soberana e pode haver milhares ou até mesmo dezenas de milhares de elementos DOM. Leia mais em escrevendo CSS eficiente no MDC.

Modelo CSS das caixas

Conhecimento íntimo, compreensão do CSS e ter uma boa base no modelo de caixa do navegador, são necessários para conquistar os fundamentos sobre os layouts CSS.

CSS Box Model
Modelo CSS de caixa em 3D diagrama por Jon Hicks.

CSS Validação

Geralmente não utilizamos o validador da W3C.

Formatação do CSS

Mantenha a formatação dos seletores CSS em uma mesma linha e cada propriedade em sua própria linha. As declarações devem ser identadas.

Insira um reforço com 2 ou 4 espaços para estilos relacionados ou filhos. Isso permite uma organização visual hierárquica e torna mais fácil (para algumas pessoas) a leitura da folha de estilos.

No caso de um ambiente com vários desenvolvedores, CSS em uma única linha deve ser evitado por causar problemas com o controle de versão do arquivo.

Alfabetizar

Se você for um obcecado por performance, alfabetize as propriedades do CSS, assim você aumenta as chances de maiores padrões repetitivos estarem presentes para auxiliar na compressão GZIP.

Classes vs. IDs

Você só deve dar atributos ID para um elemento se ele for único. Eles devem ser aplicados apenas para este elemento e mais nenhum outro. Classes podem ser aplicadas em múltiplos elementos quando estes compartilham as mesmas propriedades de estilo. Elementos que devem parecer e funcionar da mesma forma podem ter o mesmo nome de classe.

Convenção de nomenclatura para seletores

Prefira sempre dar nome a algo pela natureza do que é, ao invés do que ele parece, seja ele um ID ou uma classe. Por exemplo, um nome de classe bigBlueText para uma nota especial em uma página é algo totalmente sem sentido se tiver sido alterado para ter um texto menor com a cor vermelha. Usando uma convenção mais inteligente como noteText é bem melhor, porque quando ocorrerem mudanças visuais, o nome continuará a fazer sentido.

Seletores

Os Seletores CSS Nível 3 apresentam um novo conjunto de seletores CSS que são extremamente úteis para atingir um determinado elemento.

Pseudo-classes

Pseudo-classes possibilitam que você estilize dinamicamente um conteúdo. Algumas pseudo-classes existem desde o CSS1 (:visited, :hover, etc.) e no CSS2 (:first-child, :lang). No CSS3, 16 novas pseudo-classes foram adicionadas a lista e são especialmente úteis para estilar dinamicamente um conteúdo.

Combinadores & Atributos Seletores

Combinadores fornecem atalhos para a seleção de elementos que são descendentes, filhos, ou irmãos.

Atributos Seletores são ótimos para localizar elementos que possuam um atributo específico e/ou um valor específico. Conhecimento de expressões regulares ajudam com os atributos seletores.

Especificidade

Navegadores calculam a especificidade para determinar quais regras do CSS devem ser aplicadas. Se dois seletores aplicam uma regra para o mesmo elemento, o que tiver com maior especificidade vence.

IDs tem uma especificidade maior do que os de seletores de atributo, e seletores de classe têm maior especificidade do que qualquer número de elementos de seleção. Sempre tente usar IDs para aumentar a especificidade, há momentos em que podemos tentar aplicar uma regra CSS a um elemento e ela não funciona, não importa o que tentamos. Isso acontece provavelmente porque a especificidade do seletor usado é inferior ao outro e as propriedades do mais alto estão tomando precedência sobre aqueles que você deseja aplicar. Isto é mais comum quando se trabalha com uma folha de estilos maior e complexa, e geralmente não é um grande problema quando se trata de projetos menores.

Calculando especificidade

Ao trabalhar com uma larga e complexa folha de estilos, sempre é útil saber como calcular o valor de especificidade de um seletor para salvar o seu tempo e tornar os seus seletores mais eficientes.

Especificidade é calculada contando vários componentes do seu CSS e são expressos nesta forma (a,b,c,d):

  • Elemento, Pseudo Elemento: d = 1 – (0,0,0,1)
  • Classe, Pseudo-classe, Attributo: c = 1 – (0,0,1,0)
  • ID: b = 1 – (0,1,0,0)
  • Estilo em linha (inline): a = 1 – (1,0,0,0)

No entanto, pode ser melhor usar uma calculadora de especificidade:

Usando !important você substitui todas as especificidades, não importa o quão alto for. Nós evitamos usá-lo por este motivo. Na maioria das vezes não é necessário, mesmo se você precisar substituir um seletor em uma folha de estilo que não tem acesso. Normalmente existem outras formas de substituir um seletor sem usar !important. Se possível, evite-o.

Pixels vs. Ems

Nós usamos px como unidade de medida para definir o font-size, porque oferece o controle absoluto sobre o texto. Nós percebemos que a unidade de medida em se tornou popular para acomodar o Internet Explorer 6, já que não redimensiona pixel com base em texto. No entanto, agora todos os principais navegadores (incluindo IE7 e IE8) suportam texto redimensionado com unidade baseada em pixel e/ou zoom na página inteira. Desde que o IE6 foi considerado obsoleto, é preferível usar tamanho em pixels. A unidade line-height também deve ser usada, porque não herda um valor percentual do seu elemento pai, mas é baseado no multiplicador do font-size.

Correto
Incorreto

Internet Explorer Bugs

Inevitavelmente, quando todos os outros navegadores parecem funcionar corretamente, qualquer versão do Internet Explorer irá apresentar algum bug absurdo, retardando o tempo de desenvolvimento. Enquanto nós encorajamos a solução de problemas e a construção de um código que irá funcionar em todos navegadores sem modificações especiais, às vezes é necessário usar comentários condicionais if IE como ganchos em nossas folhas de estilos. Leia mais em paulirish.com

Corrigindo o IE

Se você estiver usando HTML5 (e o HTML5 Boilerplate) nós encorajamos o uso da biblioteca JavaScript Modernizer e este padrão:

Abreviação

Em geral, é preferível a abreviação do CSS por causa da sua concisão e possibilidade de mais tarde voltar e adicionar em valores que já estão presentes, como é o caso do margin e padding. Desenvolvedores devem estar cientes do acrónimo TRBL, denotando a ordem em que os lados de um elemento são definidas, em sentido horário: topo, para direita, abaixo e para a esquerda. Se bottom não estiver definido, ele herda o valor do top. Da mesma maneira, se left não for definido, ele herdará o valor do right. Se apenas o valor de top for definido, todos os outros lados herdam o mesmo valor declarado.

Para mais informações sobre como reduzir a redundância de código na folha de estilo, e como usar abreviação em geral:

Imagens

  • Para repetir imagens, use algo maior do que 1x1 pixels.
  • Você nunca deve usar imagens para criar espaços em branco.
  • Use CSS Sprites generosamente. Eles tornam o efeito hover mais fácil, melhoram o tempo carregamento da página e reduzem as emissões de dióxido de carbono.
  • Normalmente, todas as imagens devem ser cortadas em um fundo transparente (PNG8). Elas devem ser cortadas bem nos limites da imagem.
    • No entanto, o logo sempre deve ter um background matte e padding antes do corte (para que outras pessoas possam criar um hotlink para o arquivo).

Estilos gerais de fonte e texto

Títulos

  • Definir um estilo padrão para títulos h1-h6, incluindo cabeçalhos com links. É útil declarar estes no topo do seu documento CSSS e modificá-los conforme for necessário para manter a consistência em todo o site.
  • Cabeçalhos devem ter uma hierarquia que indicam diferentes níveis de importância de cima para baixo, começando com h1 tendo o maior tamanho de fonte
  • SEO: Para se ter uma ideia aproximada de como a hierarquia da página está organizada e legível, use a barra de ferramentas de desenvolvedor (Developer Toolbar) do navegador para desabilitar o CSS. Você vai acabar vendo apenas o seu site com os textos de todas as suas tags h1-h6, strong, em etc.

Links

  • Estilos padrões para links devem ser declarados e ser diferentes do estilo de texto principal, e com diferentes estilos para o estado hover.
  • Quando estilamos links com sublinhados usamos border-bottom, algum padding e text-decoration: none;. Visualmente fica melhor.

Tipografia Web

O uso de fontes customizadas e caracteres tipográficos na web tem se tornado muito popular nos últimos anos. Com o suporte nativo do browser em ascensão, vários serviços de apoio e APIs disponíveis, agora existe real impulso neste cenário. Cada uma dessas abordagens abaixo tem suas vantagens e desvantagens. Antes de começar um projeto, é melhor fazer uma pesquisa para saber as limitações tecnológicas e de licenciamento ao escolher a abordagem apropriada para o seu projeto em específico.

Todas as opções abaixo tem incovenientes com sobrecarga de código, tempo de desenvolvimento e performance (cronometrada e perceptíveis). Familiarizar-se com estes problemas, comunicá-los aos outros membros de sua equipe e ao cliente, irá salvá-lo mais tarde de significantes problemas no projeto.

Abaixo alguns métodos populares de incorporar fontes customizadas, listadas em ordem de nossa preferência de implementação:

@font-face

A regra @font-face permite que você defina fontes customizadas. Ela foi primeiramente lançada nas especificações do CSS2, mas foi removida do CSS2.1. Atualmente, é um projeto de recomendação para o CSS3.

Nossa primeira e mais preferível escolha para customizar fontes na web é a @font-face, simplesmente porque ele é parte do projeto de trabalho CSS Módulo Fontes, o que significa que continuará a crescer em popularidade com a medida que cresce o suporte ao navegador, e irá melhorar a facilidade de uso, tornando se mais estável.

Para agora, quando usar @font-face, é recomendado declarar o código fonte para cada formato de fonte. Isso é importante se você precisa trabalhar com um número maior de navegadores, embora não seja obrigatório.

Os formatos de fonte incluem as especificações abaixo:

  • woff: WOFF (Fonte Web de Formato Aberto)
  • ttf: TrueType
  • ttf: TrueType
  • ttf, otf: OpenType
  • eot: incorporados OpenType
  • svg, svgz: Fonte SVG

@font-face à prova de bala

Para uma compatibilidade com todos os browsers use a nova sintaxe do Fontsprings', @font-face à prova de bala (última versão de 21/02/11).

Aqui uma demo funcional usando a última versão.

Compatibilidade Cross-Browser

Safari, IE 6-9, IE 9 Modo de Compatibilidade, Firefox, Chrome, iOS, Android, Opera.

Prevenindo o Modo de Compatibilidade

Alguns IE podem ter vontade própria e mudar para o modo de compatibilidade sem você saber. Incluir o seguinte código no cabeçalho do seu site <head> pode evitar que ele use o modo de compatibilidade como padrão:


Dicas para o @font-face

  • IE 6–8 apenas será aceito com uma fonte TrueType empacotada como uma EOT.
  • font-weight e font-style tem diferentes significados com o @font-face. Uma declaração como font-weight: bold; significa que esta é a versão em negrito da fonte, ao invés de aplicar o negrito a este texto.
  • Dicas para @font-face
Prós
  • Fácil de implementar
  • Larga variedade de APIs
  • Customizável
  • Fácil para adicionar aos elementos
  • Nada requerido além do próprio CSS
  • Atualmente faz parte do projeto de trabalho de Fontes da W3C - CSS Módulo 3
Contras
  • Suporte limitado aos navegadores, se usado indevidamente
  • Alguns versões antigas dos navegadores modernos (Chrome, Opera) nem sempre renderizam bem. Textos pode ter arestas. **Eu não fui capaz de confirmar se isto é ainda é um problema ou não.

Google WebFonts API & Webfont Loader

Há duas opções disponíveis no Google Webfonts. Ambas as opções têm suas desvantagens, claro, mas eles podem ser tão boas como o @font-face, e isso depende da necessidade do seu projeto.

Webfonts API

Google's Webfonts API essencialmente faz a mesma coisa que o @font-face, ele apenas faz todo o trabalho chato para você, provendo suporte mais amplo aos navegadores. A principal desvantagem deste método é a pequena biblioteca de fontes que ele possuí. Para fazê-los funcionar tudo que você precisa fazer é incluir a folha de estilo + o nome da fonte.

Em seguida, defina um estilo para o seletor que você precisa aplicar a fonte:

Webfont Loader

Outra opção que o Google oferece é o Webfont Loader, que é uma biblioteca JavaScript que permite maior controle do que a API Fonte faz. Você também pode usar vários provedores webfonts como Typekit. Para usá-la, inclua o seguinte script na sua página:

A maneira mais rápida se você não estiver usando a APIs Ajax é incluir o arquivo webfont.js. Caso ao contrário, você deve usar isto:

Com o uso do Webfont Loader você tem maior capacidade para customização, incluindo o uso de mais fontes, não apenas as encontradas na biblioteca Google Webfont, que não é muito vasta. Entretanto, exige que você carregue JavaScript, sacrificando uma coisa pela outra.

Prós
  • Muito fácil de se implementar
  • Alto suporte dos navegadores
  • Pode ser combinada com o Typekit
  • Customizável quando usada com o Font Loader
  • API faz a mesma coisa que o @font-face
Contras
  • Biblioteca pequena de fontes quando se usa a API Fonte
  • Usando o Webfont Loader é necessário o uso de JavaScript para que ele funcione
  • A maioria dos navegadores carregam primeiro o restante da página, deixando um espaço em branco onde o texto deveria aparecer, ou se houver, dão algum recurso alternativo só quando a página termina de carregar.
  • Algumas fontes da biblioteca webfonts renderizam pobremente no Windows

Cufon

Se você escolher usar o Cufon, é altamente recomendado que você utilize a versão comprimida. Você precisará converter sua fonte usando o gerador.

Nós recomendamos o uso do Cufon com moderação, pois pode causar problemas de desempenho se aplicado a uma grande quantidade de texto. Para maiores informações visite o Wiki do Cufon.

Prós
  • Largo suporte dos navegadores
  • Renderiza bem nos navegadores suportados
  • Customizável
  • Fácil de implementar
Contras
  • Requer o uso de JavaScript para funcionar
  • O texto não pode ser selecionado quando o usamos
  • Nem todos caracteres podem ser usados
  • A customização pode ser dolorosa
  • Nem sempre é fácil de se aplicar a múltiplos elementos, especialmente quando adicionamos efeitos como hovers

Typekit

Usar o Typekit tem suas vantagens e não deve ser totalmente descartado quando for escolher o método a utilizar para adição de fontes personalizadas a um site. É uma forte plataforma integrada, escalável e popular. Ela pode ser usada com o Google Webfonts e é fácil adicionar ao Wordpress, Posterous, Typepad, e outros CMS similares.

No entanto, o uso completo do Typekit não vem sem um custo. Se você precisa usá-lo em um ou mais 2 sites, ou o site tem um alto volume de pageviews, você terá que pagar um valor anual de $49.99, e se seu site tiver mais de um milhão de pageviews, o custo será o dobro. Porém, você provavelmente tem a grana para cobrir o custo se você tiver mais de um milhão de pageviews. Senão, você precisará repensar seu modelo de negócio.

Prós
  • Vasta biblioteca de fontes, incluindo fontes Adobe
  • Fácil implementação
  • Google Webfont API e integração com plataforma de blogs
  • Plano gratuito tem um limite, mas não expira
Contras
  • Requer JavaScript para funcionar
  • Limitado acesso a biblioteca de fontes não pagas
  • Planos gratuitos e baratos só permitem usar 1-2 sites e 2-5 fontes por site
  • Você tem que pagar para usá-los em mais de 1 site

Scalable Inman Flash Replacement (sIFR)

Nós não recomendamos que você utilize este método. Como já foi amplamente usado, se sentiu que ele não é mais necessário como opção nas escolhas de quais métodos usar para implementar fontes personalizadas.

Apesar de ser popular entre Web Designers, e ter um bom suporte na maioria dos navegadores, as desvantagens dele não compensam o uso. A grande e mais óbvia razão de se não usar sIFR é porque ela utiliza Flash. E mais, para o Flash funcionar corretamente ele necessita de JavaScript, os scripts devem ser carregados antes do texto que você usou e isto fica visível na página. Sem contar que ele aumenta o tempo de carregamento da página e pode deixar um site lento ainda mais lento.

Nós vamos deixar você fazer a matemática aqui:

Prós
  • Texto pode ser selecionado
  • Suporte na maioria dos navegadores
  • A renderização funciona razoavelmente nos navegadores suportados
Contras
  • Ele usa Flash
  • Requer JavaScript para que o Flash funcione
  • É em Flash!
  • Texto não aparece até que se carregue os scripts
  • ...e é Flash...

Licenciamento de Fontes

Mesmo que você possa praticamente transformar qualquer fonte em um arquivo fonte web, você deve se certificar de que está legalmente de acordo para fazê-lo. Muitas fundições tem atualizado suas condições para especificar como suas fontes podem ser usadas na web. Veja Licenciamento de Fonte e detalhes relativos a sua proteção, para mais informações.


Especificações & Formato de arquivos de Fontes

Usando CSS3

Você pode fazer um monte de coisas com as novas características adicionadas na especificação do CSS3, muitas das quais ainda não são totalmente suportadas por todos os principais navegadores. Isto não quer dizer que você não pode usá-las hoje. Para as coisas que ainda não há suporte, existem bibliotecas fallback ou outros 'polyfills' para preencher os buracos onde os navegadores não suportam o novo recurso.

Existem também algumas propriedades específicas do navegador ou prefixos, que devem ser usados para estilar elementos também. Nós recomendamos usar o Prefixr.com para ter certeza que você incluiu todos os diferentes prefixos e propriedades para suporte em todos os navegadores.

{}

JavaScript

JavaScript é o terceiro componente principal de uma página web. Código JavaScript quando devidamente aplicado, melhora consideravelmente a experiência do usuário, através do controle de eventos e da camada de comportamento geral.

JavaScript tem visto uma explosão em sua popularidade nos últimos anos. Ganhou poderosas implementações no navegador que agora possibilitam a criação de aplicações web completas. O uso cuidadoso de JavaScript permite a manipulação e controle total sobre outros dois componentes de criação de páginas web, o HTML e CSS. Hoje, a estrutura das páginas e o visual podem ser manipulados em tempo real, sem que seja necessário atualizar a página completamente.

Bibliotecas JavaScript

Nós essencialmente desenvolvemos as novas aplicações usando jQuery, embora tenhamos conhecimento em puro JavaScript, assim como todas as grandes bibliotecas modernas em JavaScript.

Princípios Gerais de Código

  • 99% do código deve ficar em arquivos externos. Eles devem ser incluídos no FIM da tag body para melhor performance.
  • Não confie na string user-agent. Faça a detecção usando o recurso adequado. (Mais em Dive Into HTML5: Detecção & jQuery.support docs)
  • Não utilize document.write().
  • Todas as variáveis boleanas devem começar com "is".
    Teste para condições positivas
  • Nomeie variáveis e funções de forma lógica. Por exemplo: popUpWindowForAd, ao invés myWindow.
  • Não faça reduções ao nomear variáveis. Com exceção dos tradicionais i etc. Para loops for, variáveis devem ter nomes longos o suficiente para ter significado.
  • A documentação deve seguir a estrutura do NaturalDocs.
  • Constantes ou variáveis de configuração (como duração de animações etc.) devem ficam no começo do arquivo.
  • Esforce-se para criar funções que possam ser generalizadas, ter parâmetros e valores de retorno. Isto permite a reutilização substancial do código e, quando combinada com includes ou scripts externos, podem reduzir a sobrecarga quando os scripts tem necessidade de mudar. Por exemplo, em vez da difícil codificação de uma janela pop-up com tamanho de janela, opções, urls, considere apenas criar uma função que tenha tamanho, url e opções como variáveis.
  • Comente o seu código! Isso ajuda a reduzir o tempo gasto com soluções de problemas em funções JavaScript.
  • Não perca seu tempo com <!-- -->, comentários que cercam sua linha javascript, a menos que você se preocupe com o Netscape 4. :)
  • Organize seu código com o Object Literal/Singleton, com o Module Pattern, ou com o Object with constructors.
  • Reduza variáveis globais - quanto menos você as criar, melhor. Geralmente uma para o espaço de sua aplicação é um bom número.
    Ao especificar qualquer variável global, identifique-a de forma clara.

Espaços em branco

Em geral, o uso de espaços em branco devem seguir convenções de leitura inglesa de longa data. Tal que, haverá um espaço após cada vírgula e depois dois-pontos (e ponto e vírgula, se for o caso), mas sem espaços dentre os lados direito e o esquerdo do parênteses. Resumindo, nós defendemos a leitura dentro da razão. Adicionalmente, chaves devem sempre aparecer na mesma linha como seu argumento precedente.

Considere os seguintes exemplos for-loop de JavaScript...

Correto
Errado
Errado também

plugins.js e script.js

Começando com o H5BP que é nos apresentado com dois arquivos, plugins.js e script.js. Essa seção descreve o uso básico destes dois arquivos:

plugins.js

O plugin.js serve para conter todos os códigos de plugins utilizados no seu site. Em vez de linkar para diferentes arquivos, nós podemos melhorar o desempenho incluindo todo o código em apenas um arquivo. Embora exista exceções para este uso, um plug-in extremamente grande que é somente usado em uma única página raramente visitada, deve ficar em um arquivo separado e só linkado na página que é usado. Embora, na maioria das vezes é seguro colocar versões comprimidas de todos os seus plugins num arquivo só para fácil acesso.

Aqui um exemplo de como um arquivo deve se parecer, incluindo uma pequena tabela de conteúdo. Isso pode servir como um guia prático para os plugins que estão em uso, incluindo URLs para documentação, razão para o uso e assim por diante:

Script.js

Script.js serve para conter o código da sua aplicação ou site. Novamente, esta não é sempre a melhor solução em uma grande equipe. Projetos grandes e ricos em recursos podem acabar dividindo o código do aplicativo em módulos ou recursos em arquivos específicos. Para sites pequenos, aplicações simples ou protótipo inicial, deixe seu trabalho no scripts.js para fazer mais sentido.

Um exemplo simplificado, usando o padrão da marcação discreta abrangente baseada em DOM, pronta pra execução, poderia ser algo como segue abaixo:

Variáveis, ID & Classes

Todas as variáveis JavaScript devem ser escritas apenas com minúsculas ou camelCase. A única exceção para este caso é se estiver criando Constructor Functions, quais começam com maiúsculas por tradição. Todo id e declarações class em CSS, devem ser escritas usando apenas minúsculas. Não use traços, nem sublinhados.

Delegação de Eventos

Ao atribuir ouvintes de eventos discretos, normalmente é aceitável atribuir diretamente para os elementos que irão disparar alguma ação resultante. No entanto, ocasionalmente pode existir vários elementos que correspondam aos critérios para o qual você está verificando, e anexando ouvintes de eventos para cada um deles, isso pode afetar negativamente o desempenho, nestes casos, ao invés disso você deve usar a delegação de evento:

jQuery's delegate() é preferível ao live(), por questões de performance.

Debugando

Mesmo com os melhores validadores, inevitavelmente certas peculiaridades do navegador irão lhe causar problemas. Abaixo algumas ferramentas úteis que irão lhe auxiliar a refinar a integridade do seu código ou ajudar na velocidade de carregamento. É importante que você tenha todas essas ferramentas disponíveis com você, apesar do navegador primário que você usa para desenvolvimento. Nós recomendamos primeiramente codificar para o Firefox e Safari, então Google Chrome e Opera e adicionando tweaks com comentários condicionais apenas para o Internet Explorer. A lista a seguir possuí vários depuradores úteis e analisadores de velocidade:

Padrões para um melhor JavaScript

  • Escreva um código de fácil manutenção
  • Padrão único para var
  • Elevação: Um problema com vars dispersas
  • (Not) Augmenting Built-in Prototypes
  • Evite Conversão de Tipo Implícita
  • Evite eval()
  • Converta número com parseInt()
  • Localização de chave de abertura
  • Capitalize Constructors
  • Escreva comentários
  • Evite void
  • Evite with Statement
  • Evite continue Statement
  • Evite Bitwise Operators, se possível

Stoyan Stefanov fala mais sobre estes e outros detalhes aqui.

{}

Acessibilidade

Este é um assunto bastante amplo, que é separado de tudo se passa dentro de um site. Acessibilidade tem haver com tudo, de como o conteúdo é escrito para a estruturação da marcação HTML, aparência e estilo, a melhoria progressiva e a degradação suave, como o significado semântico do seu código e como ele é lido pelos navegadores.

Nós trazemos pessoas e marcas em conjunto, como nunca visto antes. E mais importante que alcançar tantas pessoas, fornecemos novas e emocionantes experiências "nunca vistas antes". Algumas áreas para se considerar uma boa acesssibilidade durante o desenvolvimento de qualquer projeto são:

  • Marcação e semântica
  • Usabilidade da interface, pelo teclado e com o JavaScript desabilitado
  • Correto uso das tags, atributos e descrições
  • Conteúdo em texto para todo conteúdo não-texto
  • Resumo do conteúdo para leitores de tela (screen-readers)

Estas áreas são todas estreitamente relacionadas para que possa ser mais fácil discriminá-las com base em tipos de projeto. Aqui algumas coisas que devem ser feitas para alcançar uma página web acessível:

Pular Navegação

Se o seu site possuí elementos de navegação antes do conteúdo principal, providencie um link para os leitores de tela para "Pular para o conteúdo principal". Esse é um link que normalmente é escondido com o uso de CSS, mas será exibido no leitor de tela para pular a navegação e indo direto pro conteúdo.

Tab Index

O índice-guia de um documento começa com o primeiro link do documento e funciona através de todos eles do início até o fim. Este é frequentemente inutilizável e não intuitivo na forma que os elementos aparecem na tela. Se assegure que a ordem de tabulação dos links e elementos ativos é lógica, usando o atributo tabindex. Elementos de formulário devem ser tabulados através da ordem que um usuário espera concluí-lo, não necessariamente na ordem das tags em HTML.

Siglas/Abreviações

Se o seu conteúdo usa abreviações ou siglas, elas devem ser expandidas usando as tags abbr e acronym.

Imagens

Todas as imagens devem ter o atributo alt. Atributos alt dão significado e descrevem o conteúdo da imagem. Se a imagem é puramente decorativa, atributos alt devem ser marcados em branco usando alt="". Não coloque algo como alt="Esta imagem é apenas decorativa", isso será irritante para o usuário que utiliza leitores de tela.

Não use imagens para criar espaços ou outros efeitos similares, isso pode ser feito apenas usando CSS.

Flash e Substituição de Imagem

Sempre use um conteúdo HTML de backup para o flash. Todas as promo imagens devem usar CSS baseado em substituição de imagem em vez de tags alt.

Fallback para versões sem flash:

Ter um fallback para flash e imagens também irá ajudar o SEO.

Tabelas

Tabelas devem ser usadas apenas para dados tabulares. Ela não deve ser usada com propósitos de apresetnação ou de layout. Quando usar tabelas:

  • Use o elemento th para o cabeçalho da tabela. Se o cabeçalho tiver abreviações, use o atributo abbr para expandi-las.
  • Para tabelas complexas, use o atributo scope nos cabeçalhos da tabela para indicar a quem elas dizem a respeito.

Cores

Uso de cores deve cumprir o seguinte:

  • Texto deve dar leitura com alto contraste. Ou use um fundo claro com um texto escuro ou vice-versa. Um texto muito claro com um fundo claro é praticamente impossível de se ler para a maioria das pessoas, e pode ser ainda pior para quem é daltônico.
  • Não use vermelho e verde juntos para fazer distinções entre funcionalidades chaves - uma porcentagem de pessoas não serão capazes de distinguir-los.

O site WAI contêm uma lista de ferramentas focadas para usuários com daltonismo, algumas que lhe permitem ver o site como as pessoas com diferentes tipos de daltonismo vêem.

JavaScript

Páginas devem continuar a ser funcionais mesmo desabilitando o JavaScript. Aplicações devem degradar normalmente, ou quando possível fazer uso dos polyfills, para adicionar aos navegadores mais antigos as funcionalidades que eles não suportam.

Seção 508

Interfaces desenvolvidas pela Isobar devem ter conhecimento sobre os Padrões da Seção 508.

Acessibilidade Checklist

Aqui o checklist da W3C sobre os pontos de verificação para acessibilidade. Intefaces desenvolvidas pela Isobar devem conhecer as diretrizes - Prioridade 1 - Diretrizes WCAG 1.0.

{}

Performance

Enquanto nós continuamos a ultrapassar os limites do que é possível fazer na web, continua sendo importante que uma página tenha que ser usada com o mínimo de esforço ou tempo de espera possível. A seguir algumas explicações sobre como páginas web podem ser otimizadas para continuar a deixar todos os públicos felizes.

Otimizar a entrega do CSS e do JavaScript

Segue algumas otimizações que devem ser feitas para servir CSS e JavaScript em produção:

  • Seguir as diretrizes de performances do Yahoo
  • Reduza imagens usando o smush.it. Também use o YSlow, que reduz automaticamente todas as imagens para você.
  • Configure apropriadamente o cache dos cabeçalhos.
  • Considere um subdomínio sem cookies para static assets
  • Evite blocos em linha de .
  • CSS deve estar localizado no <head> do documento, JavaScript deve estar logo antes da tag </body>.
  • '
  • CSS e JavaScript devem estar minificados no lado do servidor. A maioria das pessoas usam o YUI Compressor para isso.
  • Ambos devem ser servidos usando gzip
  • CSS devem ser concatenados juntos. Obviamente só pode ser feito com arquivos que compartilham o mesmo tipo de mídia (e.g. screen ou print). O objetivo principal é reduzir o número de conexões HTTP com dependências durante o carregamento da página.
  • JavaScript deve ser concatenado. Enquanto um gerenciador de script ajax seria o ideal (similar ao YUI 3 Loader), é mais complicado de se implementar. No seu lugar, eu recomendo um download singular da maior parte do script usado no site. (Claro, cache apropriado deve ser usado para reter o arquivo, se possível.)
  • Concatenação e minification normalmente ocorrem durante um processo de build automatizado, ao empacotar o código para implantação no palco ou de produção. Muitos usam ferramentas como Ant ou Maven.
  • Evite blocos <script> em linha com o HTML. Eles bloqueiam a renderização e são bastante devastadores com o tempo de carregamento de página.

Otimize a execucão do JavaScript

Durante o carregamento da página, é comum alguns scripts esperarem para executar, mas você pode priorizar isso. Esta ordem prioriza com base na resposta do usuário:

  1. Scripts que mudam visivelmente a natureza da página precisam ser carregadas primeiro. Isso incluí qualquer ajuste de fonte, layout de caixa, ou IE6 pngfixes.
  2. Inicialização do conteúdo da página
  3. Cabeçalho da página, navegação superior e inicialização do rodapé
  4. Anexar manipuladores de eventos
  5. Omniture, Doubleclick, e outros scripts de terceiros

Alavancagem dos CSS Sprites

CSS Sprites normalmente tem uma porção de imagens mescladas juntas em um arquivo único de imagem. Cada parte é revelada usando CSS background-position. Alguns normalmente seriam assim:

É muito comum o uso de sprites para estados de :hover. No caso, será algo assim:

Usando CSS sprites você reduz o peso total da página e também o número de conexões HTTP, acelerando o carregamento da página. Mais sobre técnicas gerais e uma visão sobre sprites. Isto é apenas uma melhor prática para se fazer, mas sempre que puder, faça o uso de CSS Sprites.

Muitos desenvolvedores usam um sprite verticalmente-orientado para o sprite primário. Este sprite vertical deve ter menos do que ou igual a 100px de largura (e alto), conter ícones que normalmente são colocadas junto ao texto, tais como balas de ítem de lista ou ligue para links e botões de ação. Yahoo usa poucos como este.

A única consideração é que não fazer sprites muitos largos, algo entre 1000px em qualquer direção vai acabar usando uma quantidade considerável de memória. Leia mais em quando usar sprites e o uso de memória, e para mais dicas gerais e técnicas na criação de sprites, veja o Mozilla Dev Blog.

Formato de imagens

Aqui os quatros principais formatos de imagens que devem ser usados, detalhes abaixo:

JPEG
Ele será responsável por todas as imagens fotográficas, tal como imagens promocionais da homepage e categoria, ou qualquer imagem com um número muito alto de cores.
PNG24

Este formato é facilmente acessível em Photoshop, gera imagens de alta contagem de cores e apoia suporte a opacidade graduada por pixel. Relativamente, é um formato pesado, medindo em kilobytes. Este é apenas o único formato que o IE6 precisa executar um pngfix para funcionar. Quando projetos precisam dar suporte ao IE6, nós usamos o script DD_belatedPNG (Um pngfix que corrige o problema quando PNG24's aparece com um cinza ou um azul claro fundo no IE6. Eles nem sempre são compatíveis com background-position).

Em muitos casos você pode usar um fallback em GIF para o IE6 no lugar do PNG24. Isso será mais evidente se quaisquer sprites precisam ser feitas em PNG24. Todos os pngfixes são muitos lentos e caros, por isso é melhor evitá-lo.

PNG8

A surpreendente diversidade de cores pode ser capturada dentro das 256 cores, por isso vale a pena tentar PNG antes de JPG. PNG também é muito mais compacto que o GIF. Este formato permite opacidade graduada em quase todos os navegadores, mas no IE6 os pixels semi-opacos são apenas mostrado com transparência 100%. Em muitos casos isso é suficiente. Ele também não exige um pngfix para ser executado, por isso é útil para melhor performance.

Photoshop não pode produzir esses arquivos semi-opacas corretamente, mas o Fireworks pode.http://www.sitepoint.com/blogs/2007/09/18/png8-the-clear-winner/

Transparent GIF 89a

GIF 89a oferece a flexibilidade da transparência e amplo suporte dos navegadores, mas com as restrições de nenhuma opacidade graduada, nem uma profundidade acima de 256 cores. Em nossa experiência, profundidade de 64 cores fornecem boa qualidade em miniaturas, e mantem o tamanho do arquivo comparativamente muito pequeno.

Todas baixa contagens de cores em imagens como ícones ou gráficos temáticos devem ser feitos em PNG8, como é mais eficiente em termos de tamanho deste quatro. PNG8 é a nossa principal recomendação para a maioria dos gráficos em sites.

Detalhes sobre o formato PNG, suporte dos navegadores, e os prós e contras são abordados neste artigo.

Para mais otimização destes formatos, use o Yahoo's Smush.It, ele irá revelar como eles podem ser menores.

Cache

Para conteúdo estático, o navegador deve se possível cachear o arquivo localmente. O conteúdo que deve ter o cache com a data em um futuro distante inclui:

  • arquivos CSS e JavaScript
  • imagens de produtos
  • gráficos temáticos
  • favicon.ico
  • flash .swf's e vídeos
  • imagens promocionais (leve cache)

Para um melhor cache, alavanque o Expires http header. Aqui um exemplo de futuro distante de Expires header, dizendo ao navegador que esta resposta não será considerada obsoleta até 15 de abril de 2015.

Expires: Thu, 15 Apr 2015 20:00:00 GMT

Se o seu servidor é Apache, use a diretiva ExpiresDefault para configurar uma data de expiração relativa a data atual. Este é um exemplo usando o ExpiresDefault, configurando o Expires date para 1 ano depois da data de requisição.

ExpiresDefault "access plus 1 year"

Expires http header deve ser configurado para um valor entre um mês a partir do presente a um ano (futuro distante) do presente. Cacheamento aplicado em apenas uma exata URL, para uma mudança no nome do arquivo de qualquer ativo vai começar uma nova cópia. Muitos desenvolvedores usam um processo de construção para adicionar um número de versão ou carimbo de tempo, um exemplo disso é o HTML5 Boilerplate. Cada compilação subsequente vai começar uma nova versão em cache, permitindo que você use datas de cache de futuro distante sem se preocupar. Google tem bastante detalhes sobre cache do navegador.

Recursos compartilhados em vários domínios

Conteúdo estático deve certamente ser servido de um domínio diferente daquele que serve o HTML. Isto é o ideal e não há que ter extra cookies headers em toda requisição de conteúdo estático. É também muito fácil de se escrever regras de cache para todo o domínio. (Também qualquer subdomínio do domínio atual irão herdar os cookies, por isso vale a pena usar um domínio completamente novo).

Embora com suficientes acertos (especialmente em imagens) o número de requisições cresce o suficiente para deixar lento o carregamento da página. Muitos navegadores têm uma restrição baixa de quantas coisas que irão baixar simultaneamente por domínio. (No IE6 e 7, é apenas dois). Em todo o caso, podemos servir múltiplos domínios dessa forma:

  • static1.otherdomain.com
  • static2.otherdomain.com
  • static3.otherdomain.com

Mais informações sobre sharding de domínio no Google Speed

Evite IFRAMEs

Iframes são o elemento mais caro para adicionar a uma determinada página. Eles bloqueiam a página de disparar o evento onload até que eles estão completos. Às vezes, são úteis para permitir que outra agência possa lidar com scripts de rastreamento. Por exemplo, a tag do Doubleclick é um iframe, e o administrador pode adicionar rastreamento de pixels em seu painel. Em qualquer caso em que um iframe é adicionado, deve ser anexado ao DOM dinamicamente após a janela de onload foi disparada. Mais detalhes no site sobre Performance do Yahoo.

Interação com serviços de terceiros

Omniture

Nós recomendamos que adicione o código do Omniture JavaScript para o DOM usando JavaScript após a página ter sido carregada (seja um evento DOM ready ou window's load event). Usando esta técnica, não terá dependências de scripts partindo de domínios externos, que pode deixar o site lento (e bem lento).

Flash

Conteúdo de backup deve estar no mesmo lugar do Flash em todos os casos para maximizar o trabalho do SEO. Para XML-driven, o backup do conteúdo deve ser alavancando com o mesmo arquivo XML, para garantir a consistência dos dados.

Todas as substituições devem ser feitas usando SWFObject, mas sem tags em linha script. Inicialização SWFObject deve executar após o evento DOM Ready. Versões do player devem estar ajustadas para no mínimo v9, para garantir compatibilidade com AS3.

Estratégia de Performance Cross-Browser

Há duas importantes verdades quando se trata de experiência de navegador:

  1. Sempre procure a experiência mais responsiva possível.
  2. Tudo adicionado a página desacelera.

Assim com estes dois fatos da vida, quais os passos que precisamos para deixar todos felizes?

Crie métricas de sucesso com o cliente

Estas devem ser customizadas para o seu cliente e projeto, devem também ser terminadas antes da fase de wireframing. Estes objetivos devem ser razoáveis a partir de um POV técnico, bem como testáveis.

Alguns objetivos que seriam apropriados:
  1. O navegador mais lento suportado deve carregar totalmente a página com o cache vazio em 5 segundos.
  2. Estados hover (e outras mudanças 'instantâneas') devem responder com 100ms.
  3. Animações devem surgir suavemente, com jumpiness ocorrendo < 15% do tempo (em todos os navegadores).

Para metas de carregamento de página, é importante definir o benchmark do sistema. Uma boa opção é o PageTest. Adicionalmente, metas podem ser definidas para múltiplas páginas, por exemplo: as duas maiores páginas de destino (ex: homepage e suporte).

Se o cliente tiver metas mais agressivas que são razoáveis ​​com o que é pretendido, as expectativas devem ser definidas através de reuniões do conselho, avisar a equipe das metas de desempenho do projeto é fundamental.

Comunicando o impacto de performance durante o processo de design

Internalmente

Durante IA, IxD, e o a criação do design, é o papel do front-end comunicar o impacto de performance das características interativas ou certas técnicas visuais dos navegadores alvos. Dê aos designers as restrições: "Se nós usarmos Cufon, não podemos ter mais de 10 elementos de fontes customizadas por página.

Externamente

Expectativas precisam ser definidas, todos os navegadores não terão a mesma experiência. Eles não vão executar bem como uns aos outros, não farão sentido eles terem semelhanças. Seria sensato deixar de suportar algumas características para a experiência com IE7. Catacterísticas que podem ser descartadas: shadows, transitions, rounded corners, opacity, gradients.

Quando comunicamos o impacto de algo:
  • Deixe claro o impacto com os maiores detalhes possível: "isso irá ferir o carregamento da página" vs "isso somará mais 2 segundos de carregamentos do site no IE"
  • Fornecer um POC rápido (prova de conceito), se possível: "É uma página semelhante sem siFR carrega em 2 segundos, com siFR ela carrega em 8 com um atraso para visualizar quando há rolagem"

Desenvolver de acordo com as melhores práticas

Escolha bibliotecas e plugins que tem otimização na performance. Tome decisões sábias na arquitetura baseado nas metas de performance. Também minimize manipulação do DOM quando possível, e escreva estilos para evitar mudanças visuais quando a página carrega e inicializa.

Medir a performance durante o QA

Equipes QA (em português, Garantia da qualidade) devem também priorizar desempenho, relacionados ao lado do visual e questões de usabilidade. Desenvolvedoress e QA devem determinar como esta prioridade será atribuída. Durante o QA, as métricas de sucesso devem ser testadas regularmente.

Ferramentas para teste Quando as metas de performance não são cumpridas, há três opções:
  1. Reconstrua o código - o perfil, descubra os gargalos, refatore o código, otimize para atingir uma execução mais rápida no navegador
  2. Largue o recurso - desligá-lo apenas para os navegadores mais lentos
  3. Redesenho da abordagem do UI - talvez o projeto poderia usar um ajuste que seria ignorar totalmente o problema

Com esta abordagem, nós achamos que todas as partes devem ter uma melhor chance de ter as expectativas alinhadas, bem como um fluxo de trabalho mais sensível ao lidar com os desafios de desempenho.

{}

Teste com Navegadores e Suporte

A audiência de hoje pode escolher entre uma grande variedade de navegadores web, cada um fornecendo uma ligeira (ou dramática) diferença na experiência do usuário. Como desenvolvedores, a nossa responsabilidade é escolher apenas como as páginas serão construídas e exibidas para aqueles usuários. Este capítulo descreve como nós da Isobar tomamos algumas dessas decisões-chave.

O que damos suporte

Browsers

A Isobar dá suporte a qualquer navegador com Grade-A no Yahoo's Graded Browser Support, com exceção do Opera. Pode haver exceções a este, em função dos mercados regionais e suas métricas específicas.

Faremos o possível para dar suporte a qualquer outros navegadores de missão crítica solicitados pelo cliente (IE 5.5, Opera, Konqueror, Safari 3 no PC etc), embora não possamos garantir todas as funcionalidades.

Como nós testamos

Testes abrangentes em navegadores é uma necessidade em todos os projetos web da Isobar. Um esforço considerável deve ser feito para testar em vários navegadores e plataformas para garantir a qualidade e experiência consistente do usuário. Configurar um ambiente de teste pode ser um desafio, mas pode valer a pena.

No Microsoft Windows

Teste com IE

Desde que se tornou impossível ter mais de uma única cópia do Microsoft Internet Explorer instalada no PC, testar para o IE se tornou um desafio. Felizmente, a Microsoft finalmente tornou disponível para download, versões antigas de desenvolvimento do Internet Explorer. Esses Discos Virtuais (VH's) rodam versões antigas do Microsoft Windows que expiram (tempo limite) ao longo do tempo. Configurá-lo novamente depois de alguns meses se torna comum. Cópias de desenvolvimento do Microsoft Windows de sua licença MSDN (se estiver disponível) também pode ser uma opção, dependendo do que você tem acesso.

  • Virtual PC - Virtual PC deve ser instalado no seu computador, e se você estiver no Windows 7, você deve usar o "Modo XP".
  • Microsoft Windows VPC Images - Diversas variedades de imagens de discos virtuais estão disponíveis. Dependendo do seu projeto, você pode necessitar instalar diversos para ter um conjunto abrangente de testes.

Existem outras opções menos eficazes de testar o IE (normalmente não recomendado) incluem IETester, o que ainda é melhor do que Multiple_IE e IE7 standalone.

Firefox
Safari para PC
Opera
Google Chrome e suas versões

Google Chrome se atualiza automaticamnete e para nossa sorte, a maioria dos usuários tem a versões mais recente deles. Com ele é mais fácil, então, não se preocupe com versões antigas do Google Chrome.

No Mac OS X

O core dos navegadores Mac OS X, Mozilla Firefox, Google Chrome e Apple Safari oferecem experiências de navegador praticamente idênticas aos do Windows. Algumas diferenças de nível de sistema operacional pode estar presente e sites devem ser testados em ambas as plataformas. Diferenças típicas ocorrem em torno de renderização de fontes e por vezes surgem questões de espaçamento.

Teste para Windows em um Mac

Existe um número de opções para testes em navegadores no Windows no Mac OS. Primeiro, o Mac oferece uma partição "boot camp", que permite que você inicialize uma partição Microsoft Windows. Este é um ambiente de teste complexo, mas completo. Depois de iniciar no Windows, o normal é ter as todas opções que existem nele.

Outras opções incluem virtualização do Windows dentro do Mac OS X, que permite que você literalmente rode o Windows dentro do Mac OS.

As Microsoft VHD's podem ser abertas e convertidas na maioria dessas opções, portanto, permitindo o mesmo grau de destreza nos testes que os usuários do Windows têm à sua disposição. Embora desde que você também pode testar no Mac ao mesmo tempo, alguns podem argumentar que você tem mais flexibilidade...

  • Parallels - Parallels está disponível e já pode ser instalado pelo departamento de TI Isobar no seu Mac.
  • VMWare Fusion - VMWare Fusion oferece o mesmo nível de virtualização do Windows através do seu produto Fusion.
Mozilla Firefox

Assim como no Windows, você pode instalar e rodar várias cópias do Mozilla Firefox no seu Mac, embora seja um pouco mais complicado de configurar vários perfis através do Profile Manager. Aqui algumas dicas que você pode usar com o Automator, para fazer perfis separados e executá-los bem.

Bugs nas versões standalone do IE

Nota: O IE6 standalone tem um bug de implementação de opacidade em alguns casos. Isto irá resultar em falhas em qualquer opacidade aplicada com um filtro de CSS, como alfa opacidade ou um PNG de 24-bit. No caso de opacidade deve ser testado, você vai precisar de uma instalação nativa IE6.

Foi noticiado que o IE7 usando a plataforma do Vista não tem diferença das versões do Windows XP, portanto, você pode querer ter certeza de que alguém em sua equipe tem esta configuração também. IETester sabe-se que corrigir uma série destas questões, assim como os navegadores Xenocode.

Resolução do Navegador

Junto com a restauração de browsers, os desenvolvedores devem ficar consciente das resoluções de tela de seu público. Como as telas dos monitores ficaram maiores, a amplitude das resoluções cresce também. Abaixo estão algumas diretrizes para ajudá-lo a trabalhar com resoluções.

Resolução 1024px

  • Altura de rolagem visível estimada em 570px.
  • Ideal largura com: 960px - Tem espaçamento confortável nos dois lados, é dividido por muitos números, e também se sai bem com o padrão IAB
  • Maior largura: 970px - Continua com alguns espaçamentos nos dois lados na maioria dos navegadores. A matemática, joga bem com o Golden Ratio
  • Máxima largura: 996px - Sem incluir barras de rolagens horizontais na maioria dos navegadores. Baseado nesta pesquisa , o máximo é de 1003px de largura, se você não quer uma barra de rolagem horizontal.

Estatísticas atuais sobre tamanhos de janela

Resolução do sistema não é, contudo, o mesmo que o tamanho do navegador

{}

Otimização para Motores de Busca

Uma parte essencial de um bom web design e o desenvolvimento é o SEO (em inglês, Search Engine Optimization). Um bom e estruturado código é a chave para assegurar que uma página web não é só corretamente indexada por motores de busca, mas também é acessível para as pessoas com capacidades limitadas.

Esteja ciente de melhores práticas de SEO

Indexação

Nós devemos sempre usar a marcação semântica porque é legível e lógica quando o JavaScript e o CSS estão desligados. Todo o conteúdo de uma página deve ser estar em HTML. Nós não devemos usar iframes ou JavaScript para carregar conteúdo indexável.

Todas as ligações devem ser para destinos HTML.
Em vez de

Este permite que a página indexe corretamente pelos motores de busca e também permite que os usuários abram-os em novas abas e janelas.

Otimização

A tag title deve possuir palavras-chaves para uma página única. Os títulos devem ser únicos para cada página. Cabeçalhos (h1, h2 etc) devem formar um contorno do documento e representar as mais importantes palavras-chave para a página. URLs devem ser legíveis com palavras-chave alvo presentes nelas:

http://domain.com/mens-shoes/basketball/jordan/jordan-mens-ajf-6-basketball-shoe/

vs

http:// domain.com/ecomm.cfm?view=prod&prodId=23425

Google's SEO Report Card

Google's SEO Report Card é um esforço para fornecer ideias às equipes de produtos do Google sobre como eles podem melhorar a páginas de seus produtos usando otimizações simples e aceitáveis. Essas otimizações são destinadas não apenas ajudar que os motores de busca entendam melhor o conteúdo da sua página, mas também como melhorar a experiência destes usuários.

Quando visitamos estes sites medidas simples como fixação de ligações 404s e links quebrados, simplificando a escolha da URL, e proporcionando meios mais fáceis de entender títulos e trechos de suas páginas, podem beneficiar os usuários e os motores de busca.

{}

Revisões de código

Uma revisão de código é a pedra angular do processo formal para garantir a qualidade da experiência do usuário desenvolvido pela equipe de tecnologia criativa. Trata-se de uma reunião entre os autores de marcação, revisores e outros interessados, com revisões de código subseqüentes. Simplificando, nós incentivamos a realização de revisões de código para manter as nossas ferramentas afiadas e limpas.

Por que eu deveria fazer uma revisão de código?

As revisões de código são um investimento estratégico de tempo para mitigar o risco em um projeto.

Muitas vezes, pede-se aos desenvolvedores de interface que façam composições visuais através do wireframe. No entanto, é possível que essas telas desenhadas não possam ser traduzidas com facilidade para a marcação sem comprometer a qualidade. As revisões de código fornecem uma oportunidade para tratar o risco e de serem resolvidas antes que a produção total das páginas começe.

Revisões de código aumentam o nível global de conhecimento entre os projetos

Desde que a revisão de código envolva membros de fora e de dentro da equipe, técnicas e melhores práticas são facilmente compartilhadas ao longo de toda a equipe de tecnologia criativa.

Revisões de código eliminam bugs antes deles serem reproduzidos em alguns modelos e multiplicado em várias páginas

Normalmente, revisões de código são conduzidas no início do processo de desenvolvimento, antes da plena produção das páginas começarem. Quando os modelos são revisados pela equipe e executados através de ferramentas de validação de múltiplos navegadores, bugs começam a aparecer. Este é o momento ideal de serem corrigidos.

Revisões de código dão uma refrescada nos seus olhos e uma oportunidade de detectar os problemas com o código

Revisões de fora da equipe do projeto podem identificar mais facilmente problemas com o código que os autores da marcação, que já tem trabalhado com o mesmo código por um longo período de tempo.

Quem deve participar da revisão de código?

Em última análise, é necessário a presença do desenvolvedor líder para garantir que foram seguidos os prodecimentos adequados de revisão.

Normalmente, um líder deve agir como facilitador para uma sessão de revisão de código, a menos que o líder é também o desenvolvedor de interface, cujo código está em análise. Nessa situação, um gerente de projetos pode ser trazido como um facilitador.

A equipe de revisão deve incluir pelo menos dois membros sênior da equipe de tecnologia de interface experientes em práticas recomendadas de desenvolvimento.

O que é necessário para uma revisão de código?

Antes da revisão de código ser conduzida, modelos para serem revisados devem estar completamente desenvolvidos, validados e testados em navegadores e plataformas suportados pelo projeto.

O líder na prática e/ou desenvolvedor de interface deve distribuir em 48 horas anteriores à data da revisão de código:

  • Código para todas as páginas, includes associados do lado do servidor, CSS e JavaScript. Estes devem estar completamente comentados, impresso com os números de linha no lado esquerdo, e o nome do arquivo/página no rodapé de cada página impressa.
  • Imagens (screenshots) de cada modelo
  • URLs dos modelos, se for o caso
  • Uma lista com os navegadores e plataformas suportados por este projeto
  • Uma lista com conhecidos
  • Uma lista de problemas conhecidos e zonas de interesse

É comum para o código ser mudado constantemente até chegar a data de revisão do código. Infelizmente, isto não deixa tempo suficiente para validação e testes. Se for o caso, é recomendado que a revisão do código seja remarcada para uma data que garante uma revisão de código adequada.

Além disso, o líder na prática e/ou o desenvolvedor da interface deve reservar uma sala de conferência e chamada em número para todos os participantes, já que é possível que os membros do projeto ou equipe de revisão do código são de fora. Uma hora deve prever tempo suficiente para revisão de dois ou três modelos, embora, tempo irá variar dependendo do volume e complexidade dos modelos.

Durante a revisão do código, o líder na prática e/ou desenvolvedor da interface deve facilitar o encontro, enquanto o líder ou o gerenciador de projeto toma notas e atribui itens de ação. Os comentadores devem rever o código e chegarem preparados para realizar perguntas ou fornecerem comentários.

Notas e ítens de ação (incluindo proprietários) devem ser distribuídos a todos os participantes após a revisão de código. Se mudanças substanciais acabarem saindo de uma revisão, ou todo o código não foi revisado, será necessário agendar uma segunda revisão dele. No entanto, isso deve ser discutido entre a equipe do projeto para determinar a viabilidade.

{}

Apêndices

Aqui algumas referências, ferramentas e outras coisas que se relacionam com este documento.

Apêndice A: Validadores

Apêndice B: Ferramentas

Editores de código

Um bom editor de código pode acender a produtividade de formas excepcionais. Muitos desenvolvedores preferem editores de texto rudimentares, enquanto outros preferem poderesos ambientes integrados de desenvolvimento (IDEs). Segue uma lista geral com algumas das mais bem conhecidas ferramentas; já que seria impossível enumerar todas que existem.

Aptana
Aptana Studio é um poderoso, gratuito e open-source ambiente de desenvolvimento Ajax que roda em stand-alone ou com Eclipse. Aptana Studio oferece ferramentas para Ajax, incluindo HTML, CSS, DOM e edição e debug de JavaScript, com suporte para adicionais e gratuitos plugins para desenvolvimento em PHP, Ruby on Rails e Adobe AIR. Ele também possui integração total com repositórios SVN para commiting, branching, tagging, merging e navegação em repositórios. Aptana. [Linux, Mac, Windows]
Geany
Geany é um editor de texto usando o kit de ferramentas GTK2 com características básicas de um ambiente integrado de desenvolvimento. Foi desenvolvido para ser uma pequena e rápida IDE, que tem apenas algumas dependências de outros pacotes. Ele suporta muitos tipos de arquivos e tem algumas características interessantes. Geany. [Linux, Mac, Windows]
Notepad ++
Notepad++ é gratuito (livre como "liberdade de expressão", mas também, como "cerveja grátis") editor de código e substituto do Bloco de Notas, que suporta várias linguagens de programação. Roda apenas em ambiente Windows. Notepad ++. [Windows]
e TextEditor
E é um novo editor de texto para Windows, com poderosas características e com algumas habilidades únicas. Ele faz manipulação de texto de forma rápida e fácil, e permite que você foque no que você está codificando, automatizando todo o trabalho manual. Suporta várias linguagens e é apoiado pelo TextMate, permitindo que você toque em uma larga e ativa comunidade. e TextEditor. [Windows]
Edit Plus
EditPlus é um editor de texto, HTML e editor dos programadores para Windows. Enquanto ele serve como um bom substituto do Bloco de Notas, ele também oferece muitas características poderosas para autores de páginas web e programadores. EditPlus. [Windows]
Homesite
HomeSite 5.5 fornece um fino editor apenas para desenvolvimento web. Características avançadas possibilitam que você instantaneamente crie e modifique HTML, CFML, JSP e tags XHTML, enquanto as ferramentas de produtividade aprimoradas permitem-lhe validar, reutilizar, navegar e formate seu código facilmente. Configure o Adobe (antiga Macromedia) HomeSite para atender às suas necessidades, aumentando a sua funcionalidade e personalização da interface. Homesite. [Windows]
TextMate
TextMate diz ser o "Editor Perdido" para Mac OS X. Um editor de propósito geral com uma interface esparsa, o verdadeiro poder está em sua extensibilidade. Características de seleções de coluna, macros graváveis​​, trechos, auto-emparelhamento de colchetes e outros caracteres, histórico de clipboard, dobramento de código, guia-triggers, espaços reservados com guias e mirror typing. E isso é só o começo. Qualquer coisa que pode ser feito através de scripts de linha de comando através do Mac pode ser feito através de comandos personalizados, permitindo um alto grau de personalização e expansão do conjunto de recursos. TextMate do formato "bundle" foi adaptado por muitos outros editores de código, incluindo o TextEditor acima mencionado. TextMate. [Mac]
Espresso
Espresso foi criado pelo mesmo companheiro que criou o inovador editor CSS, CSSEdit. As características do Espresso são destacamento da sintaxe, dobramento do código, conclusão de código, navegadores de documento, projetos, poderoso pesquisador de código, e recursos internos de publicação de arquivos de transferência. E finalmente, um "doce" poderoso conjunto de recursos que permitem a criação de comandos personalizados e plugins. Espresso. [Mac]
BBEdit
BBEdit é um grande-pai dos editores de código do Mac para desenvolvimento web. Possui destacamento de sintaxe, ferramentas de manipulação de texto excepcionais, busca em vários arquivos, uma API programável, recortes de texto e extensas funcionalidades do Mac Automator. BBEdit. [Mac]
TextWrangler
O "pequeno irmão" gratuito do BBEdit, é o poderoso cru editor de texto com um massivo conjunto de características de manipulação texto. Pesquisas, expressões regulares, transformações de texto, destacamento de sintaxe e ferramentas de navegação de código para uma variedade de ambientes com diferentes linguagens. TextWrangler. [Mac]
Coda
Coda, da empresa Panic software é uma poderosa IDE com edição de código, terminal, gerenciamento remoto de arquivos e documentação de ajuda, todas construídas em apenas uma interface de usuário. Com o objetivo de ser um balcão único para o fluxo de trabalho de desenvolvimento web, ela também tem integração com SVN e um novo construtor de plug-in com poderoso suporte programável e pacote de importação com TextMate. Finalmente, clips de código e edição em tempo real de multi-usuário também são suportados. Coda. [Mac]
UltraEdit
Outro editor que tem sido durante os anos, um dos mais robustos e poderosos editores texto, capaz de abrir arquivos limitados apenas pela quantidade de memória no seu computador. Sua lista de capacidades é praticamente impossível de se listar, mas inclui uma grande capacidade de se manipular texto, suporte a projetos, poderosa pesquisa e substituição, edição hexadecimal, lista de funções e uma grande suporte de linguagens (mais de 600), FTP remoto, telnet, SSH, comparação de arquivos e macros programáveis, ferramentas e suporte a compiladores, e muito, muito mais. UltraEdit. [Linux, Mac, Windows]
Sublime Text
Um editor relativamente novo, Sublime Text é uma nova abordagem nos editores. "Abre qualquer coisa", faz pesquisas através de nomes de arquivos e conteúdos de arquivos, com notável eficiência. Incrível e poderoso controle de seleção permite editar o texto em vários locais imediatamente e o "Minimap" lhe dá uma visualização ao estilo olho de pássaro do arquivo aberto e você pode achar algo facilmente. Sendo ativamente desenvolvido e melhorado, novas características estão sendo adicionadas e a comunidade em volta do editor está rapidamente se expandindo. Macros, auto conclusão, snippets, build tools, e a lista de características vai crescendo. Suporta Linux e Mac começando da versão 2. Sublime Text. [Linux, Mac, Windows]
Vim
Se você tem que perguntar, não é provavelmente para você. Vim [Linux, Mac, Windows]

Extensões do Google Chrome

Ferramentas de Desenvolvimento
Não é realmente uma extensão para o Chrome, mas construído dentro dele (compartilha com o inspetor do Safari Web, ambos derivados de WebKit.) Esta suíte de ferramentas possuí um inspetor DOM, um básico depurador JavaScript, ferramentas de perfil, verificador de carregamento na rede com linha do tempo, verificadores de recursos da página e muito mais. Developer Tools.
code cola
Um painel pop-up com ferramentas de edição CSS para examinar e modificar estilos em uma determinada página. code cola.
Firebug Lite para Google Chrome
Você realmente não precisa instalar uma extensão para usar o Firebug Lite com o Chrome, embora a extensão é útil, porque permite que um você acione o aplicativo do script Firebug Lite para qualquer página que você estiver trabalhando. Não é o Firebug completo, mas chega perto. Firebug Lite.
HTML5 Outliner
O HTML5 Outliner adiciona um pop-up com um contorno de HTML5 gerado da hierarquia de cabeçalho da página atual. Ajuda para verificar a organização de suas páginas contra o novo cabeçalho HTML5 algoritmos de estrutura de tópicos. HTML5 Outliner.
Pendule
Bom conjunto de ferramentas para visualizar dados e interagir com a página web atual. Muito parecido com o a barra de ferramentas de desenvolvedores original do Firefox. Pendule.
Web Developer for Chrome
Chris Pederick, o desenvolvedor original da barra de ferramentas para desenvolvedores do Firefox, têm migrado a maioria deles para o Chrome. Lá você tem. Web Developer.

Firefox Plugins

FireFTP
FireFTP é um gratuito e seguro cliente FTP multi-plataforma para Mozilla Firefox, que fornece um acesso fácil e intuitivo a servidores FTP. FireFTP.
Firebug
Firebug integrado com Firefox te coloca um conjunto de ferramentas de desenvolvimento nas suas mãos enquanto você navega. Você pode editar, debugar e monitorar CSS, HTML e JavaScript em tempo real em qualquer página web. Firebug.
Firequery
FireQuery é um conjunto de melhorias para Firebug integrado com jQuery. Firequery.
Firecookie
Firecookie acrescenta visualização de cookies, edição e exclusão para Firebug. Firecookie.
CSS Usage
CSS Coverage é uma extensão para Firebug que lhe permite digitalizar várias páginas do seu site para ver quais as regras CSS que são realmente utilizadas por ele. CSS Usage.
Greasemonkey
Permite personalizar a maneira como uma página da Web exibe usando pequenos pedaços de JavaScript.GreaseMonkey.
Web Developer Toolbar
Adiciona um menu e uma barra de ferramentas com diversas ferramentas para desenvolvedor web. Web Developer Toolbar.
JSView
Adiciona um item na barra de status que exibe todas os arquivos externos JavaScript e CSS carregados em uma determinada página. Permite que você clique e visualize os arquivos e coisas como suas URLs. Ótima maneira de puxar as URLs dos arquivos para colocar em Charles para a depuração remota. JSView.
Live HTTP headers
Quando executado, captura todo o tráfego HTTP a partir do navegador, que permite ver quais arquivos estão sendo solicitados, bem como informações sobre os pedidos e respostas do servidor. Live HTTP Headers.
Quick Locale Switcher
Uma grande ajuda quando se faz a internacionalização, o Quick Locale Switcher permite que você altere a localidade enviada junto no cabeçalho do navegador HTTP user-agent, dizendo servidores para exibir conteúdo para você em outras localidades. Quick Locale Switcher.
Screengrab
Screengrab fica na barra de status do Firefox, permitindo-lhe capturar e copiar ou salvar imagens das telas de tudo, desde as seleções de uma página web para a página inteira, mesmo as peças exibidas "abaixo da tela de primeira rolagem". Screengrab.
Total Validator
Permite acesso de um clique para enviar sua página através de um validador de marcação. Não há melhor maneira de verificar rapidamente para etiquetas ausentes ou incompatíveis. Também disponível como um aplicativo independente. Total Validator.

Extensões do Opera

Dragonfly é a ferramenta de desenvolvimetno similar ao Firebug.

IE Plugins

CompanionJS, DebugBar, IE8 Dev tools.

Charles Proxy

Charles assiste todas as requisições e lhe traz um monte de informações sobre ela. Map Local também é extremamente útil, ele permite que você use um arquivo local no lugar de uma determinada URL (bom para a substituição de um js minified por uma completa).

Fiddler

Do site: Fiddler Debugging Proxy é um Web Debugging Proxy que registra toda a tráfego HTTP(S) entre o computador e a Internet. Fiddler permite que você inspecione o tráfego, defina pontos de interrupção, e faça "fiddle", com dados de entrada ou saída Fiddler inclui um poderoso evento. Baseado subsistema de script, e pode ser estendido usando qualquer linguagem .NET.

Speedlimit

Speedlimit é um painel de preferências (obras no Snow Leopard) para limitar a largura de banda de rede para um de um casal diferente velocidades-768k DSL, Edge, 3G e Dialup. Bom para testar suas mais baixas velocidades, ou quando você quer saber como seu aplicativo irá funcionar em velocidades do mundo real.

Tutoriais & Ferramentas:

Ícones

Apêndice C: Recursos