Tableless - Desenvolvimento inteligente com Padrões Web

09/11/2008
Artigos

Não “otimize” seu código

Quando fazíamos sites com tabelas, o grande problema era a quantidade de código que escrevíamos. Naquele tempo – 1996, 97, 98 – tínhamos outros pontos que precisavam de uma atenção maior. A conexão era lerda para todo mundo e isso …

Por


Quando fazíamos sites com tabelas, o grande problema era a quantidade de código que escrevíamos. Naquele tempo – 1996, 97, 98 – tínhamos outros pontos que precisavam de uma atenção maior. A conexão era lerda para todo mundo e isso dificultava um bocado as coisas. Por isso, fazer um site pesado era fora de cogitação. Ficávamos “mendigando” cada byte para que o site ficasse milésimos de segundo mais rápido.

O código era o grande problema. A quantidade de código interferia diretamente na performance do site. E isso fez com que os desenvolvedores encontrassem saídas não muito agradáveis.

Era comum fazer códigos como o de baixo:

Produto Preço
Tênis R$230

Se transformarem em verdadeiros monstros:

Produto Preço
Tênis R$230

Isso tudo para economizar alguns bytes, que dependendo do site, significavam teras e teras de banda por mês. Naquele tempo, fazer isso era totalmente justificável. Precisávamos de alguma forma diminuir esse código para que o site ficasse mais rápido para o usuário e as requisições não sobrecarregassem o servidor.

Hoje isso é totalmente dispensável.

Aprendemos a utilizar o CSS e sabemos escrever HTML semântico.
A utilização dos Padrões trazem uma série de vantagens, e uma grande parte dessas vantagens são por causa da diminuição do código. Com o desenvolvimento de camadas e principalmente por causa do uso do CSS, não precisamos mais “otimizar” o código.

Mas parece que os desenvolvedores gostam de coisas complicadas. Esse mal costume de otimização de código ainda existe, e hoje querem otimizar o CSS. Eu acho totalmente inútil. O CSS foi feito para controlar o visual do site inteiro. Ele tirou a responsabilidade de formatação que colocávamos no HTML. Seu trabalho é exclusivamente esse: controlar o visual e diagramação do site.
É normal ele ficar grande, enorme, bizarro! Sim, haverão alguns casos que o tamanho superará mais de 1000, 2000, 3000, 4000 linhas.
Dá para evitar? Claro que dá! Pense simples. Module os arquivos. Faça um planejamento. Mas NUNCA faça com que um CSS escrito assim:

div {
 padding: 10px;
 border: 1px solid #CCC;
 width: 485px;
 height: 37px;
 background: #EEE;
}

Fique assim:

