Deixando uma imagem como se fosse um selo por CSS

Vou reproduzir uma técnica que vi outro dia sobre como deixar uma imagem parecida com um selo, com aquela borda picotada.

É simples, e a própria explicação do que vamos fazer hjá demonstra o que vamos manipular: a borda do elemento CSS.

Como você faria para criar uma marcação html dessa forma?

Poderia ser criada uma imagem, mas e se você precisar alterar a imagem e o texto várias vezes?

Com o código abaixo, fica fácil; basicamente, deve-se colocar a imagem como background de uma div, e essa div com borda tracejada. O valor ali de cima, fica dentro de um <p>

<div class="stamp">
 <p>99&cent;</p>
</div>
.stamp {
    width: 500px;
    height: 414px;
    background: #fff url(george.jpg) no-repeat;
    border: 12px dashed #1b1a19; }
.stamp p {
    color: #fff;
    margin: 10px 10px 0 0;
    font: bold 60px Georgia, "Times New Roman", Times, serif;
    text-align: right; }

Pronto!

CSS Orientado a Objetos

Mesmo sabendo que o Chris vai falar algumas coisa relacionada ao termo "orientado a objetos", achei o conceito de otimizar e "orientar" o CSS bem interessante.

Na semana passada estava conversando sobre CSS aqui no serviço, debatendo o que era melhor:

Opção 1 – Uma classe por elemento

Ao meu ver, este é o modo mais simples de "pensar" CSS. Você pensa na estrutura html do seu site a para cada elemento cria uma classe, quando o elemento se repete você usa a mesma classe.

Por exemplo, você tem um quadro (div) com o topo azul, bordas cinza e área para conteúdo com background branco.

Seu CSS seria:

.quadro_azul{
border: 1px solid #ccc;
background: #fff;
padding: 6px;
}

.quadro_azul h6{
display: block;
background: blue;
}

 

Para criar um quadro com o header vermelho você precisar duplicar o código do CSS, facilita a vida para atualizar um elemento específico porém dificulta para fazer alterações gerais, como mudar o layout.

Esse método também torna o código mais sujo (e o html levemente mais limpo).

 

 

Opção 2 – Classes comuns para diversos objetos

Para mim ainda é um pouco complicado pensar desta forma, uma coisa que temos que ter na cabeça antes de pensar nisso é: um elemento do html pode ter várias classes. Repitam isso.

No mesmo exemplo anterior, você teria um estilo para delimitar TODOS os quadros, por exemplo:

.quadro {
border: 1px solid #ccc;
background: #fff;
padding: 6px;
}
 

 E para setar as outras propriedades, como a cr do cabeçalho definiria classes para isso.

h6 .azul{
display:block;
background:blue;
}

Ou ainda mais amplo:

.azul{background:blue;}

.block{display:block;}

Claro que neste caso não faz muito sentido, porque estamos criando classe para setar uma única propriedade, um "desperdício" de classe por assim dizer.

Mas neste caso utilizamos na div a classe "quadro e no cabeçalho (h6) as classes azul e block.

<h6 class="azul block">Header do quadro</h6>

 

 

O que é melhor?

Eu ainda não tenho uma opinião formada sobre qual o melhor caminho a seguir, mas neste momento eu recomendaria o budismo: "siga o caminho do meio".

Ter centenas de classes definindo propriedades vai só complicar a vida do desenvovledor em possíveis manutenções. O CSS vai dicar extenso, montar o html também pois você terá que chamar diversas classes para cada objeto.

Ter uma classe para cada objeto também pode não ser benéfico, a cada nova página você provavelmente vai ter que criar uma nova classe, aumentnado seu CSS sem um bom reaproveitamento de código.

Em ambos, lá se vai a facilidade para alterar layout de um modo REALMENTE rápido.

 

Graças ao Twitter (saiba o que é o Twitter e como usá-lo) visitei um link que me chamou a atenção, com uma possível buzzword: CSS Orientado a Objetos.

Apesar do nome mimimi, a idéia é realmente interessante. A herança poderia ser bem útil no CSS, mas como o nome diz a "cascata" existe, pensando direito dá para aproveitá-la bem.

Bom, veja a apresentação em slides do conceito, abaixo continuo meus pitacos sobre essas práticas!

 

Uma coisa que não costumo fazer e tenho certeza que é muito útil é a separação no CSS da estrutura (posicionamento de colunas, menu, header, footer, ad, etc…) da visualização (backgrounds, fontes, bordas, etc.).

Isso facilita a alteração de layout (visual e estrutural) e somado com o reaproveitamento de classes para diversos elementos, a redução do número de classes para elementos bastante similares e outras boas técnicas pode reduzir bastante seu CSS e facilitar o trabalho em equipe!

O que vocês acham da idéia, do nome e da apresentação?

Resetando o CSS

Acho que um dos maiores concensos dentro do desenvolvimento de interfaces para web é resetar o CSS padrão antes do início do desenvolvimento.

Isso porque cada browser tem os seus próprios valores padrão para margens, paddings, bordas, etc… dos elementos do CSS.

Todo mundo tem o seu método de fazer isso. Eu, há algum tempo, uso uma folha de estilos separada – normalmente chamada reset.css – com o código abaixo, e a chamo como primeiro include nos htmls:

 

 

*{outline-color:invert;outline-style:none;outline-width:medium;}
html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre,a, abbr, acronym, address, big, cite, code,
del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, dl, dt, dd, ol, ul, li,fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
    margin: 0; padding: 0; border: 0; outline: 0; font-weight: normal; font-style: inherit; font-size: inherit;
    font-family: inherit; vertical-align: baseline;
}
:focus {outline: 0; }
body {line-height: 1; color: black; background: white; font-size:100.01%;}
ol, ul { list-style: none;}
table { border-collapse: separate; border-spacing: 0;}
caption, th, td { text-align: left; font-weight: normal;}
blockquote:before, blockquote:after,
q:before, q:after {content: "";}
blockquote, q {quotes: "" "";}
strong{ font-weight: bold; }
body,input,select,textarea {  font-size: inherit; }

 

