Webpoint

Bem, a abreviação do CSS já diz tudo sobre sua arquitetura. Ela funciona em cascata. Novidade para uns, obsoleto para outros, mas que quando aplicado da maneira correta, pode te ajudar em muito na leitura do CSS. Bem, o usuário final não vai ver o resultado, mas para desenvolvedores web que se prezem, não importa apenas o resultado final. Como ele foi atigindo também é relevante. Como já disse anteriormente, mesmo sendo uma linguagem de design, o CSS tem várias metodologias e truques por trás da manga.

Você vai entender melhor do que estou falando, irá diferenciar este post de uma weblosofia que não tem prática. Vamos supor que você quer estilizar um campo de formulário e assim você atribuiu uma classe para ele com o nome de campo. Como já mostrei no post hover em campos com o jQuery, você pode colocar outra classe que irá representar o estado hover do elemento, pois como já discuti antes, o IE6 suporta o hover apenas em links.

Assim, ele poderia ser estilizado da seguinte maneira:

.campo {
font-size: 18px;
color: gray;background-color: #DDDDDD;
border: 1px solid #A19A9A;
 
}
 
.campo_focus {
 
font-size: 18px;
color: gray;
border: 1px solid #E64D4D;
background-color: #DBCDCD;
 
}

No campo focus ele muda a cor de fundo e a borda, mas permanece com a fonte 18px. A fonte está especificada por que é diferente das demais, caso contrário ela seria especificada no body, no html ou com o símbolo asterisco que representa todos elementos. Olha o efeito em cascata evidente, pois a classe campo e campo_focus herdaria o tamanho da fonte de qualquer elemento ancestral a ele. Sim, pode considerar o documento como um pai cheio de filhos e que tem mais filhos, ou como uma árvore, pois uma família pode ser representada também por uma árvore. Não importa como você pensa, desde que você tenha isto em mente. Sendo assim, podemos reescrever este css desta maneira:

.campo, .campo_focus {
font-size: 18px;
color: gray;
background-color: #DDDDDD;
border: 1px solid #A19A9A;
}
 
.campo_focus {
border: 1px solid #E64D4D;
background-color: #DBCDCD;
}

Desta vez eu especifiquei o campo e no campo_focus suas propriedades em comum e as que irão ficar somente na classe campo estão declaradas. A segunda vai ter as propriedades diferentes e vai prevalecer no campo_focus as declarações que você colocou por último, obedecendo a herança. Assim, se você mudar o tamanho da fonte, basta apenas mudar em um local. Se não ficou evidente a diferença, vou ilustrar um exemplo mais complexo.

Imagina que você está colocando em um menu um fundo diferente para cada item e que este menu esteja como uma lista não ordenada. Pois bem, haverá várias declarações nos elementos li, mas neste li você terá que colocar um id para diferenciar dos demais para assim no css para cada id tem um background. Então você deve aplicar a frase anterior literalmente: "cada id tem um background", ou seja, a única coisa que diferencia-os é o background, portanto, todos as outras propiedades comuns devem ser declaradas no li e somente o background deve ser declarado em cada id. Isto evita redundância e melhora a hierarquia do seu CSS.

Estava com um layout para programar que a idéia era não ter espaço no topo, ou seja, teoricamente uma margem no topo com o valor de zero. Sendo assim, apliquei um margin: 0 no elemento body. No IE6 e 7 funcionou como esperado, mas no Opera e no Firefox ficou ainda um espaçamento no topo. Por que isso ocorre?

No Internet Explorer há elementos que por padrão tem uma propriedade chamada on having layout (tem layout) . Existe também um artigo desse do Maujor em português. Este assunto é muito amplo e pretendo postar um artigo exclusivamente para isto, mas uma lida neste artigo do Maujor já diz tudo. Entenda por enquanto que isto acontece por causa deste comportamento do IE, que não segue os padrões, possuindo uma própria maneira de tratar o layout.

O que importa, a solução!

Há várias soluções, mas há uma que achei bastante interessante pois me levou a usá-la para várias situações. Há um seletor * que especifica todos os elementos. Se você fizer algo do tipo:

* {  margin: 0;
 
padding: 0;
 
}

Não haverá margem e padding no topo, nos lados e abaixo do elemento body. O problema é que isto será aplicado a todos elementos. Todos sem exceção, pois este seletor serve justamente para este fim. Sendo assim, parágrafos, divs, inputs, uls ficarão com uma margin e um padding com o valor de zero.

Depois que isto aconteceu, comecei a perceber que no decorrer do desenvolvimento da diagramação html / css ocorreu menos diferenças entre o IE e o Firefox. O fato é que você colocando o padding e margin para zero torna-se o padrão da página e assim não haverá diferença destas duas propriedades. Resumindo: se um elemento ul, por exemplo, não tem uma margem especificada, esta margem será o padrão do browser, que é diferente para cada um. Você usando esta propriedade você "iguala" os browsers nesta propriedade. Então para dar uma margem em qualquer elemento, é só especificar que ele será o resultado final.

Além disto, você pode também usá-lo para colocar outras propriedades padrões. Por exemplo, em quase todo site eu costumo especificar o height para auto, então por que não colocar como propriedade do elemento asterisco? Assim quando surgir um elemento com um height diferente, simplesmente eu especifico, se não vai ficar como auto.

Há sempre uma dica quando você valida o código na W3C. Estes dias eu li um que foi muito útil. Basicamente ele dizia:

Muitas pessoas usam nome de classes como textoazul ou bordavermelha. A melhor maneira de nomear suas classes é pela sua função no html que ela está inserida

Se você colocar um nome da classe bordaVermelha e essa borda ficar azul? Ou seja, a aparência pode sempre mudar, mas a função que a classe representa não. Então é sempe uma boa prática nomear classes de acordo com sua função ou contexto e não com suas características. Já me deparei com esses nomes, mas realmente é um hábito ruim de programação CSS. Abaixo, vai as dicas da W3C de nomes bons e ruins:

Nomes bons

• warning
• important
• download_imagem

Nomes ruins

• fundo_azul
• borda_verde
• lista_bonita

Isto não vai prejudicar a apresentação final, mas com certeza é um bom hábito e uma boa prática para se ter um código mais bem lido e com uma melhor manutenção.