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

• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução das premissas dos controles de versão
• Boas práticas de Acessibilidade
• CSS1K

Framework é um conjunto de componentes que provêm uma estrutura básica de elementos reutilizáveis, tendo uma arquitetura consistente de funcionalidade genérica sob a qual a aplicação será construída.

O uso de uma Biblioteca (CSS, Javascript, etc) é bastante parecido com a utilização de um framework. Eu prefiro a utilização de uma biblioteca por ser menos instrusiva e muito mais personalizável. Existem algumas diferenças que você deve prestar sua atenção para entender qual das duas formas é melhor para o projeto.

Modificação visual

Enquanto o framework modifica as características visuais, a biblioteca se restringe manipulando a diagramação ou a posição dos elementos.

Na grande maioria, os frameworks modificam automaticamente o visual de alguns elementos, gerando um certo retrabalho, porque geralmente o design aplicado não é o design aprovado pelo cliente ou pelo designer do projeto. Veja por exemplo o Bootstrap feito pelo pessoal do Twitter. Assim que linkado em seu código, os elementos como os campos de formulários e parágrafos tem suas características visuais modificadas para seguir um design pré definido pelos donos do framework – diga-se de passagem, o trabalho de design feito pelo pessoal do Bootstrap é muito bacana. Já as bibliotecas, na maioria das vezes, não faz nenhuma modificação no design ou na posição dos elementos sem a inserção de Classe ou ID. Geralmente as bibliotecas são restritas para manipular a posição e as dimensões dos elementos, facilitando a diagramação de layouts, sem modificar as características visuais, já que os layouts de cada site tem o design diferente. É por isso que eu gosto de definir que frameworks são ótimos para construir sistemas, já as bibliotecas ajudam muito mais ao construir websites. Sistemas tem muitos formulários, botões de ação, pouco texto e etc. A utilização de um framework é muito interessante nesse caso porque não perdemos tempo manipulando e definindo um padrão visual para estes elementos – como os tamanhos dos campos de formulário de texto.

Já a biblioteca é muito útil para definir quando os elementos terão float, position, largura variável e etc. São características de posição e diagramação, que não afetam a questão do design.

Quantidade de código não utilizado

Geralmente ao utilizar uma biblioteca, talvez você estará linkando mais código do que o necessário para o seu projeto. Você pode não utilizar todas essas classes/ids pré definidos pelo autor da biblioteca, o que é normal dependendo do projeto e do design criado. Este risco diminui quando utilizamos frameworks, já que eles modificam as características de todos os elementos principais do projeto. Praticamente todo o código estará do framework estará sendo usado porque eles são aplicados nos elementos assim que o framework é linkado no código. Porém, com a biblioteca, é fácil mapearmos quais as classes utilizadas e excluir o código que não está sendo usado para diminuir o tamanho dos arquivos e do código.

Personalização e criação

A personalização ou criação de uma biblioteca CSS é muito mais fácil do que se resolvermos criar do zero um framework. Você consegue facilmente criar uma biblioteca de CSS contendo algumas classes úteis para qualquer projeto, por exemplo:

O código acima é um bom começo para uma biblioteca CSS personalizada. Contém ali classes básicas que se combinadas dão diferentes características para um determinado elemento. Essas classes também se mostram muito úteis se reutilizarmos no código javascript do projeto.

Sistema e Site

Design de sistemas são sempre parecidos. Todos eles tem muitos campus de formulário, checkboxes, combos, radio buttons e etc. É basicamente manipulação de formulários, alertas de erro e mensagens para o usuário, manipulação de botões de ação e etc. Não foge muito disso.
Já o design de sites são todos bem diferentes. Por isso que a manipulação visual dos frameworks se torna inútil e gera muito retrabalho.

Eu prefiro utilizar bibliotecas para a criação de sites. Para o desenvolvimento de sistemas, prefiro utilizar framworks.

Mas tenha em mente: se for decidir utilizar qualquer um dos dois, é bom que essa decisão seja feita logo no começo do projeto. Aplicar um framework no meio de um projeto pode dar muitos problemas e tomar muito tempo. Por isso é importante que essa decisão seja feita no início do projeto.

Concluindo

Entenda que um framework pode ter uma biblioteca de CSS embutida em seu core. Tendo também a possibilidade de manipular o visual dos elementos, o framework se mostra muito mais completo que uma biblioteca CSS, embora a bilioteca ganhe por ser mais fácil de personalizar e por não manipular o visual dos elementos, te deixando livre para formatar da forma que você bem entender.