clearfix – solução css para elementos float

Vai uma dica rápida de CSS para uma questão que acontece no Firefox: quando você tem dentro de um elemento block (uma div, por exemplo) outro elemento com float, esse elemento que flutua não força automaticamente a altura do elemento container; ou seja, ele não empurra a borda inferior para baixo.
Isso acontece porque nesse momento o elemento que está flutuando deixa de ter o container como pai dele.
O que se faz mais comumente por aí é colocar um elemento com clear:both antes do final do elemento container; o clear:both força que a borda inferior vá para baixo.
O ruim dessa técnica é que o seu html fica sujo, com um elemento a mais, como pode ser visto aqui:

<div>
    <div style="float:left; width:30%;">Algum conteúdo</div>
    <p>Texto que não flutua</p>
    <div style="clear:both;"></div>
</div>

Uma outra técnica, mais bonita, é fazer isso por CSS. Há tempos foi encontrada uma solução que se popularizou chamada de clearfix
Ela é uma classe CSS, como pode ser vista abaixo, que deve ser adicionada ao elemento container:

.clearfix:after {
    content:".";
    display:block;
    height:0;
    clear:both;
    visibility: hidden;
}
.clearfix {display:inline;}
* html .clearfix {height: 1%;}
.clearfix {display: block;}

É usada essa propriedade :after para inserir um conteúdo via CSS no final do elemento que recebe essa classe. Nesse caso, é inserido um texto blocado e invisível. O elemento block, por si só, já é um elemento com clear:both.
As outras 3 linhas do código são para que o código de cima não afete os demais browsers.

<div class="clearfix">
    <div style="float:left; width:30%;">Algum conteúdo</div>
    <p>Texto que não flutua</p>
</div>

[WARNING] se você é um fanático por validação de código nos engines do W3C, nem precisa testar esse aqui, que ele não passa mesmo. Mais explicações aqui, ó, bem como um texto mais explicadinho sobre toda essa solução.[/WARNING]

 

Diminuindo o consumo de banda com html, css e javascript

Estava eu ontem, todo *feliz*, analisando as estatísticas de acesso de uns sites feitos (e hospedados) na empresa pra qual trabalho. Bacana, vendo acessos de browsers, horas de pico, resolução de tela, tráfego de arquivos e…
Perae! 45% do tráfego mensal era de javascript. Num site sem absolutamente nada de ajax ou efeitos ou coisas do gênero.
Encafifei: o quê estaria acontecendo?

Simples: esqueceram de ligar o filtro de compressão gzip para arquivos css/javascript.

Vejo por aí que muita gente não conhece isso, e fica proecupado em tirar todos os tabs e espaços dos arquivos html, css e javascript. Usa aqueles aplicativos que diminuem o código javascript, colocando tudo na mesma linha. E acabam com qualquer tabulação no CSS.
Tudo isso era válido 5 anos atrás. Hoje em dia, existe uma forma mais adequada de fazer diminuir o consumo de banda quando arquivos desse gênero são requisitados.

Explicando como os browsers funcionam: ao fazer uma solicitação de um URL, quando essa chega no servidor de destino, a primeira coisa a acontecer é passar pelo webserver. Esse cara tenta pegar os arquivos requisitados (html, imagens, css, js, etc…) e, em caso de sucesso (status 200) devolve pra quem os requisitou.
*isso tudo é uma simplificação beeem simplificada do fluxo, conforme pode-se ver no diagrama abaixo:

 
Bem, um novo passo nesse fluxo foi adicionado com a evolução tanto dos browsers, quanto dos webservers quanto do protocolo HTTP.
Os browsers hoje em dia, bem como o webserver, têm a capacidade de comprimir e descomprimir dados usando o gzip (como se fosse um .zip). Quando o browser faz uma solicitação de uma URL, ele manda um header com dados referentes à solicitação e a ele mesmo (qual a versão, tipo, etc…). Com isso, o webserver consegue saber se esse browser suporta compressão de arquivos. Se o webserver estiver configurado, ele pode fazer a compressão de arquivos html, css, js, ou de qualquer outro formato de arquivo.

 

Fazendo testes aqui, a diferença de tamanho de arquivo para html/css/js chegou a 90% em alguns casos. Imagine que se você usa algum framework js (a jQuery tem uns 100kB, a Prototype está com 120), a cada requisição de um usuário que não está com esses arquivos no cachê pode ser de 90kB – okey, vamos arredondar para 80kB. Se 100 pessoas acessam por dia, dá 8mB; ou, 240mB por mês.
Agora, imagine num site com milhares de pageviews…

Na net, existem muitos links explicando como configurar o seu webserver (ISS, Apache) para cada tipo de arquivo, como esses aqui:

Compressão de html com o Apache: http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/
Compressão de CSS/js com o Apache: http://blog.joshuaeichorn.com/archives/2007/01/10/compressing-javascript-and-css/
Verificar a taxa de compressão: http://www.gidnetwork.com/tools/gzip-test.php

Enjoy 😉