O desenvolvedor web, o cara que programa, que mete a mão na massa – ou no código – é, obviamente, o pedreiro.  Um pedreiro de luxo, é verdade, mas continua pedreiro. Um peão. E assim como um peão o desenvolvedor web pode ser chamado para muitas coisas – os bicos ou freelas – que vão desde uma troca simples de azulejos – ou uma alteração num formulário de contato – até uma reforma total da cozinha – ou a construção de uma nova área do site.

Nesse aspecto não podemos esquecer que, assim como o pedreiro não é decorador, desenvolvedor web não é webdesigner. O pedreiro até dá pitaco no azulejo, na cor da tinta, mas quem estudou pra isso não foi ele (eu sei que o pedreiro não estudou nem pra ser pedreiro, mas você entendeu).

Se estiver fazendo um freela e precisar de um layout profissional chame um profissional. Layouts envolvem diagramação, equilíbrio de cores, hierarquias de elementos que, se você não estudou, você vai simplesmente ignorar e o resultado pode ser desastroso. Convide um designer para participar do projeto nem que seja para te dar consultoria ou para te mandar uma ideia inicial. Não fica caro e enriquece o seu trabalho, além de – se você trabalhar direitinho – o designer te chamar quando precisar de um desenvolvedor.

Outro ponto interessante é que, em construções decentes, sabe-se onde queremos chegar. Sites que não são bem planejados desde o começo têm uma estrutura difícil de entender e, por consequencia, difícil de navegar. Se estiver com um problema grande pra resolver nesse sentido é legal pedir ajuda pra alguém da área de arquitetura de informação.

Entretanto existem algumas diferenças na comparação com a construção civil como, por exemplo, o acumulo de funções. Não raro assumimos a função de engenheiro e pedreiro ao mesmo tempo, cobramos preços bem diferentes dos pedreiros (eu cobro, você não?!). Também passamos facilmente de pedreiros a engenheiros, mas quando precisamos temos que colocar nosso capacete de peão e ir lá mexer a massa.

Posts Relacionados:

1. Organizando seu código CSS

Se você chegou agora, pode ser interessante ler meus textos anteriores sobre o assunto:

• XHTML2, HTML5 e outras coisas futuristas
• As Mudanças do XHTML 2.0

A primeira coisa que preciso dizer é em que o HTML 5 é diferente do XHTML 2. Sua maior preocupação não é separar definitivamente o conteúdo da apresentação. O HTML 5 é feito para ser uma linguagem de desenvolvimento de aplicações online. Nada de se preocupar com XML, nada de evitar usar um elemento só porque ele também interfere na aparência do conteúdo.

Pro inferno com as frescuras, eu quero é sites bons.

Esta nova versão do HTML começou a ser desenvolvida em um grupo fora do grande W3C. Fizeram isso justamente porque o W3C estava demorando demais pra criar uma nova versão (0 xhtml 1.0 foi publicado em 2000) e eles estavam trabalhando em algo que não resolvia os problemas dos sites ricos que temos hoje em dia.

O HTML 5 é feito para facilitar o desenvolvimento de aplicações web (e não apenas sites simples) e padronizar as coisas em todos os browsers.

Vamos ver todas as coisas legais que o HTML 5 traz pra nós.

Elementos estruturais

Aquele monte de <div> que a gente usa pra montar a estrutura do site vai ter um bom substituto agora. Pra facilitar uma padronização e permitir que os elementos tenham significado, criaram vários elementos estruturais que vão funcionar como o <div>, mas cada um com seu próposito.

Por exemplo, teremos o <header> para criar o cabeçalho do site (geralmente onde fica o logotipo, etc). Temos o <nav> para definir o menu de navegação, <article> para colocar o conteúdo principal do site, <aside> pra criar uma seção lateral, e <footer> pro rodapé.

Estrutura de um site padrão

Novas tags multimídia!

Em vez de fazer como no XHTML 2, onde tem uma única tag bizarra para exibir conteúdo multimídia, o HTML 5 preza por uma solução mais óbvia e mais fácil.

Para tocar som, você tem a tag <audio>. E o negócio ainda é tão bem feito que dentro da própria tag você passa uns parâmetros para definir se começa a tocar sozinho, e até se o browser vai exibir controles (play, pause, etc). Se o browser não suportar html 5, aparece o texto interno.

<audio src="musica.ogg" autoplay control>
    Você não tem HTML 5, bobão, então faça <a href="musica.ogg">download</a> da música.
</audio>

E vídeo, então, que maravilha! Se antes você tinha que usar a tag <object> cheia de parâmetros, agora basta usar a tag <video>. Você pode definir largura e altura, e também definir se quer autoplay (iniciar automaticamente) ou se quer exibir os controles. Você pode até mesmo definir pro vídeo ficar passando em loop, se quiser fazer lavagem cerebral em alguém.

<video src="lavagemcerebral.ogg" autoplay loop>
    Quem não tem HTML 5, saia pela segunda porta à direita.
</video>

E quem cuida de exibir o vídeo? O browser! Por padrão, o codec de vídeo vem dentro do próprio browser e todos os usuários poderão assistir, independente de que browser ou sistema operacional eles usam. E sem ter que baixar plugin!