Posts Relacionados

• Experiência cross-device
• Introdução ao CSS 3D – Flip Card
• OOCSS ou CSS do jeito certo
• CSS3 – Animation e regra keyframe
• CSS 3 – O valor currentColor

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.

1. Adicionar, remover ou atualizar o DOM;
2. Esconder nós do DOM usando display:none;
3. Mover e animar o DOM na página;
4. Adicionar folhas de estilo on-the-fly que mudem o comportamento dos elementos;
5. Redimensionar janelas;
6. Alterar tamanho de fontes;
7. 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.

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.

1. 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.
2. 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.
3. 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.
4. Limpe seu CSS. Classes não utilizadas devem ser removidas.
5. 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.
6. Animações na página, transições? Pondere sobre posicioná-la de maneira absoluta e trabalhar com ela a partir do BODY.
7. 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

Posts Relacionados

• Tenha o DOM
• Vote no Especialista em Usabilidade para Presidente
• jQuery: métodos desconhecidos
• Introdução aos padrões de codificação
• jQuery: dicas de otimização e performance

Ferramentas de Inspeção

Hoje a maioria dos browsers tem sua própria ferramenta de inspeção. O Firefox incorporou a Firebug, o IE tem a Developer Tool, o Chrome e o Safari tem o web inspector do próprio Webkit. O Opera usa o Dragonfly.

Com estas ferramentas você consegue facilmente encontrar o elemento, verificar o seu estilo CSS e entender qual das propriedades está causando o problema. Você consegue editar essas propriedades e ver o resultado ali mesmo.
Entenda que essas ferramentas não são utilizadas para salvar seu CSS diretamente servem apenas para fazer o trabalho investigativo.

Além de nos ajudar com HTML e CSS, os “inspectors” nos ajudam muito com debugging de Javascript. Você consegue localizar exatamente um determinado problema adicionando observer points para verificar o funcionamento de partes do script.

XRAY

O XRAY é um bookmarklet que te mostra as informações sobre um determinado elemento apenas clicando em cima dele. Você salva o bookmarklet e pronto. Clicando em qualquer elemento, você consegue informações como tamanho, nome da classe e do id, hierarquia, margens e qualquer outro estilo relacionado ao elemento.

SelectORacle

Você já deve ter visto algum seletor muito, mas muito complexo e difícil de se entender. Algo do tipo:

body > ol > li p;
:not(a);
p:not(.section);
body > h2:not(:first-of-type):not(:last-of-type);
ul li:nth-child(2n+3):not(:last-child);
ol li:nth-child(-3n+9);
ol li:nth-child(7n-3);
button:not([DISABLED]);
html|*:not(:link);

Se você parar alguns preciosos minutos você consegue entender exatamente o que cada um dos seletores quer dizer. O SelectORacle te fala em segundos o que cada um dos seletores quer dizer, explicando em poucas palavras cada uma das funções.

Validadores de HTML e CSS

Validar seu HTML e CSS não é ponto crucial para a aprovação do código pelo cliente, mas ele validar o código é muito importante para que ele não vá para a produção com erros de sintaxe. Estes erros podem causar grande parte dos erros visuais de crossbrowser. Cada browser se comporta diferente ao encontrar uma tag aberta ou colocada no lugar errado. Se o IE quebra o layout porque a tag não está fechada da forma correta, mas nos outros browsers o visual da página aparece normalmente, você logo fará um Hack para consertar o problema no IE.
Por isso é interssante que antes de incluir um CSS Hack em seu código, procure a SOLUÇÃO do problema antes de fazer um “workaround”.

O W3C disponibiliza o validador de HTML, que já está entendendo algumas coisas de HTML5. E o validador de CSS, que ainda não entende CSS3.

Posts Relacionados

• Novo parser HTML5 – FF4
• Experiência deve ter começo, meio e fim
• Ah, o maravilhoso mundo real
• Web Standards Project – WaSP
• Browsers – Guerra Fria

A sintaxe é muito simples. Na verdade, é idêntica a sintaxe existente. Segue abaixo:

div {
	width:600px;
	height:500px;
	border:1px solid black;
	background:
	url(gradiente-top.png) top left repeat-X,
	url(gradiente-baixo.png) bottom left repeat-X,
	url(gradiente-esquerda.png) top left repeat-Y,
	url(gradiente-direita.png) top right repeat-Y;
}

Veja que basta definirmos diversas vezes a propriedade URL com as imagens que escolher e pronto. Os atributos de posição e repetição continuam iguais!
É tão simples que dispensa grandes explicações. No exemplo acima usei 4 imagens em gradiente transparente. Duas para os lados e as outras duas para o topo e baixo.