div{padding:10px;border:1px solid #CCC;width:485px;height:37px;background:#EEE}

Tenha dó do seu próximo e tenha dó de você mesmo.

Se você escreve o código de acordo com os Padrões, já economizou código suficiente. Não prejudique a manutenção do site por conta dessa neura. Escreva código legível!

Há outro ponto que devemos levar em consideração: imagine que o site pese 40Kb. Estes 40Kb são compostos por 20Kb de CSS e 20Kb de HTML. O CSS tem uma característica interessante: ele é cacheado pelo browser quando visitante entra no site.
Na primeira visita do usuário ele baixará 40Kb de uma vez. Já na segunda visita ele baixará apenas 20Kb relativos ao HTML. Ele não precisará baixar os 20Kb de CSS porque o arquivo já está cacheado pelo browser.

Não “otimize” seu código CSS, nem seu código HTML. Faça apenas com Padrões Web e siga categoricamente a semântica. É a melhor otimização que você pode conseguir.

O Leonardo Caineli escreveu um artigo sobre isso. Claro, discordo da opinião dele.

[update]Depois do post o pessoal chamou a atenção para essa prática em empresas grandes. Notei que no post eu não falei nada sobre isso. Sim, concordo que essa prática, só nessa hipótese, é totalmente considerável.

Quando treinei a primeira equipe do Terra – da época do site laranjão, lembra-se? – a primeira coisa que eles fizeram foi converter a home, e eles ainda sim queriam colocar todo o CSS em apenas uma linha.

Realmente 1Kb multiplicado por milhões é coisa para caramba e não há banda que agüente. Por isso, é totalmente aceitável que sites com um porte muito grande, “otimizem” seu código. [/update]

Por Diego Eis

Diego Eis criou o Tableless para disseminar os padrões web no Brasil. Como consultor já treinou equipes de empresas como Nokia, Globo.com, Yahoo! e iG. É palestrante e empreendedor.

http://twitter.com/diegoeis/

Veja os outros posts de

  • http://carlossoler.net Carlos Soler

    Galera!

    Conheço programadores ótimos que fazem CSS dos 2 jeitos! Não existe certo ou errado, cada pessoa está acostumada a organizar o código de uma maneira.

    Eu acho que o Diego deveria ter deixado claro que esse é o jeito que ele programa e recomenda, mas não que seja o único jeito e a maneira correta de se fazer.

    Abraço!

  • http://leonardocaineli.com.br/ Leonardo Caineli

    Opiniões divididas é um ótimo sinal de que este post não está com a razão. A internet avança rápido demais, se não nos acostumarmos com novos padrões ficaremos estagnados no mercado. Acredito que todos aqui querem trabalhar (ou já trabalharam) em grandes projetos, e esta é a realidade hoje: páginas rápidas = economia de banda = retorno de R$ para as empresas. Para os que ainda têm dúvidas, seguem alguns CSS´s que a maioria de vocês deve acessar:

    globo.com.br:
    http://www.globo.com/Portal/cda/estilo_css_cda/0,,6637-0-1795980775,00.css

    uol.com.br (CSS embedded):
    http://www.uol.com.br/

    ig.com.br:
    http://images.ig.com.br/homeigv25/home_v081106a.css

    terra.com.br (6 requests):
    http://www.terra.com.br/capa/css/estrutura_olimp_26.css
    http://www.terra.com.br/capa/css/moduloComunidades2.css
    http://www.terra.com.br/capa/css/css_videos_olimp_26.css
    http://www.terra.com.br/capa/css/css_noticias_olimp_26.css
    http://www.terra.com.br/capa/css/css_abinhas_olimp_26.css
    http://www.terra.com.br/capa/css/css_olimp_26.css

    Para fechar, faço questão de postar a url do CSS do meu blog para comprovar que otimização e organização podem sim andar de mãos dadas:
    http://leonardocaineli.com.br/wp-content/themes/leonardocaineli/style.css

    Longe de mim ditar como cada um de vocês deve programar, mas o mínimo que posso fazer é comprovar o que postei mostrando claramente a realidade de hoje. Fico muito feliz que a grande maioria pensa e/ou adota as mesmas idéias.

    Abraços!

  • http://paulojean.com Paulo Jean (“Millhouse”)

    Olá galera!
    Legal o post Diego, em relação a otimização ao longo do tempo se torna automático para o desenvolvedor o ideal que eu acho que ele sempre reveja seus trabalhos antigos, quando ele tiver tempo e pense em soluções mais cabíveis e sempre tentar montar sua própria library já pensando em uma organização pq ai realmente vc começa a caminhar para os padrões.

    O que falta para muitas pessoas é um conhecimento de como pode ser feito pq por um lado vc pode ter ganhado quando faz o css em inline como também vc tem percas em relação a fazer uma manutenção seria complicado. Eu já trabalhei com as duas formas. E acho muito mais simples fazer ele como bloco não como linha. Mais creio que isso é preferencial de cada um.
    Quando se fala em padrões, é difícil universalizar uma única forma de desenvolver sites, mais é fácil programar e pensar em novas estruturas e boas práticas para uma manutenção e criação de sites rápidos, leves e validados.
    Já que esse é um dos fatores primordiais para começarmos a pensar em padrões universais.
    Bem essa é minha opinião.
    Abraços.

  • http://www.presencaonline.com.br/blog Rhamsés Soares

    É Muito legal usar um script para otimizar o código CSS. Mas para elaborar ou até mesmo publicar, eu também só coloco em uma linha quando tem uma propiedade apenas. Visualmente é bem melhor, ninguem sofrerá quando for atualizar o seu arquivo.

  • http://blog.lppjunior.com Luiz Paulo

    Pessoal,
    Acho que o Diego está certo falando sobre o código em uma única linha, realmente é horrível manter.

    Sobre compactação, vocês já ouviram falar em GZIP?

    Esse cara compacta o arquivo antes de envia-lo para o browser e resolve o problema.

    Nunca utilizei esse recurso nas plataformas (PHP, Ruby, etc). Não sei o quanto trabalhoso seria, mas em JAVA é tão simples quanto uma biblioteca e 1 linha de configuração.

    []‘s

  • http://blog.lppjunior.com Luiz Paulo

    Esqueci de falar, GZip funciona em todos os browsers :)

  • http://www.ederprado.com Eer

    Pra quem conhece as ferramentas de edição de CSS sabe que esse post é quase que indiferente, uma vez que se o código estiver todo em uma linha, o programa de edição pode organizá-lo de forma “identada”! :P

    Já peguei códigos assim pra editar e nunca morri por causa disso, é só mandar o programar organizar o código.

    Discussão bem vazia!

  • http://www.brunodulcetti.com/blog Bruno Dulcetti

    só pra causar uma discórdia diego. eu penso assim também, principalmente quando um site é pequeno e tudo mais.

    mas eu ainda acho que em sites grandes (grandes MESMO), como portais da globo.com, videolog, que foram projetos em que participei, tornar o código em uma linha traz um ganho absurdo. só participando para saber.

    e lógico que ainda passam um gzip, e mesmo assim, o ganho tirando espaços, tabs, entre outros são absurdos. no videolog eu lembro que o ganho foi de uns 20kb ou mais. e isso pra mim é um número considerável.

    mas concordo que para ler é mais difícil, mas tudo é questão de costume ;)

  • Mark de Souza Costa

    Eu sou totalmente contra esse “code in line”. O ganho é insignificante, mesmo os 20kb falado do nosso colega Bruno não demoraria mais de 4 segundos para carregar numa conexão discada de 56kb/s e sinceramente um cara que vai acessar um site desses não usa conexão discada. Eu sinceramente até hoje não vi nenhum caso ou argumento que fizesse o “code in line” valer a pena.

  • http://blog.lppjunior.com Luiz Paulo

    Sim Bruno, concordo com vc.
    Mas você não precisa escrever “código torto” para se aproveitar dessas artimanhas.

    Sabemos que existem várias formas de reduzir o tamanho do código.

    Podemos utilizar algum esquemas para gerar o código “compilado” da parte WEB, como sistemas de obfuscator para JS ou até mesmo scripts para retirar os espaços / tabs dos códigos.

    Assim mantemos o código mais amigável no momento de edição e “compilamos” para publicação.

    Concordam?

  • http://www.brunodulcetti.com/blog Bruno Dulcetti

    @Mark – cara, é fácil falar quando não se está dentro do projeto e tudo mais. Eu sei que 20kb é pouco na sua visão e eu pensava assim. Agora multiplica esses 20kb em MILHÕES de acessos, mesmo que cacheado e tudo mais. Pegue só a primeira visita e são milhões. Isso é tráfego e é pago. Quanto mais podemos economizar, melhor ;) E me desculpa, mas temos acessos com discada sim e não são tão poucas ;) e eu considero esse um bom argumento

    @Luiz – to ligado cara, tb sou a favor desses recursos e ajudam bastante, mas bato novamente na tecla “burocrática” de uma grande empresa e tudo mais. Infelizmente não podemos colocar tudo em prática por falta de “liberdade” e engessamentos dentro de algo como vignette, entre outras coisas.

    mas ta legal essa discussão ;)

  • http://caioariede.com/ Caio Ariede

    Acho que o ganho sendo extremamente suficiente, ou pouco suficiente, independe.

    Você gasta mais tempo verificando a performance do que compactando um JS, por exemplo.

    Acho que a compactação e otimização deve fazer parte das boas práticas no desenvolvimento web, ainda mais agora que o número de acessos por celular vem aumentando muito.

    Nem que seja 1kB economizado, você faz 1 vez e te favorece a cada visita. :)

  • http://tableless.com.br/ Diego Eis

    @dulcetti Claro! Concordo contigo. Não adianta falar agora que eu não coloquei no post sobre os sites grandes! :D
    Nesse caso, e só nesse caso concordo com você. Esta seria a única excessão.

    Mas vocês já viram o CSS “in head” do Yahoo!?
    Está todo o CSS no HEAD do Yahoo!, não modularam em arquivos e o CSS é enorme! ENORME!

    Mas tudo bem, erro meu! Devia ter explicado sobre as grandes empresas! Desculpa o tio aqui!

  • http://www.brunodulcetti.com/blog Bruno Dulcetti

    relaxa Diego, eu vendo já fui falando isso, quando é pequeno vale a pena sim.

    bom, é bem bizarro essas coisas que rolar como a do Yahoo. mas eu não falo mais sobre essas paradas sem saber antes o argumento por terem utilizado isso. apesar que aparentemente não vejo nenhum, mas sempre tem algo pra ferrar… mas talvez não seja justificativa.

    e trabalhar com css dessa forma, mesma linha, acaba te deixando assim. Mesmo para projetos pequenos, eu já faço dessa forma, por costume mesmo. mas quando existem projetos onde mais pessoas não acostumadas com isso, prefiro o identado mesmo ;)

  • http://blog.fshark.com Fabiano Shark

    Trabalho em um portal de um provedor de SP e também usamos em uma linha, para editar não há problemas, usamos o firebug para ajustar os valores.

    Abraços,
    Fabiano Shark

  • http://marcogomes.com Marco Gomes

    Dá pra /minificar/ o CSS e o JS na hora da entrega, além de pode também gzipar tudo. Comprimir o código “na mão” é burrice.

    *** MESMO *** em sites ENORMES, não há porque ficar cortando espacos e quebras de linhas, como eu já disse, dá pra minificar na hora da entrega pro usuário, com isso, os espacos e quebras de linhas inuteis somem, e tudo fica lindo e rápido. Procurem por minify no Google :)

    Falo porque usamos isso aqui na boo-box, numa aplicação com 2 milhoes de hits por dia.

  • Pingback: Não “otimize” seu código CSS, por favor! | Leonardo Bighi

  • Pingback: Modulando o CSS » Tableless.com.br - CSS e Práticas com Padrões Web

  • http://www.camilotx.com.br Camilo Teixeira de Melo

    Discordo plenamente, antes de você alegar tal suposição (não otimizar o seu código) deveria ao menos a aprender a semântica CSS correta, pois os exemplos a cima não seguem o padrão.
    Como “Designer”, você não tem a necessidade de entender tais processos de funcionamento de servidores: tráfico, logs, processamento, cache, etc. Mas não use da ignorância para escrever, estude um pouco mais, se especialize antes de escrever um “artigo”.
    Quer matemática? A cada 5KB que vc economiza por acesso em um site com 1 milhão de acessos (número pequeno para grandes portais), é economizado 50000000 KB, ou seja, 488 MB por dia.
    Sem contar que o site carrega mais rápido, alivia o processamento do servidor e do navegador! O interpretador não liga se o código esta bonito, ele retira todos os espaço e tabulação.
    O Google é um exemplo de site de “otimização de código”, olhe e veja.
    Aprenda, antes de criticar o que você não conhece, a entender.

  • Pingback: Compactar meu CSS? Eu faço, mas se você não faz, tanto faz. Ou não. » Bruno Dulcetti - web standards, css, xhtml e tecnologia em geral.

  • http://filmesdatv.com João Henrique

    Será que não tem uma ferramenta gratuita que faça a otimização, para que as pessoas tenham 2 versões? (uma de desenvolvimento, e outra de produção)

  • http://project47.viscountbox.com/ Carlos Eduardo

    Acho que nem se deve entrar no mérito da questão, se o certo é escrever uma propriedade por linha ou uma regra inteira. Neste caso, prefiro a última opção, mas as duas maneiras estão certas!

    O importante é, caso você trabalhe com mais pessoas, estabeleça um padrão de escrita pra facilitar a manutenção e não haver confusões durante o desenvolvimento.

    Já escrevi bastante sobre isso no meu blog também, mas acho que muita coisa só se aprende com a experiência, passando por grandes projetos, por exemplo, que exigem um código bem enxuto, ou seja, otimizado, sem redundâncias no código, coisa muito comum quando estamos iniciando na área :)

  • Mauro George

    Muito boa a discussão, concordo com o @Diego eo @Bruno Dulcetti, acho que para sites pequenos é válido sim escrever identado, facilita na visualização, não há tantos page views… o problema deve ser mesmo em grandes site para poder tratar de banda, page views… ae sim vale a pena escrever em uma linha, gzip…

    Abração

  • Mark de Souza Costa

    @Bruno, eu acho que seria legal colocar dados estatísticos de banda consumida, porque eu realmente ainda não estou convencido de que isso é uma boa prática. Eu fiz umas brincadeiras aqui com os 20kb e dependendo realmente dos pageviews diários, pode chegar a valores extraórdinários de banca consumida:

    Se o pageview da página for de 10.000.0000 por dia podemos chegar a 200GB por dia, ignorando cache e os valores exatos do byte. Isso é um valor significante realmente (e bota significante nisso). Mas se reduz para a casa dos milhares, como 100.000 por dia, chegamos a não tão expressivos 2GB por dia, totalizando 60GB por mês em média.

    By the way, se essas ferramentas comentadas realmente fazem um bom processo automatizado, realmente não tem porque não economizar esses bytes.

  • Mark de Souza Costa

    Eu acho interessante também o dado de qual a porcentagem de redução de código que o “code-inline” proporciona, por exemplo, 20kb é o que? 2% do tamanho da página? Menos de 2%? Isso nos daria uma informação interessante, muito interessante.

  • http://www.visual7.com.br Fábio ZC

    Concordo com Guilherme Nagüeva, Diego CODU e com o Micox!

    Código inline fica MUITO prático quando vc já esta acostumado desta maneira.. vc nao precisa ficar rolando a tela para fazer a edição de código!

    e o que eu recomendo, no inicio pode parecer frescura, mas depois vira costume e para a localizacao das propriedades fica muito mais fácil, é: colocar as propriedades em ordem alfabética..
    assim vc sempre saberá a ordem das propriedades.. vc nunca vai ficar perdido procurando uma propriedade X..
    porém sempre deixo o width e height por último.

    Questão de costume

  • http://www.visual7.com.br Fábio ZC

    @Diego Eis, apesar de achar ótimo os seus posts, mas como alguém falou em um comentário ai em cima:

    “Obs: Mania que você tem de sempre colocar um “Não” no começo dos posts; Não otimize seu código; Não use comentários condicionais; pega mal. Dá a impressão de ser uma coisa “horrível”…”

  • Brill

    Não “otimizar” ou não “compactar”? Porque “otimizar” é tornar melhor, quando eu otimizo o código não é colocar ele todo em uma linha, otimizar pra mim sempre foi deixa-lo mais simples e fácil de entender, “Melhorar o código”.

    No editor que eu uso (PSPad), tem uma opção que faz isso com um clique, se chama “Compress HTML Code”. Para o CSS o processo se chama “Format into Inline CSS”, o processo inverso se chama “Format into Structured CSS”.

    Eu sempre preferi a forma estruturada porque o código fica mais claro. A forma compactada parece uma grande massa de caracteres.

    O post meu sobre o assunto se chamaria “Escreva seu código de forma estruturada”. Talvez esse negocie de “Otimizar” gere confusão. Se isso já não aconteceu!

  • http://hajaluz.net Luiz Aquino

    Francamente não sei porque tanta polêmica. O editor que eu utilizo (PsPad) faz o código ficar “inline” com um comando e quando for editar é só expandir em um comando também.

  • http://developer.yahoo.com Diogo Shaw

    Além do Cache, no Yahoo definimos versões estáveis e static compactadas, na hora da manuntenção temos o file original, no “push” pelo svn há uma compactação básica (minify).
    E quando usamos versões dentro do HTML, muitas vezes onthefly removemos espaços e linhas…

    Na hora de modificar qualquer JS e CSS todo o código está perfeitamente organizado, somente na hora de printar que tem o minify…

  • Lucas

    Eu utilizava o CSS fazendo uma propriedade por linha. Depois que “aprendi” a fazer no estilo
    #id { font-size: 12px; color..}
    nunca mais voltei para o antigo. Acho muito mais fácil de organizar o arquivo, com muito menos linhas. E adotei uma metodologia de colocar os elementos na mesma ordem, facilitando muito a manutenção.
    E não faço isso para “otimizar” o css e sim para deixa-lo mais organizado, ao meu ver.

  • http://tcelestino.com.br/blog Tiago Celestino

    Eu utilizava da forma não “otimizado”, porém, achei que a necessidade de não apenas ter algo mais organizado.

    Claro que seguir os padrões já é uma coisa que ajuda, porém, acredito que vai dar forma de cada um em montar o css. No XHTML, nunca utilizei a otimização, ou melhor, no tempos das tabelas sim. :D

  • http://www.luandapereira.com.br Lua

    Acho que é tudo uma questão de prática, não há nada que impeça uma pessoa de ler um código em uma linha, é só começar, depois acostuma…
    Só não acho certo dizer que é errado css numa só linha… o certo ou o errado quem diz é o projeto em sí.

  • http://blog.inuar.com Nei

    “Seu trabalho é exclusivamente esse: controlar o visual e diagramação do site.” que tal isso e + performance + economia de banda para usuarios menos privilegiados, etc..

    isso não é tal inútil assim como vcs diz.

  • Leo Cabral

    É um argumento válido, Diego. Mas hoje há editores que alternam em visualizações (otimizar para performance/reformatar para legibilidade) e essa opção permite comprimir sem afetar o trabalho, acho válida. Compreendo o “rant”; já me deparei com código crípticos e o custo de reorganizá-los afetava diretamente o rendimento do trabalho. Valeu pelo artigo.

  • http://www.brunonatal.com.br Bruno

    nossa… nem sei pq isso… para né… em 1990 tinha que pensar nisso e ninguem pensave né… agora com a qualidade de internet que temos nos preucuparmos com isso… com kbites… para né…

  • Jacob

    Não existe este negócio de que o código tem que ser escrito “assim” ou “assado”.

    Não há um padrão de como o código deve ser formatado, do contrário o navegador/interpretador não entenderia nada ele não funcionaria… e isto vale não só para css, mas também para um monte de outras linguagens; php, c++, pascal etc… Ou seja, pode valer apenas como sugestão para um programador aprendiz, e é apenas uma questão de estética e para copreensão do código, mas não uma questão de regra ou padrão.

    E quanto a economizar os bytes, isto é importante sim. Se um site carrega em 10 segundos e você consegue reduzir pra 8 segundos por exemplo, o visitante (que está pouco se lixando para o seu código e quer mais é ver a coisa funcionando direito e rápido) vai agradecer… ocorre que a maioria dos programadores e designers esquecem quem realmente interessa, o cliente, e acabam olhando o proprio umbigo e se importando mais para como os demais colegas de profissão o verá.

  • http://rwstudio.site90.com Rangel

    Bom, parabéns pelo WebSite TABLELESS.
    Eu acho q em partes sim tem razão de não “Otimizar” porém eh verdade q cada um tem sua própria forma, quando comecei, foi da forma em q se escrevia em uma LINHA só, rsrsrs mas isso não era bom pelo menos pra mim!

    Achei meio dificil de entender depois de um tempo sem mexer no site.

    em fim melhor fazer de acordo com um padrão, pq eu vi q realmente tem uma forma q a maioria escreve:

    div {
    padding: 10px;
    border: 1px solid #CCC;
    width: 485px;
    height: 37px;
    background: #EEE;
    }

    muito melhor mais entendivel…

    abraços.

  • Patrique

    Se não existe contras, não a motivo para não se usar um code in line, mesmo que o site seja pequeno… por isso defendemos os padões… nem que for para retirar mizeros 100kb por mês de banda isso já será uma vantagem.

    Contra fatos não há argumentos…

  • Vicente Lyrio

    Aqui onde trabalho somos responsáveis por alguns dos sites do Terra e do Ig, e eu faço o html/css da maneira que estou acostumado (sem compactar), e a equipe que desenvolve o projeto usa um script q compila a dll com o css já comprimido.

    Não dá trabalho algum dar manutenção, primeiro pq localmente o css está sem compressão, segundo pq o firebug ta aí pra isso.

    Além disso, acredito que qualquer prática que economize tráfigo é importante, independente do porte do site. Consumo de banda tb é consumo de energia, mesmo que pulverizada entre milhares de sites.

    O planeta agradece ;)

  • Helton Marinho

    Bom dia… Primeiro gostaria de parabenizar o Diego pelo artigo, polemico e interessante.

    Na minha opinião, que nasci na internet em 98, se você tem um código em linguagem Server-side que retorna o HTML, você pode poupar bytes em HTML. Já em CSS costumo não poupar bytes, porém p/ quem tem estrutura manter duas versões (light e pesadinho) é uma boa pedida.
    Exemplo “poupar código HTML sendo feliz”:

    Bom… essa é minha opinião
    Valeu

  • Peul

    Organizar o código é bom, agrega portabilidade e fácil atualização mas otimizar também é bom, fica leve e economiza processamento e banda. Porque não fazer as 2 coisas? É só passar o código por um otimizador como compilar um fonte. O que vai pro servidor é história, não é material de programação mas apenas executável, o resultado do trabalho.

  • Daniel Kiiti Haibara

    São apenas boas práticas, podem ser ou não seguidas. Porém, isso pode influênciar na legibilidade do código. Prefiro sempre um código legível e bem documentado.

    Parabens, ótimo artigo para influênciar novos programadores a organizar melhor o seu código.

  • http://www.studiosecret.com.br Paulo

    Acho que devemos facilitar a vida do cara que vai fazer manutenção no site amanhã. Um código limpo e padronizado facilita muito. Concordo com o artigo. Quanto ao consumo de banda, modular o CSS seria a melhor solução para se sesguir os padrões e otimizar o código.

  • Eleandro

    Acho a discução inútil. Qualquer desenvolver decente de um site de grande porte tem uma ferramenta que faz o minify no momento do depoy. Ou seja, o código fica intacto na máquina para desenvolvimento e compactado no servidor. Concordo plenamente que não faz sentido ter otimização. Contanto que o projeto seja do site do “tio joão” ou que tem uma ferramenta de publicação que faça o trabalho sujo de “minificar”.

  • http://aprendacss.wordpress.com Paulo Fernandes

    Gostei do artigo!

    Trabalhei em um provedor em SP. Lá o código CSS era todo em uma linha.
    Ficava mais leve, mas para editar as vezes ficava dificil encontrar o que mudar, só era possível com o “Localizar” dos editores.

    Para facilitar a edição, reescreviamos a regra no final do arquivo.

    Para fazer a otimização do css tem que tomar cuidado para não se perder.

    o que eu recomendo é criar na sua maquina um arquivo todo comentado e bem separado e quando for colocar em produção, remover os espaços em branco e os comentários

    abraço

  • http://www.uol.com.br Carlos Zillner

    Tudo depende de como será melhor dar manutenção no seu site.

    Nem sempre um CSS numa linha é um fator de complicação. Por exemplo, se você quer achar todo CSS relativo a um elemento da página, como por exemplo:

    /* Barra UOL */
    #barraUOL {height:2.3em;line-height:2.3em;padding:0 1em;position:relative;}
    #barraUOL a {display:inline}
    #barraUOL strong {font:bolder 1.1em Arial, Helvetica, sans-serif;}
    #barraUOL ul {position:absolute;top:0;right:3em;}
    #barraUOL ul li {float:left;position:relative;}
    #barraUOL ul li .icone {background:url(‘http://h.imguol.com/h3/barrauolicones.gif’) no-repeat;display:block;position:absolute;top:.1em;left:.6em;width:2.8em;height:2em;}
    #barraUOL ul li.batepapo .icone {background-position:-32px 0}
    #barraUOL ul li.messenger .icone {background-position:-64px 0}
    #barraUOL ul li.email .icone {background-position:-96px 0}
    #barraUOL ul li.shopping .icone {background-position:-128px 0}
    #barraUOL ul li.voip .icone {background-position:-160px 0}
    #barraUOL ul li.namoro .icone {background-position:-192px 0}

    É muito mais facil visualizar os componentes que envolvem a Barra UOL assim.

    Um CSS q diz recentemente, utiliza as duas maneiras:

    http://musica.uol.com.br/blogs/styles_blogradio.css

    Abraço!

    Muito legal o site, fazia tempo que nao entrava.

  • http://www.klebersonleite.com Kleberson Leite

    Bom.. o post é de se comentar e muito.. mas eu prefiro organizar o meu codigo como foi relatado no post.

    E acho que fazendo em uma linha pode atrapalhar..

    Gosto não se discute!! Então.. Cada um faça como achar melhor.. o problema é com quem vai atualizar este website, ou até mesmo como vai se atualizar um site com o codigo dessa forma…

  • Danielle Young

    O código em uma só linha não é errado. Acho que quando o autor escreveu este artigo, ele deve ter achado que as pessoas fazem isso de propósito.

    Eu trabalho em uma organização onde temos que fazer o site, depois retiramos todos os espaços. Por que? Consumo de Banda!

    Essa otimização não prejudica em nada. Primeiro fazemos todos os testes de forma privada, e um pouco antes de disponibilizar no ar, é otimizado.

    Obs.: Acho que as pessoas não deveriam se prender totalmente em conceitos, e deveriam pensar nas soluções de forma prática.

  • http://www.baixar.info Bruno

    Não concordo, no meu caso eu programo o css em uma linha, mas não por economizar o código e sim por facilitar em muito a minha leitura quando quero achar uma classe. Você já experimentou usar o código assim? As classes ficam muito mais fáceis de serem achadas, ainda mais por quem utiliza editores de texto simples. Obrigado