Você pode brincar de desenhar

O novo elemento <canvas> permite que você escreva código que desenha na tela em tempo real. Isso é muito interessante pra criar gráficos, por exemplo. Imagina o Google Analytics sem precisar de flash.

E não só desenhar, mas redesenhar, modificar desenhos, mover os desenhos. Alguém poderia escrever um jogo com elementos se mexendo, usando o canvas. Sem precisar de flash.

E tem a correção de erros!

Além de tudo isso, uma parte muito importante da especificação do HTML 5 é que ele diz aos navegadores como eles vão tratar um código que esteja errado.

A grande maioria dos sites na internet tem um código muito mal feito. Você só é capaz de ver “corretamente” o conteúdo desses sites porque todos os browsers possuem um poderoso motor de correção de código. Esse motor vê aquele código capenga, que não valida nem com HTML 4.01, e tenta “deduzir” o que o desenvolvedor quis fazer. O maior problema é que cada browser deduz as coisas de um jeito diferente.

O HTML 5, além de trazer todas essas maravilhas, traz uma série bem específica de regras para os navegadores deduzirem aquele código bizarro e malformado. Assim há uma garantia de que até esse código ruim vai ser exibido da mesma forma em todos os navegadores.

Mas esperem sentados…

Se você também ficou animado com as possibilidades (e olha que nem falei todas), aí vem o banho de água fria: vai demorar! A versão final do HTML 5 não fica pronta esse ano. E nem no ano que vem.

E mesmo depois de sair a versão final, temos um enorme problema chamado Internet Explorer. Não poderemos usar os novos recursos em sites sérios, até que o Internet Explorer dê um suporte decente à linguagem.

Sendo otimista, eu diria que lá pra 2025 vamos poder usar a linguagem.

No related posts.

Use a Cabeça! (Head First) HTML com CSS & XHTML

Há um bom tempo atrás eu comprei o livro Use a Cabeça! (Head First) HTML com CSS & XHTML, e apesar de já ter começado a lê-lo várias vezes, somente no início desse ano eu tomei vergonha na cara e o li do início ao fim. Sendo assim, aqui está a minha opinião sobre o livro.

Assim como os demais títulos da série Use a Cabeça, esse livro tem uma abordagem bastante inteligente, focada num texto fácil e extremamente agradável de ler. Esta característica, combinada com algumas outras, faz com que o nosso cérebro preste mais atenção no conteúdo, além de aumentar as chances de memorização, conforme os livros da série explicam em seus capítulos introdutórios.

Outra tática inteligente do livro é dar exemplos para cada novo tópico apresentado, só que limitando o escopo, de forma que os exemplos sejam bem simples e diretos. Isso evita que o leitor fique cansado lendo longos exemplos onde apenas um pequeno trecho é realmente relevante.

Essa abordagem mais direta também é aplicada nos exercícios, que aparecem com razoável frequência, mas sempre bem focados no tópico que está sendo discutido no momento. Além disso, muitos dos exercícios são divertidos, e o obrigam a pensar fora da caixa, principalmente os exercícios de palavras cruzadas, presente em quase todos os capítulos.

Uma outra característica que torna o livro mais eficiente na tarefa de ensinar o conteúdo é o fato dele ser redundante sobre muitas coisas importantes. Dessa forma, alguns tópicos são apresentados mais de uma vez, só que em contextos e de formas diferentes, muitas vezes adicionando uma pequena novidade, e facilitando que o assunto em questão seja memorizado através da ocorrência repetida.

Ainda sobre a didática do livro, é interessante notar que a série segue essa fórmula não porque está dando certo, ou baseada em achismo, mas porque estudos relacionados a metacognição indicam que as técnicas de apresentação de conteúdo usadas no livro estão entre as mais eficientes.

Em relação ao conteúdo propriamente dito, é impossível não destacar positivamente a preocupação do livro em focar desde o início a separação da estrutura e da apresentação de uma página Web. Para ter uma idéia do quão engajados eles são em relação a este assunto, já no capítulo que explica sobre a metodologia da série, ou seja, antes mesmo do primeiro capítulo com conteúdo sobre HTML, XHTML e CSS, há uma breve e clara explicação sobre a função dessas tecnologias.

Adicionalmente, o livro menciona com frequência que devem ser utilizados os elementos do HTML/XHTML que melhor representarem o conteúdo que está sendo marcado, enfatizando assim a importância da semântica no desenvolvimento de uma página Web.

No entanto, nada é perfeito, e este livro não é diferente. Pra começar, a tradução é péssima. A Alta Books, que é a editora do livro, fez um trabalho extremamente descuidado na tradução, o que não me surpreendeu, já que o único outro livro traduzido que eu tenho deles, o Use a Cabeça! Java, também tem uma tradução sofrível.

Aliás, ao meu ver, este é o maior defeito do livro, pois realmente complica a compreensão do texto por parte de quem não sabe nada sobre HTML, XHTML e CSS, sendo que este é exatamente o público alvo do livro. Como exemplo deste péssimo trabalho de tradução, eu posso citar nomes de elementos sendo traduzidos, sendo o elemento head o campeão no número de ocorrências.