Testando com o HTML

Posts Relacionados

• Introdução ao CSS 3D – Flip Card
• CSS3 – Sombras em textos e elementos
• CSS3 – Animation e regra keyframe
• CSS3 – Abas com a pseudo-classe :target
• OOCSS ou CSS do jeito certo

O HTML é a liguagem base da internet. Foi criada para ser de fácil entendimento por seres humanos e também por máquinas, como por exemplo o Google ou outros sistemas que percorrem a internet capturando informação.

Quem criou o HTML?

Tim Berners-Lee. Esse é o nome do homem que criou o HTML. Ele criou o HTML para a comunicação e disseminação de pesquisas entre ele e seu grupo de colegas. O HTML ficou bastante conhecido quando começou a ser utilizada para formar a rede pública daquela época, o que se tornaria mais tarde a internet que conhecemos hoje.

O que são as tags do HTML?

O HTML é uma linguagem baseada em marcação. Nós marcamos os elementos para mostrar quais informações a página exibe. Por exemplo, um título importante. Aquele título do artigo, da manchete do site, nós marcamos com uma tag/elemento chamado H1. Veja um exemplo:

Perceba que o texto está entre duas marcações. Essas marcações são chamadas de TAGS. As tags são abertas e depois fechadas. No exemplo acima abrimos a tag com <h1> e fechamos com </h1>. O que está dentro é o conteúdo mostrado para o usuário.

O parágrafos são marcados com a tag P. Assim:

Utilizando as tags, nós dizemos para o navegador o que é cada informação. O que é um título, o que é um parágrafo, o que é um botão, um formulário etc. Dizemos também o que é cada coisa para os sistemas de busca, como o Google. O Google, nesse caso, para exibir os resultados de busca, ele precisa saber o que é um parágrafo e o que é um título. Ele sabe disso através das tags.

A estrutura básica

Todo HTML começa do mesmo jeito. Não há segredos aqui. Você pode simplesmente copiar em algum lugar para usar esse código toda vez iniciar um novo HTML.

A primeira linha se chamada DOCTYPE. O Doctype avisa aos browsers, robôs de busca, leitores de tela e outras coisas que tipo de documento e aquele que eles estao prestes a carregar. Existem outros códigos que podemos carregar, por exemplo XML. Por isso o Doctype avisa o browser para que ele saiba como se comportar ao ler o código.

Depois começamos com a Tag HTML. Isso quer dizer que todo o que estiver entre as tags <html></html> é escrito em HTML. Ao lado da palavra HTML tem um atributo (explico o que são atributos mais pra frente) chamado lang, onde indicamos qual o idioma do texto que escreveremos.

Logo após a tag html temos a tag <head>. Na tag Head nós indicamos o título do documento e indicamos a tabela de caractéres que o browser deve usar para renderizar seu texto. Também não se preocupe com isso agora.
A tag &lttitle> é muito importante. É com ela que você indica o título do documento. O Google e outros sistemas de busca utilizam essa tag para indicar em suas buscas o título da págin. Isso é muito importante para que você apareça bem nas buscas.

Logo depois da tag de fechamento </head> começamos a tag <body>. Dentro deste elemento é que vamos escrever todo o código HTML do resto do site.

Criando seu primeiro HTML

Para criar seu HTML é muito simples. Primeiro, abra e crie um arquivo vazio, sem texto, com o nome index.html. Utilize o Notepad (se estiver no windows) ou o TextEdit (se estiver no Mac).
Perceba que a extensão do seu arquivo é .html e não .txt

Feito isso, copie o código utilizado no exemplo acima e cole neste documento. Salve e abra no seu navegador. Voilá! Você fez seu primeiro arquivo HTML

Um pouco avançado: Desenvolvimento em Camadas

Um dos principais problemas no desenvolvimento para internet é a mistura dos diversos códigos. Nós não usamos apenas o HTML para fazer sites. Além do HTML, utilizamos ainda o CSS, que é uma linguagem para configurarmos o visual das páginas e o Javascript, que vai cuidar do comportamento da página, por exemplo, o que acontece quando o usuário clica em um botão.
Há também as linguagens chamadas Linguagens Server-Side, que são linguagens como PHP, Python, Ruby, ASP e etc. Essas linguagens fazem tudo funcionar. Elas fazem os cálculos nos servidores e dão a resposta para o navegador do usuário.

