Palestra sobre Componetização de CSS e HTML (Front in Sampa 2013)

[http://www.youtube.com/watch?v=00NrHc7Vz4g]

Saiu o vídeo oficial da minha palestra no FrontInSampa 2013, sobre componetização de HTML e CSS e a polêmica sobre orientação a objetos com CSS.

E os slides:

[slideshare id=28678434&doc=componetizacaodecsscomcompass-131127102153-phpapp02]

E você usa componetização de CSS e HTML? Que ferramentas utiliza para isso?

Customização de CSS com Compass

Trabalhar com componetização do HTML e CSS significa mais qualidade no código e muito mais produtividade no longo prazo.

Já escrevi algumas vezes aqui sobre este assunto, um dos que causaram bastante debate foi sobre CSS orientato a objetos – mais debate pela nomenclatura do que pela metodologia em si.

Este ano tive o prazer de palestrar no Front in Sampa 2013 e falei um pouco sobre componetização de HTML e CSS utilizando o Compass, uma ferramenta extraordinária que vale a pena ser estudada.

A popularização de frameworks como o Bootstrap tornaram mais fácil este tipo de metologia, pois já temos a segmentação da estrutura e trabalhar com a customização visual dos componentes fica bem mais fácil. Aproveitar este conhecimento de arquitetura de front-end destes projetos e trazer para dentro da sua empresa pode ajudar muito na produtividade da equipe.

Abaixo os slides da minha apresentação sobre este assunto:

[slideshare id=28678434&doc=componetizacaodecsscomcompass-131127102153-phpapp02]

E aí, vamos componetizar?

Palestra sobre responsive design

Este ano graças a indicação do Daniel Filho (uma das personalidades mais influentes no mercado de front-end nacional que odeia este título que o acompanha) tive a oportunidade de palestrar no Campus Party (e tinha esquecido de compartilhar isso no blog!).

Falei um pouco sobre responsive design sem mimimi, se vocês conseguirem me acompanhar correndo pelo palco perceberão que tentei abordar alguns temas que considero importante no assunto:

  • Vantagens e desvantagens do responsive design
  • Qual o impacto do responsive design para os usuários?
  • Qual o objetivo do responsive design?
  • Qual o custo do responsive design
  • Qual a melhor forma de pensar em design responsivo?

Vídeo da palestra sobre responsive design

Aqui tem o vídeo e mais abaixo os slides da apresentação.

[http://www.youtube.com/watch?v=piXlBkzrSeM]

Correções:

  • em 5:20 falei em aplicar folha de estilos para dispositivos e isso é tudo que o design responsivo não é, eu queria dizer resoluções   

Encontrou mais alguma canelada? Comenta aí para eu atualizar o post.

Slide sobre responsive design

[slideshare id=16342889&doc=responsivedesign-130204092612-phpapp01]

Gostou? Compartilhe!

3 Dicas de performance de CSS

O primeiro passo para se discutir a performance da renderização das páginas no navegador é entender como o navegador funciona.

Antes de continuar você deve entender os conceitos de browser reflow e browser repaint, pois nosso objetivo para ter uma página renderizada mais rapidamente é a redução dos reflows e repaints da página.

Como o navegador interpreta o CSS?

O navegador começa a leitura do CSS da direita para a esquerda, do nosso último elemento para o primeiro. Ele pega o seletor bem da direita, percorre todos os elementos do DOM que casem com este seletor e passar para o próximo seletor a esquerda, verificando os parents do seletor que ele verificou anteriormente (o bem da direita na sua linha de seletores).

Parece confuso mas na prática é simples. Para o código abaixo, por exemplo:

#content #menu ul li a

O navegador vai varrer todos os elementos "a" da sua página, depois ele vai verificar quais destes elementos estão dentro de um elemento li e assim por diante até encontrar o elemento #content.

Agora que você já sabe como o navegador trabalha vamos as dicas de CSS para páginas rápidas!

 

1. Escreva seletores curtos

Agora que você já sabe como o navegador percorre o seu seletor, já sabe quanto mais curto ele for menos será o caminho percorrido e consequentemente mais rápida a renderização da sua página.

Evite

#content nav#menu ul li a

 

Melhor performance CSS

.menu-item

 

Outro exemplo, em uma página com bastante conteúdo tabular:

Evite

table thead tr td

 

Melhor performance CSS

.header-table

 

2. Prefira classes e ids do que seletor por elemento

Quanto mais preciso seu seletor for menos elementos do DOM serão percorridos pelo browser, o seletor de tag tende a ser mais abrangente do que seletor de classe.

Evite 

h2.product-title

Melhor performance CSS

.product-title

 

Evite

nav#menu

Melhor performance

#menu

O navegador não precisa fazer 2 verificações para estilizar os elementos casados com a classe.

 

3. Evite seletor universal, por atributo e pseudo-selectors

Principalmente no IE evite os pseudo seletores como :hover, :nth-child e outros. O seletor universal percorre todos os elementos do DOM (por isso a baixa performance) e os pseudo seletores tem uma performance bem inferior do que qualquer seletor por classe ou id, então sempre que for possível evite seu uso.

Evite:

input[type="text"]

Não tão ruim:

input.texto

Melhor performance CSS:

.input-texto

 

Dica bônus: não enlouqueça

Não seja um paranóico, não deixe que as preocupações com performance de CSS prejudiquem (muito) a organização e leitura do seu código.

Se você trabalha em projetos com uma equipe grande em que todos estão acostumados a escrever seletores descritivos (e compridos) para facilitar o entendimento do código pode ser um pouco complicado fazer esta mudança, uma boa dica é estimular comentários no CSS – qualquer processo de minify arrancará os comentários e manterá o código enxuto.

 

Para saber mais sobre performance no front-end veja este post sobre performance de javascript e o recente post do Chris sobre manipulação do DOM de forma mais performática.

Se está na dúvida (ou não acredita no que escrevi), utiliza esta ferramenta para testar a performance de seletores CSS.

 

Referências:

Melhorando a performance do CSS

Escrevendo CSS eficiente

Google best pratices rendering

Mozilla – Writting effective CSS

Simplifying CSS selectors

Como escrever um bom HTML em 3 passos

Como muitos de vocês sabem estou em uma empreitada maluca não só para me tornar um Jedi em PHP mas também para ter um bom domínio em uma ferramenta que não é um sabre de luz mas chega perto: o Code Igniter.

Para isso estou fazendo o que todo desenvolvedor adora fazer em suas folgas: devorando documentação e passando algumas madrugadas fazendo testes.

Entre os estudos entrou o desenvolvimento do And After todinho baseado no Code Igniter – e é bastante coisa. Cheguei na vez de portar O Desenvolvedor para o CI, e no meio do caminho resolvi aproveitar para reestruturar o html (que está super sujo, podem conferir) e aplicar alguns conhecimentos que adquiri desde a criação do blog: otimização do CSS, performance do javascript e o badalado html5.

 

Como escrever um bom HTML?

Resolvi refazer todo o HTML (e CSS) deste blog durante a migração para PHP. O código estava sujo (várias implementações "puxadinhos" foram feitas depois de pronto) e seria mais produtivo refazer tudo para transformar em template ao invés de tentar aproveitar alguma coisa (e posteriormente melhorar o código).

Em pouco mais de uma hora a estrutura estava montada com os novos elementos do HTML5 (sections, articles, navs, asides) e eu estava terminando também a base de CSS, com especificações da estrutura e visual do blog.

Considero minha produtividade para montar um html é razoavelmente boa, mas confesso que ontem me surpreendi, fui procurar o motivo da produtividade e reparei como mudei minha forma de desenvolver ao longo do tempo.

Abaixo algumas dicas que consegui listar como as razões para atualmente eu conseguir desenvolver de forma muito mais eficiente e com um código muito melhor os htmls.

 

#1 Conheça o CSS – escreva menos

Não adianta, se você sabe o que é possível fazer com uma linguagem (CSS) você não precisa ficar quebrando a cabeça e sujando o código com workarrounds. Então minha primeira dica é estudar CSS: saber o que é possível fazer, o que faz cada propriedade, valores permitidos, etc.

Meu maior aumento de produtividade relacionado ao CSS se deve ao fato de atualmente aproveitar ao máximo o que o CSS se propõe a fazer: estilos em cascata.

Criei dois exemplos do mesmo código para ilustrar isso, estão bem simples mas acho que conseguem mostrar como é possível escrever mais rápido se pensar antes na estrutura do HTML e reduzir as classes e elementos do código.

Exemplo de código "sobrecarregado" com classes:

 <ul class="comments">
    <li class="comment_odd">
        <img class="thumb" src="src" alt="avatar" />
        <span class="author">Name</span> - <span class="date">dd-mm-yyy</span>
        <div class="comment">
            Comment
        </div>
    </li>
    <li class="comment">
        <img class="thumb" src="src" alt="avatar" />
        <span class="author">Name</span> - <span class="date">dd-mm-yyy</span>
        <div class="comment">
            Comment
        </div>
    </li>
</ul>

CSS
ul.comments{
    padding: 10px;
}
li.comment_odd, li.comment{
    padding: 10px;
    border bottom: 1px solid #333;
    margin-bottom: 5px;
}
li.comment_odd{
    background: #efefef;
}
ul.comments img.thumb{
    float: left;
    margin: 0 10px 5px 0;
    border: 1px solid #ccc;
}
ul.comments li .comment{
    color: #666;
    font-size: 1.1em;
}

 

E agora um bloco de código com a mesma função porém com um html mais limpo e um css aproveitando as heranças de estilo.

<ul class="comments">
    <li class="odd">
        <img src="src" alt="avatar" />
        <span class="author">Name</span> - <span class="date">dd-mm-yyy</span>
        <div>
            Comment
        </div>
    </li>
    <li>
        <img src="src" alt="avatar" />
        <span class="author">Name</span> - <time>dd-mm-yyy</time>
        <div>
            Comment
        </div>
    </li>
</ul>

CSS
ul.comments{
    padding: 10px;
}
    ul.comments li{
        padding: 10px;
        border bottom: 1px solid #333;
        margin-bottom: 5px;
    }
    ul.comments li.odd{
        background: #efefef
    }
        ul.comments li img{
            float: left;
            margin: 0 10px 5px 0;
            border: 1px solid #ccc;
        }
        ul.comments li div{
            color: #666;
            font-size: 1.1em;
        }

 

Neste curto exemplo as otimizações não são tão visíveis no CSS (por ser poucos elementos e classes) mas em alguns layouts um pouco mais complexos a diferença é muito perceptível. É possível "economizar" o uso de várias classes (mudei inclusive uma tag, para o time do html).

 Algumas coisas que devem ser utilizadas:

  • Usar CSS sprite sempre que possível
  • Evitar o abuso de classes
  • Backgrounds podem retirar várias imagens do seu HTML, mas analise do ponto de vista do conteúdo: a imagem faz parte do conteúdo ou do layout?

#2 Semântica – escreva direito

Antes eu montava um html pensando no layout da página: como posicionar os elementos (e já era tableless, só quem viveu lembra do tempo das tables dentro de tables), espaçamentos, backgrounds… hoje em dia eu digo: não faça o html pensando no layout, faça pensando no conteúdo.

Este item pode parecer contraditório ao primeiro, mas na verdade são complementares. Você precisa saber como é o layout pois certamente isto influencia algumas coisas no HTML, mas você deve guiar sua estrutuar ao conteúdo e não ao layout.

Olhe o seu layout, pense em como será a estrutura da sua página, olhe o conteúdo e pense quais tags se encaixam para cada área. Com o HTML5 está rolando debates intensos sobre o uso de articles ou sections, então é melhor pensar antes de começar a escrever… 🙂

Outra dica para isso ficar melhor é na hora de escrever o html não desenvolver o CSS, no início isso causava improdutividade pois eu demorava mais para adaptar o CSS depois, hoje isso aumenta minha produtividade pois apesar de não escrever o CSS já vou matutando como ele será, e isso vai mudando conforme escrevo. Quando transformar o conteúdo HTML no layout, o CSS já está pensado e revisado! 😀

Esta segunda basicamente diz: a web é semântica e o HTML é conteúdo, CSS é layout.

 

#3 Otimize

Eu acredito que quase todo o código pode ser otimizado, utilizando estas técnicas eu gosto muito do resultado final – mas depois de pronto acabo percebendo que algumas coisas poderiam ser melhoradas.

Nesta última etapa incluo também o desenvolvimento do javascript (leia: javascript: extreme performance) que com a popularização da banda larga a interface (renderização do HTML e código javascript) representa uma porcentagem muito maior da espera do usuário para ver a página.

Depois de tudo pronto "leia" seu código, veja se pode otimizar, reduzir seu CSS, minimizar o número de requisições (evitar muitos .js e .css separados, usar CSS Sprite, transformar backgrounds que usam imagens em cores/css3, etc).

 

Estas são três regras que eu procuro seguir sempre que vou desenvolver um HTML, quais são as dicas/críticas de vocês?

Comentem que eu atualizo o post ou faço uma nova lista baseado nas sugestões! 🙂