Outro erro bizarro está nos exemplos de regras do CSS. A extrema maioria delas não possuem um par de chaves tradicional, ou seja, { e }, e sim um bizonho par de chaves { e {. Exemplo:

p
{
  color: maroon;
{

O exemplo acima foi tirado do próprio livro, no capítulo que começa a explicar o CSS. Ou seja, quem nunca ouvir falar sobre a linguagem vai ficar bem confuso sobre a forma correta de combinar as chaves. E o mais curioso é que a versão original do livro não contém estes erros, portanto, a Alta Books fez besteira até onde nem precisava traduzir.

Contudo, nem todos os defeitos do livro são culpa da Alta Books, uma vez que há também alguns poucos deslizes na versão original em inglês. Por exemplo, o livro usa com certa frequência o elemento <br />, o que, ao me ver, é errado, uma vez que este elemento insera uma quebra de linha, o que caracteriza uma função relacionada a apresentação, não representando absolutamente nada em relação à semântica da página Web.

Outro erro relacionado ao uso incorreto de um elemento no que diz respeito a semântica está presente no exemplo abaixo:

  <h1>BEVERAGES</h1>

  <p>House Blend, $1.49</p>

  <p>Mocha Cafe Latte, $2.35</p>

  <p>Cappuccino, $1.89</p>

  <p>Chai Tea, $1.85</p>

Neste caso, novamente de acordo com a minha opinião, há vários elementos p sendo usados para representar itens de uma lista, portanto o correto seria envolver toda a lista com o elemento ul, que representa listas não ordenadas, e então usar o elemento para itens de lista, li, para cada bebida individual. O resultado seria esse:

  <h1>BEVERAGES</h1>

  <ol>
    <li>House Blend, $1.49</li>
    <li>Mocha Cafe Latte, $2.35</li>
    <li>Cappuccino, $1.89</li>
    <li>Chai Tea, $1.85</li>
  </ol>

Mas nesse caso podemos deixar passar, já que na verdade este exemplo está presente na página de recursos do livro.

Enfim, o Use a Cabeça! (Head First) HTML com CSS & XHTML é um excelente livro. Ainda que ele cometa alguns poucos deslizes, é de longe o melhor livro que eu conheço para quem quer aprender HTML, XHTML e CSS, uma vez que ensina desde o início a desenvolver páginas Web da maneira correta: usando o HTML ou XHTML para estruturar o conteúdo da página, respeitando a semântica de cada elemento, e definindo a apresentaçao através do CSS.

P.S.: Uma dica para quem se interresou pelo livro: compre a versão original e se livre de uma péssima tradução.

Posts Relacionados:

1. Organizando seu código CSS

Desde a versão 1.0 do XHTML o consórcio W3C tem empurrado cada vez mais o HTML pro lado do XML. Mas essa versão foi feita pra tentar manter uma grande semelhança e compatibilidade com o HTML 4.01, e por isso acabaram mantendo muitos elementos de apresentação no XHTML. Agora, querem dar um grande passo. Querem remover tudo, querem fazer o XHTML que o W3C sempre sonhou. E com isso podem dizer adeus à retrocompatibilidade.

Quanto mais as coisas mudam, mais elas mudam

A idéia do W3C para o XHTML 2.0 é remover TODOS os elementos de apresentação. Ou seja, qualquer coisa no código XHTML que indique como o elemento vai aparecer na tela vai ser removido. Isso é trabalho do CSS. Nessa nova versão morrem as tags <img>, <a>, <br> e algumas outras.

Vai ter uma série de mudanças tão grandes que não existe compatibilidade com versões anteriores. Os sites precisarão ser refeitos para validar com as especificações do XHTML 2.0. O problema é que a maioria dos profissionais são ruins. Ainda hoje a maioria dos sites não cumpre nem as especificações do HTML 4.01, imagina se vão mudar pra se adequar a essa nova “linguagem estranha”.

Eu conheço ainda pessoas que nem sabem direito o que é CSS ou XHTML. Profissionais que montam seus sites usando a tag <font> pra formatar o texto, e outras coisas igualmente bizarras. Esse tipo de pessoa nunca vai querer reaprender tudo pra adotar o XHTML 2.0.

Vamos dar uma olhada em algumas das principais mudanças:

- Mataram o <a>. Agora tudo é link.

Todos os elementos do XHTML possuem alguns parâmetros padrão, como “id”. E agora o parâmetro “href” se junta a essa lista. Qualquer elemento poderá receber o parâmetro href e se tornar um link. Você vai poder fazer coisas como <p href=”http://disney.com”>…um monte de texto…</p> e terá um parágrafo inteiro funcionando como link.

- Adeus <br>. Olá <line>

Eles não querem que o XHTML tenha nada que force um jeito específico do conteúdo aparecer na página, então uma das primeiras tags a morrerem foi a tag de quebra de linha. Não tinha jeito de impedir, ela só servia pra uma coisa e pronto.

No lugar dela, entre a tag <line></line>. O padrão é que sempre que você fechar a tag o browser vai quebrar a linha, mas agora você pode evitar esse comportamento se quiser.

- Um <object> para a todos dominar.

Mais duas tags que morrem: <img> e <applet>. No lugar delas vem a tag <object> que é uma tag extremamente complexa, daquelas meio esotéricas, pra representar diversos tipos de conteúdo de mídia. Se você quiser inserir uma simples imagem, tem que botar esse código todo:

<object data="/imagens/sandy-nua.jpg" type="image/gif">
  Aqui é um texto equivalente ao alt da imagem
</object>

A outra opção para exibir uma imagem é usar outro dos novos parâmetros padrão, o src. Qualquer elemento do XHTML agora pode receber o parâmetro src, que faz aparecer uma imagem no lugar do elemento. Não vejo grandes vantagens deste método em relação ao atributo imagem normal, já que isso não remove a necessidade de ter a imagem dentro do XHTML.

E por aí a vida segue

O XHTML 2.0 também traz várias outras mudanças, como formulários mais parrudos e novos tipos de listas. Mas o que me parece é que essa atualização existe apenas para agradar o próprio W3C, e não para realmente resolver os problemas dos desenvolvedores. É uma atualização que quebra toda a compatibilidade com linguagens anteriores e traz mudanças, mas parece que é só pelo prazer de realmente portar tudo pro mais perfeito XML e separar totalmente estrutura e aparência.

Mas cadê as mudanças que realmente torne nossos sites melhores? Isso vai resolver os problemas que estamos tendo hoje? Como isso vai me facilitar a criar bons sites dinâmicos?

Eu não sou o único preocupado com isso, na verdade. Foi justamente pensando em resolver os problemas atuais que as grandes desenvolvedoras se uniram para criar o HTML 5. Mas isso é assunto para outro post.

No related posts.

(Acabei de receber um fax me proibindo de fazer piadas com super-heróis num site sobre programação. Eu garanto que não há nenhuma referência a um personagem famoso pelos próximos três parágrafos)

Duas grandes tecnologias estão sendo desenvolvidas e deverão estar disponíveis antes de 2099: XHTML 2.0, e HTML 5. A principal diferença entre elas é que o HTML 5 é uma evolução de tudo que temos hoje, e o XHTML 2.0 é tão diferente que é quase uma linguagem nova.

Explicando de uma forma clara, é como se o HTML 5 fosse o seu carro atual, mas com neón azul, turbina e aerofólios, e o XHTML 2.0 seria como vender o seu carro, tirar o seu dinheiro da poupança e comprar um novo importado, com marcha no volante e formato esquisito.

HTML5 está pronto pra briga!

O que me parece é que alguém perdeu completamente a noção da realidade. Mesmo hoje, a maioria dos sites não consegue validar nem contra as especificações do HTML 4.01. Uma boa parte dos programadores é tão ignorante que nem faz idéia do que é XHTML e com qual garfo se come isso. É muito otimismo acreditar que uma revolução completa na linguagem conseguiria uma grande adoção. Não quero ser muito pessimista, mas não acredito no futuro do XHTML, que é desenvolvido pelo consórcio W3C (World Wide Web Consortium).

Já o HTML 5 está sendo sendo desenvolvido pelo grupo WHATWG (na minha cabeça, isso é sigla para Why Have A Tomato With Guitars, “por que ter um tomate com guitarras”), formado pela Apple, Mozilla, e Opera. Sim, as grandonas do desenvolvimento de navegadores bons. A proposta do HTML 5 é pegar tudo de bom que temos até agora, acrescentar coisas ainda melhores, e corrigir as falhas para que todos os navegadores renderizem os sites da mesma forma. Incluindo os sites que não validam nem com o HTML 4.01. Isso sim parece bom. O que o Batman faria?

Vou te dizer o que o Batman faria. O Batman sabe que não é muito bom ter duas linguagens concorrendo pra substituir as tecnologias atuais. Ele vai esperar e observar até que, num futuro não tão distante (2030 é perto, não é?) as duas linguagens vão dividir os programadores por um tempo, mas depois uma delas vai ser esquecida e morrer. Porque o Batman é esperto. Ele sabe que HTML é como Highlander: só pode haver um. E apenas um dos grupos tem guitarras.

No related posts.

O problema é que as pessoas tendem a supervalorizar qualquer coisa que suas mentes venham a produzir. Assim, ao terem uma idéia, elas ficam tão satisfeitas consigo mesmas que a consideram instantaneamente boa, ou até mesmo revolucionária. Acontece que essa não é a verdade na extrema maioria dos casos.

Não quero ser fatalista, mas as estatísticas me permitem dizer que a maioria das idéias não são boas, muito menos revolucionárias. Portanto, é importante reconhecer quando sua idéia não é boa o bastante para merecer ver a luz do dia. Dessa forma, ao contrário do que possa parecer, você está lhe prestando um serviço, já que evitará perder tempo e energia em um empreendimento que já começa perdendo.

Contudo, não é exatamente fácil reconhecer quando suas idéias são ruins, devido principalmente à natural valorização que damos a nossas próprias idéias. Além disso, a definição de uma idéia ruim é um tópico complexo, e o que é uma idéia ruim para alguns, pode ser uma idéia excelente para outros. Tendo isso em vista, abaixo eu disponibilizo algumas perguntas que eu faço quando quero identificar aquilo que eu considero uma idéia ruim.

O que as Outras Pessoas Acham da sua Idéia?

Uma forma de anular o deslumbramento natural que temos em relação a nossas próprias idéias é pedir a opinião sobre elas a outras pessoas. Só tome cuidado de perguntar para as pessoas certas. Em geral, as melhores pessoas para conversar sobre o assunto são aquelas que você respeita intelectualmente e/ou que entendam do problema que sua idéia resolve.

Entretanto, é importante ter em mente que ninguém tem credenciais boas o suficiente para afirmar que sua idéia é ruim se você realmente acredita nela. Portanto, se você tem uma idéia que você tem certeza que é válida, não desista dela só porque existem incontáveis opiniões contrárias, e nenhuma a favor. Muitas idéias revolucionárias só foram adiante porque os seus autores foram visionários o suficiente para não darem importância ao fato de estarem sozinhos na crença de que ali tinha algo que valia a pena.

Você está Resolvendo um Problema ao qual Você se Importa?

Se a resposta a esta pergunta for “não”, nem perca o seu tempo, provavelmente você não terá sucesso em seu empreendimento. Fazer uma idéia florescer em um negócio rentável é realmente trabalhoso, e não há nenhuma garantia que você consiga isso, mesmo estando apaixonado pelo seu projeto. Portanto, tentar o mesmo sem estar engajado diminuirá consideravelmente suas chances, já que você provavelmente não terá o mesmo gás quando tiver que enfrentar os problemas que inevitavelmente surgirão.

Adicionalmente, você estará lutando contra as estatísticas novamente, uma vez que a maioria dos empreendimentos não dão certo. Logo, você terá uma chance enorme de fracassar, o que lhe trará um enorme sentimento de frustração caso ocorra, uma vez que investiu tempo e energia em algo que no fim não deu certo e que nem mesmo lhe interessava em nível pessoal.

Você sabe Implementar a Solução do seu Problema?

Não adianta conhecer bem o problema e ter uma possível solução para ele se você não sabe como efetivamente implementar a sua idéia. É o mesmo que resolver o problema da falta de tempo com uma máquina do tempo. É uma ótima solução, mas você não faz idéia de como torná-la real, portanto é o mesmo que nada.

Sendo assim, seja qual for a área pela qual a sua solução transite, garanta que você tenha conhecimento suficiente para construi-la. Se não for o caso, você deve aprender o que precisa para resolver o problema em questão, ou encontrar alguém que seja capaz de fazê-lo. Caso contrário, qualquer tentativa de levar sua idéia adiante será perda de tempo.

O Problema em Questão Merece Ser Resolvido?

Atualmente é quase um consenso que qualquer que seja o problema que você tenha, você não é único. Embora isso seja verdade, acaba passando a ilusão de que se você se incomodou com algo e imaginou uma forma de resolver isso, então vale a pena colocar em prática.

Acontece que isso só é verdade se você tem como único objetivo resolver o problema, ignorando qualquer possibilidade disso se tornar um empreendimento rentável. Afinal, nem todos os problemas incomodam um número suficiente de pessoas ao ponto de virar um negócio. Alguns problemas simplesmente são pequenos demais para se tornarem o ponto central de um empreendimento bem sucedido.

Conclusão

É claro que existem outras questões a serem consideradas ao avaliar a validade de uma idéia, mas acredito que os questionamentos acima já ajudam um pouco. Portanto, se a sua idéia passsar intacta por todos esses questionamentos, é possível que você tenha mesmo uma boa idéia.

No entanto, é sempre bom lembrar que só uma idéia não é nada. A melhor idéia do mundo pode ser arruínada por uma péssima execução. O mesmo vale para uma idéia muito ruim, que pode ser salva por uma implementação primorosa.

Logo, se tiver uma boa idéia, vá adiante e se dedique também a sua execução. Mas caso ela seja ruim, ou simplesmente não seja boa o bastante, e você não consiga pensar em nada melhor, vá em frente com ela mesmo. Qualquer idéia é melhor do que nenhuma, e você pode acabar sendo redimido por um trabalho operacional brilhante. Além disso, em última análise, é o seu público alvo que decidirá o valor da sua idéia.

No related posts.

Então eu desenvolvi 5 regrinhas que ajudaram meu CSS a ficar mais organizado, e mais fácil de mexer.

1- Usar um CSS Reset

CSS Reset é como tomar uma droga bem forte. Quem nunca usou acha que não é algo útil, ou até ruim. Mas depois que você experimenta não quer mais voltar atrás e ainda tenta convencer os outros a usarem também.

Apesar dos navegadores terem um ótimo suporte ao CSS, muitos deles tem padrões diferentes. Se você não definiu uma coisa, ela é exibida com o padrão do navegador, e isso pode fazer o seu site ficar com caras diferentes de acordo com o navegador do usuário.

O CSS Reset pega uma grande parte dos elementos visuais e padroniza eles, geralmente zerando ou definindo um novo padrão. Ele tira as bordas, as margens, os paddings, padroniza o tamanho da fonte, etc. A partir daí, você sabe que as coisas vão ficar mais certinhas em todos os navegadores e não vai ter nenhuma surpresa desagradável.

Recomendo Eric Meyer Reset, ou o fantástico YUI Reset.

2- Colocar em ordem alfabética

Sabe quando você tem aquele elemento no CSS que tem uns 12 parâmetros ou mais? Aí você precisa editar a margem, passa o olho rápido pela lista de parâmetros e não encontra. Cadê a margem que estava aqui? Tá ali bem na sua frente, mas tem que olhar umas 3 vezes pra achar. É um saco.

Eu passei então a organizar meus parâmetros do CSS em ordem alfabética, e fez uma grande diferença. Eu sempre sei que a border vai estar perto do começo, e que a margin vai estar ali perto do meio, perto do padding.

3- Separar os trechos de códigos em categorias

Quando o CSS fica realmente grande, o jeito mais fácil de organizar o código é usando comentários pra criar uma separação visual.

/* ------------------------------------------- */
/* ---------- MENU LATERAL ------------------- */
/* ------------------------------------------- */
elemento {
    color: #000;
    background: #FFF;
    outros códigos...
}
elemento a {...}
elemento img {...}

/* ------------------------------------------- */
/* ---------- RODAPÉ ------------------------- */
/* ------------------------------------------- */

div#footer {...}
div img {...}

Fica ainda mais organizado se as categorias estiverem numa ordem lógica, indo dos elementos mais genéricos pros mais específicos.

4- Colocar seu esquema de cores como comentário  no topo

Geralmente no site você tem umas poucas cores selecionadas pra usar. O que acontecia muito comigo era toda hora ter que parar pra procurar qual era mesmo o código daquele azul do título, ou o código do vermelho da borda do rodapé.

Uma solução simples passou a me poupar muito tempo.

Eu passei a colocar um comentário no topo do CSS, indicando os códigos das cores do meu site.

/* ---------- CORES ------------------------- */
/*
    Azul Claro: #A8EFEE;
    Marrom Escuro: #473B38;
    Rosa Clodovil: #FF4095;
    Amarelo Urina: #F2D843;
*/

5 – Não usar o parâmetro important!

O CSS tem o recurso important! que serve para definir uma regra como prioridade máxima, insubstituível. E isso atrapalha demais. Se você definiu, por exemplo, a cor da fonte como !important, não tem nada que você possa fazer no CSS pra definir outra cor de fonte. Na verdade, nem por javascript você conseguirá mudar a cor da fonte. O important! sempre tem prioridade máxima.

Acontece que no fim das contas isso sempre acaba atrapalhando no futuro. Mesmo que a versão inicial do layout saia legal, mais cedo ou mais tarde você vai precisar editar o seu site e aquele important! perdido lá vai te dar dor de cabeça.

Se você usou esse recurso no seu CSS, é porque algo não está certo. Dá pra organizar todo o seu site sem ter que usar isso, e é bom se planejar para isso desde o começo.

Usar !important no CSS é como casar com mulher promíscua. Você pode não ter tido nenhum problema até agora, mas é só questão de tempo.

Posts Relacionados:

1. Cada um no seu quadrado
2. Use a Cabeça! (Head First) HTML com CSS & XHTML

Hoje estava tendo problemas com o caracter & (e comercial/ampersand) no javaScript. O sistema é baseado em AJAX, portanto os dados ficam trafegando na forma de Query String e no fim é enviado por um Post Request.

Para não ter problema com caracteres especiais, essa query string era encodada com a função EncodeURI() do JavaScript. Aí estava o problema. Ele encoda toda a string para URI, mas não o caracter &, já que ele é usado como separador de variáveis na Query String. Tentei então usar a função escape(). Funciona, mas ferrava os acentos.

Achei que era a função escape que não entendia acento e botava caracteres estranhos no local, mas depois de muito teste acabei descobrindo que ele entendia sim os acentos, mas os passava pra latin1. Como uso padrão UTF-8, ferrei-me.

Então depois de uma pesquisada descobri a função encodeURIComponent(), esse sim vai encodar perfeitamente e respeitando o UTF-8.

No related posts.

A verdade é que estes trocadilhos são tão manjados que hoje integram o status quo tanto quanto os produtos que eles tentam ridicularizar. Como consequência disso, muita gente começa a usar essas expressões só para parecer cool, até porque não existe forma mais fácil de parecer cool do que falar mal da Microsoft. O curioso é que muitos dos que se valem destas expressões geralmente o fazem sob alguma versão do Windows, e em alguns casos até mesmo sob o Internet Explorer.

É mais um exemplo do velho caso do comportamento herdado sem questionamento algum, apenas por que outros o fizeram antes. Dessa forma, repetindo esses geniais trocadilhos, muitos acreditam que estaram anexando à sua reputação a qualidade de alguém crítico, questionador, quando na verdade são meros repetidores de trocadilhos bem pouco inspirados.

Além disso, duas dessas expressões merecem destaque especial: Micro$oft e M$. Elas por si só nem mesmo são depreciativas, pois colocar um cifrão no nome ou na abreviação do nome de uma empresa, pelo menos pra mim, significa apenas que se trata de uma empresa lucrativa, ou que busca o lucro. E isso de maneira alguma é ruim. Pelo contrário, uma empresa tradicional, ou seja, aquelas que vendem produtos ou serviços, precisam lucrar para se manter no mercado, portanto associar a imagem da Microsoft ao lucro é o mesmo que dizer que ela é competente em fazer aquilo que toda empresa deve fazer: lucrar.

Por fim, eu só quero destacar que não estou defendendo a Microsoft e nem os seus produtos, assim como também não os estou criticando. A crítica aqui é direcionada apenas ao que eu considero ser a forma mais infantil de crítica, ainda mais quando repetida a exaustão por aqueles nem sabem o porquê da crítica. Portanto, se quiserem criticar algo ou alguém, armem-se de argumentos, não de velhos trocadilhos que só deixam transparecer que o bobo da história é você.

No related posts.

Desenvolvedores do mundo todo estão aderindo a essa movimentação e parando de suportar o IE6. No dia 11 deste mês, vários sites da Noruega passaram a colocar também um alerta aos usuários deste navegador para que atualizem a versão.

Pra ser honesto, se eu fosse listar os 3 navegadores que eu mais odeio, eu diria Internet Explorer 6, Internet Explorer 7, e Internet Explorer 8. Nessa ordem. Só de você ter o  Internet Explorer como navegador padrão na sua casa, o meu respeito por você cai aproximadamente 350%.

Pro inferno com navegadores ruins!

Um método interessante pra incentivar as pessoas a mudarem é não só parar de suportar, mas também alertar os usuários e ainda disponibilizar uma página explicando o problema e como se faz o upgrade pra uma versão mais nova. Quem sabe a pessoa não acaba até abandonando o Internet Explorer de vez? Ou será que estou sonhando alto demais?

O site quirksmode.org criou a página Upgrade your browser! onde explica para o usuário como o IE6 é ruim e porque ele precisa fazer o upgrade. Podemos usá-la como inspiração para criar páginas semelhantes em português.

Então vamos todos forçar esses filhos de uma taturana a abandonar o Internet Explorer 6 de uma vez por todas! Coloque um aviso no seu site que só será visto por quem usa essa versão.

Veja o código condicional abaixo:

<!--[if lte IE 6]>
  <p class="ie6"><strong>IE6?</strong> Sério? Não acha que já passou da hora de um <a href="/upgrade.html">upgrade para uma versão mais nova</a>?</p>
<![endif]-->

Deixe de suportar o IE6. Coloque um código condicional no seu site. Vamos tirar essa âncora dos nossos projetos e dar o grito de liberdade: Pro inferno com navegadores ruins!

No related posts.

address

O elemento address define um conteúdo como uma informação de contato do autor ou dono da página Web.

  Avenida Expedicionário José Amáro, número 500, Apartamento 13, Vila São Luís,
  Duque de Caxias/RJ.

del

Tem a função de marcar um texto que foi removido da página.

<p>
  O Jogo Final Fantasy XIII é a continuação da famosa saga de RPG da Square
  ,sendo o seu lançamento exclusivo para o Playstation 3.
</p>

ins

Especifica um texto que foi inserido no documento, sendo muitas vezes usado em conjunto com o elemento del, como forma de corrigir uma informação anterior.

  <p>
    A atual versão do Rails é a 2.22.3.2.
  </p>

abbr

O elemento abbr serve para marcar um texto que é a forma abreviada de uma frase ou de uma expressão composta, ou seja, ele marca abreviações. Adicionalmente, é bom utilizar o atributo title neste elemento para especificar a palavra ou frase inteira que está sendo abreviada. Além disso, é válido mencionar que este elemento não é suportado pelo Internet Explorer 6.

  <p>
    O <abbr title = "EXtensible HyperText Markup Language">XHTML</abbr> deve ser
    usado para estruturar o conteúdo.
  </p>

acronym

Este elemento tem a função semântica de identificar acrônimos, que são um tipo especial de abreviação, onde cada letra do acrônimo corresponde à primeira letra de uma das palavras da expressão ou frase abreviada.

<p>
  Para definir a apresentação de uma página Web você deve usar o
  <acronym title = "Cascading Style Sheets">CSS</acronym>.
</p>

cite

Define o autor ou a fonte de uma citação, podendo, e devendo, ser usado em conjunto comos elemento q e blockquote, que identificam a citação em si.

<p>
  Conforme Martin Fowler disse:
</p>

<blockquote>
  <p>
    Any fool can write code that a computer can understand.
    Good programmers write code that humans can understand.
  </p>
</blockquote>

dl, dt e dd

Estes elementos são usados para criar listas de definição em uma página Web, sendo muito usados, por exemplo, para a criação de FAQs. O elemento dl representa a lista em si, enquanto os elementos dt e dd representam o termo a ser definido e a sua definição, respectivamente.

<dl>
  <dt>Ruby</dt>
  <dd>Linguagem de script orientada a objetos e criada por Yukihiro Matsumoto.</dd>

  <dt>Ruby on Rails</dt>
  <dd>Framework Web desenvolvido com a linguagem de programação Ruby</dd>

  <dt>ActiveRecord</dt>
  <dd>Um dos principais sub-frameworks do Ruby on Rails</dd>
</dl>

dfn

O elemento dfn é utilizado para marcar um termo que está sendo definido, sendo que pode-se usar o atributo title para resumir a sua definição. A diferença entre o dfn e uma lista de definição, é que o primeiro é utilizado para marcar uma definição isolada no texto, enquanto o segundo agrupa várias definições em uma lista.

<p>
  O <dfn title = "Framework Ruby">Merb</df> é um framework Web escrito em Ruby.
</p>

Conclusão

Existem muitos elementos no XHTML/HTML além daqueles que são amplamente conhecidos, e uma vez que estes elementos adicionais são mais precisos quanto à semântica do seu conteúdo, não há porquê não usá-los. Dessa forma, suas páginas Web ficarão mais corretas semanticamente, o que significa uma maior acessibilidade.

Além disso, não se limite aos elementos extras mostrados aqui, uma vez que a idéia deste post era apenas mostrar através de exemplos que quase sempre há um elemento mais preciso para marcar o seu conteúdo. Portanto, quando tiver dúvidas se está usando o elemento correto em sua página Web, pesquise pare descobrir se não há uma opção mais adequada.

Por fim, embora alguns destes elementos possuam um estilo padrão definido pelo browser, a regra de ouro continua valendo, ou seja, para definir a apresentação deles você deve usar o CSS.

No related posts.

A maldição do outline no firefox

Veja a imagem acima. Se você usa o Firefox, com certeza já viu esse pontilhado ao redor de algum botão. Sabe por que eu o odeio? Porque ele é obrigatório. Não dá pra tirar. Na verdade, até dá pra tirar o outline dos links, mas caso use <input type=”submit”> ou <button> o seu botão vai ter o pontilhado ao redor e não tem nada que você possa fazer.

Só pra constar: Esse outline no firefox não é um bug! Esse marcador é colocado ao redor dos elementos por motivos de usabilidade. A idéia é sempre indicar visualmente onde está o foco. Aí o problema vem quando eu mesmo quero implementar uma forma diferente de indicar o foco, porque ele me obriga a continuar com o outline.

Outro dia eu estava trabalhando no meu projeto secreto com os outros fundadores do blog, e queria fazer um botão super bonito. Eu usei a tag <button> pra poder inserir imagens e texto lá dentro, pra criar um botão tão maneiro que seus olhos explodiriam de prazer. Depois de um tempão criando o botão, me deparei com o outline do firefox, que acabou com todo o mojo.

Sério, um quadrado pontilhado estraga completamente aquele botão super bonito, arredondado, com degradê e efeitos de mouse over.

Se você também se irrita com isso, fique feliz porque você pode pelo menos impedir que o outline apareça nos seus links. Basta declarar o seguinte no CSS para os seus links:

a {
    outline: none;
}

Isso não funciona nos submits e buttons, entretanto. Não adianta nem tentar.

Ah, e se você procurar bastante na internet vai ter algum super gênio por aí sugerindo usar um código em javascript que tira o outline dos botões. Não faça isto em hipótese alguma! O que essa solução em javascript faz é tirar instantaneamento o foco do botão assim que ele recebe foco. Fazendo isso o usuário não pode manusear seu formulário (ou seu botão) pelo teclado, não pode chegar ao seu botão apertando TAB. Ou seja, fica uma porcaria.

Esse tipo de coisa acaba forçando o desenvolvedor a fazer algo totalmente não semântico, como usar <a> pra criar o seu botão de submit, só pra se livrar do outline. Algumas vezes essas bobeiras do navegador vão tão longe que até o google acabou usando <div> pra criar os “botões” que ele usa hoje em dia no Google Reader e no GMail. Pode ir lá olhar, é div!

Até onde eu sei, apenas o Firefox tem essa obsessão por outline. Espero que desistam disso em versões futuras. Na 3.5, quem sabe.

No related posts.

Existem vários outros blogs sobre desenvolvimento por aí, eu sei. Mas todos eles acabam sendo muito parecidos. A maioria dos blogs por aí escreve sobre os primeiros passos no desenvolvimento, e só. Uau, maravilha! Quem procura informações de como fazer um hello world em PHP, ou como instalar o Ruby on Rails no Windows vai achar um monte de fontes, mas e quando a pessoa precisa de uma coisa um pouco mais avançada em português?

Quantidade de Hello World = 0

O Not For Dummies vai fazer jus ao nome. Não vamos cair no lugar-comum, não vamos ficar escrevendo os mesmos posts básicos. Nossos textos não são for dummies, não são pro novato que nem sabe direito o que é XHTML. Isso não quer dizer que só quem é expert vai nos entender, claro. Mas você precisa ao menos já ter se iniciado pra entender do que a gente está falando. Falando assim parece até coisa de sociedade secreta.

O blog vai ser mantido por vários escritores diferentes. Nós reunimos um bom time de escritores e ainda planejamos aumentar a equipe em breve. Outra coisa é que o blog vai ser escrito de uma forma bem descontaída, sempre que possível. Talvez a gente até coloque uma piada no meio de uma explicação séria, só pra não ficar chato.

Acreditem em mim nisso: acompanhem o blog e vocês vão gostar. Eu agarantio!

No related posts.