Para que os códigos não se misturem, nós os separamos em diversas camadas. Para ficar mais fácil de entender, imagine que o HTML é sempre o esqueleto do site. É com ele que vamos fazer toda a estrutura de código, onde iremos dizer o que é um título, o que é um parágrafo, uma imagem e etc. O CSS será a parte externa do corpo. É o que deixará o esqueleto bonito. É com o CSS que iremos dar cor para o título, configurar o tamanho do texto, largura das colunas e etc.

Dessa forma nós não misturamos o código HTML e o código CSS. Utilizamos a mesma ideia para separar os outros códigos citados acima.

Este é o básico. É conceito puro, por que você precisa começar de algum lugar.

Mais referências:

• Quer aprender HTML? Faça aulas particulares conosco.
• Videos tutoriais sobre desenvolvimento web
• Um artigo muito completo no Wikipedia
• Sobre o desenvolvimento web em camadas.
• Áudio: Sobre marcação HTML

Posts Relacionados

• Experiência deve ter começo, meio e fim
• Biblioteca CSS ou Framework?
• CSS3 – Breve introdução ao RGBA
• Ferramentas de diagnóstico
• Novo parser HTML5 – FF4

O W3C promoveu um curso sobre HTML5 para seus membros em São Paulo. A Visie foi escolhida pelo W3C para ministrar este curso e trazer aos membros as mudanças e novas características do HTML5. Conversando com os participantes, ficou claro que com a mudança do HTML5 e CSS3, o profissional de client-side também precisa mudar. De novo.

Quando a ideia de sites tableless ganhou o mundo e o interesse de todos, houve um espécie de filtragem no mercado. Os profissionais que estavam na zona de conforto, fazendo websites com softwares WYSIWYG e digitando código sem respeitar as boas práticas, foram colocados contra a parede. Ficaram perdidos porque seus chefes mandavam que os sites fossem feitos sem as famosas tabelas. Que o código fosse feito com CSS e que o HTML fosse limpo e otimizado. Era necessário premissas de semântica fossem respeitadas e que o código tivesse uma boa performance nos sistemas de busca. Sem contar os pontos principais de acessibilidade que nunca tiveram a atenção de ninguém e que passaram a ser obrigatórios.
Muitos destes desenvolvedores decidiram esperar para ver até onde iria essa “moda” de escrever sites “sem tabela”. Outros perceberam que quanto mais demoravam para se atualizar, pior ficava. Os novatos no mercado estavam já aprendendo da maneira nova e esperar os colocavam em uma posição ruim. Este bloqueio para adotar as novas ideias eram compreensíveis: eles trabalhavam já algum tempo com uma determinada forma e de repente, sem mais nem menos, eles precisavam reaprender. Deveriam esquecer tudo o que sabiam e começar a aprender tudo de novo. De uma hora para outra sua forma de trabalhar estava totalmente errada. Foram muitas mudanças de uma vez.

Esse tempo passou e a boa notícia é que houveram sobreviventes. Entretanto, uma nova mudança está começando novamente com o advento do HTML5 e CSS3. Atualmente a maioria dos desenvolvedores client-side tem uma visão errada das suas funções. Escrever HTML e CSS é apenas uma das obrigações. Primeiro entenda que o client-side envolve tudo o que é resolvido no cliente. HTML, CSS, Javascript são as principais funções, mas há outras como performance do website, compatibilidade com aparelhos móveis e browsers do mercado. Acessibilidade. Modularização de CSS e principalmente escalabilidade.

Sim, este profissional precisa saber javascript, contudo, apenas o suficiente para controlar o comportamento dos elementos. Ele não precisa ser expert e nem precisa saber programar profundamente em JS. Ele precisa saber suficiente para fazer os comportamentos que designer definiu e resolver problemas de compatibilidade ou
limitações do CSS. Mas e aqueles papos de CANVAS, SVG e etc? Nesse caso tem uma linha muito sutil onde é difícil distinguir o client-side do programador. Você não vai fazer gráficos mirabolantes com cálculos e mais cálculos, cruzando dados e etc. Mas ele será o responsável por toda a integração entre o client e o trabalho do programador.

Com a chegada do HTML5, mais do que nunca o mercado de client-side ganhou a atenção de todos. O desenvolvedor vai ter sim que se atualizar. Quem já estava atento às mudanças, serão os novos pioneiros. Para os que estão na zona de conforto, só faltará sobreviver.

Posts Relacionados

• Experiência deve ter começo, meio e fim
• Sections: seções do HTML5 – Parte 1
• HTML5 Diff
• Ah, o maravilhoso mundo real
• Sobre Internet Explorer para Mobile – Breve impressão

serve apenas para fazer “sidebars”. Lembre-se de outros blocos para utilizamos para expor algum tipo de informação referente ao assunto principal. Isso acontece muito em livros: dependendo do livro que você estiver lendo, como um livro técnico, ele pode ter caixas de informação durante todo o fluxo de texto do livro. Essas caixas normalmente servem para chamar sua atenção para alguma informação importante ou outras informações que agregarão mais ao conteúdo principal. O elemento

fará esse papel quando se tratar de websites. Logo, tenha em mente: o elemento

agrega mais informação ao conteúdo principal.

Algumas utilidades do

: citações ou sidebars, agrupamento de publicidade, grupos e blocos de navegação e para qualquer outro conteúdo que é separado do conteúdo principal.

Dentro do

você pode agregar por exemplo grupos de elementos nav, headers, sections e etc. Isso te permite fazer um menu lateral separando os grupos de informações:

Note que não utilizamos nenhum

, pelo contrário, utilizamos apenas tags que trazem algum tipo de significado semântico. Neste exemplo, indicamos para o navegador, aplicação, sistema de busca – qualquer outra coisa que acessará nosso código – que aquele é bloco lateral, e que cada grupo de

é referente um assunto.

O elemento

pode ir também dentro de um elemento

como uma caixa de notação ou algo do genêro. Nesse caso, quando o usuário imprimir, você pode dar ênfase a esta caixa como se fosse um box de informação, como nos livros.

Posts Relacionados

• Section: elemento article – Parte 4
• Ah, o maravilhoso mundo real
• Para iniciantes: O que é HTML?
• Novo fôlego
• JQuery para produção de Layouts

A regra do CSS chamada @font-face é uma das funcionalidades que foram mais aguardadas. Ela permite que você utilize famílias de fonts fora do padrão do sistema. Veja abaixo a sintaxe:

@font-face {
     font-family: helveticaneue;
     src: url('HelveticaNeueLTStd-UltLt.otf');
}

Na primeira linha você define um nome para a font importada.
Na segunda linha, você inclue o endereço de onde a font se encontra. Para facilitar, crie uma pasta font dentro da pasta onde está o CSS.

Feito isso, você a utiliza como qualquer outra font:

p {
	font:36px helveticaneue, Arial, Tahoma, Sans-serif;
}

Suponhamos que você queira oferecer a font para os usuário que não a possuem instalada, mas para aqueles usuários que tem a font em seus sistema, o browser utiliza a cópia local do usuário:

@font-face {
     font-family: helveticaneue;
     src: local(HelveticaNeueLTStd-UltLt.otf), url(HelveticaNeueLTStd-UltLt.otf);
}

O valor local() faz com que o browser procure a font no computador do visitante antes de executar o download da que está no servidor.

Abaixo segue uma série de formatos que podem ser usados e que os browsers podem adotar:

Compatibilidade

A compatibilidade é melhor do que você pode imaginar. Mesmo assim há alguns entraves que chateiam.

As versões 7, 8 e 9 do Internet Explorer aceitam o @font-face apenas se a font for EOT. Você pode encontrar qualquer conversor online que esse problema é resolvido. Você pode converter suas fonts para EOT diretamente no Font Squirrel. O Safari, Firefox, Chrome e Opera aceitam fonts em TTF e OTF.

Veja um exemplo pronto.

Fonts pagas

O principal problema com na utilização de @font-face é que arquivo da font é disponibilizado no servidor, de forma que qualquer um tem acesso. Se você estiver utilizando uma font paga, com direitos de copyright, o download desta font pode ser ilegal e você que está disponibilizando pode ser responsabilizado. Há uma série de fonts que são grátis, estas não há problema. Mas há uma outra grande parte que são pagas. O problema é que você tem a licensa de utilizar essa font nos seus projetos, mas não tem o direito de compartilhá-la ou dar para alguém. Quando você utiliza @font-face, você praticamente disponibiliza para o mundo o arquivo da font. Qualquer um pode fazer o download. Por isso, cuidado com a font que você utiliza. Certifique-se de que ela é uma font gratuita.

Leia mais sobre @font-face direto do W3C.

Posts Relacionados

• Múltiplos backgrounds com CSS
• HTML5: Elemento AUDIO
• Propriedade background-clip
• Introdução ao CSS 3D – Flip Card
• Experiência deve ter começo, meio e fim

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posts Relacionados

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