Book Review: Refatorando HTML – Como melhorar o projeto de aplicações web existentes

Por: Henrique Pereira

Categoria: HTML / CSS / JavaScript, Reviews

Já ouviu falar de refatoração? Refatoração é a melhoria gradual de trechos de código sem alterar o comportamento da aplicação web, site, sistema, etc. O objetivo é remover problemas de código antigo e/ou ilegível (difícil de dar manutenção) para código mais moderno, claro e mais fácil de manter e de realizar manutenções evolutivas.

Dentre as razões para refatorar código podemos notar, por exemplo, a melhoria da acessibilidade, otimização de mecanismos de busca, performance, redução do tamanho de arquivos de HTML e CSS, tornar o código mais claro e fácil de dar manutenção, dar suporte a um novo browser, etc. Refatoração se faz necessária quando você precisa evoluir uma aplicação web mas você não tem dinheiro, tempo ou pessoal suficiente para reescrever a aplicação do zero. Estou falando de aplicação web, mas pode muito bem ser um blog, site institucional, etc.

Li recentemente o livro Refatorando HTML – Como melhorar o projeto de aplicações web existentes (Do original Refactoring HTML: Improving the Design of Existing Web Applications, Ano 2010, 360 páginas, ISBN 9788577806317) do autor Elliotte Rusty Harold publicado pela editora Bookman e achei muito bom e tenho algumas considerações.

Refatoração se faz necessária quando você precisa evoluir uma aplicação web mas você não tem dinheiro, tempo ou pessoal suficiente para reescrever a aplicação do zero.

O livro pode ser encarado como guia de consultas rápido ou um livro de estudo com uma abordagem muito curiosa. Ele tem uma abordagem focada em problemas a serem resolvidos e não na teoria. Ao invés de focar em conceitos, o livro pega dezenas de problemas do mundo real que precisam ser resolvidos e traça estratégias de resolução associando aos conceitos necessários.

Essa abordagem faz com que esse livro não seja indicado a iniciantes. Se você quer começar no mundo do desenvolvimento existem livros mais apropriados. Este é um livro para desenvolvedores intermediários e avançados. E acredite, o Refatorando HTML tem muitas abordagens maduras relacionadas a semântica de HTML, acessibilidade, performance, cache, validação etc.

O livro tem uma divisão lógica excelente. Veja abaixo a estrutura de capítulos:

Capítulo 1 – Refatoração: Descreve o que é refatoração e as razões contra e a favor. Uma aula conceitual sobre o assunto.

Capítulo 2 – Ferramentas: Analisa várias ferramentas de desenvolvimento e a contribuição de cada uma no processo de refatoração. São ferramentas de expressão regular, edição de HTML, validação, etc.

Já os capítulos 3 a 8 são divididos respectivamente pelos assuntos Documentos bem formados, Validade, Layout, Acessibilidade, Aplicações web e Conteúdo. E todos esses capítulos seguem a seguinte estrutura de tópicos:

1. Descrição / Problema: explica qual é o tipo de problema relacionado ao assunto do capítulo
2. Motivação: considerações e defesa sobre o porque é importante refatorar nesse tipo de situação / problema
3. Potenciais perdas e ganhos: considerações que não podem ser ignoradas ao refatorar determinado tipo de problema.
4. Mecânica: Descrição prática (com exemplos de código) de como resolver o problema descrito.

Enfim, achei o livro excelente e me surpreendeu. No início achei bem chato, pra ser sincero, devido a essa abordagem muito prática. Mas depois que você entende a razão e a organização do livro, percebe que é a abordagem que faz toda a diferença. Vale a pena adquirir principalmente se você trabalha com equipes de desenvolvimento que dão manutenção em aplicações web.

O livro “Refatorando HTML” pode ser adquirido no site da própria Bookman ou no Submarino.

Comentários: 4

Web Standards? E agora José?

Por: Henrique Pereira

Categoria: HTML / CSS / JavaScript

Eventualmente converso com algumas pessoas “das antigas” sobre os famosos padrões web, sobre boas práticas de XHTML e CSS e sempre fico me perguntando onde chegamos e para onde estamos indo. Este texto é uma reflexão sobre isso. O que já alcançamos e o que está pela frente.

O passado

Não vou contar de novo a mesma história mas vou resumi-la. A primeira grande guerra dos browsers transformava a vida dos desenvolvedores em um inferno, onde para fazer um site rodar no maior número possível de versões de navegadores era necessário muitas gambiarras, trechos de códigos redundantes etc. Tudo para deixar o mesmo site o mais igual em diferentes navegadores. Esta foi a forma humana mais básica de sentir na pele a necessidade de padrões de desenvolvimento para a internet. Se você não viveu esta época como desenvolvedor, agradeça!

Naquela época desenvolver sites usando tabelas era o caminho mais fácil para fazer um site ser renderizado de forma mais parecida possível em vários navegadores. A popularização e o refinamento das ferramentas visuais de desenvolvimento de HTML ou os chamados editores WYSIWYG também foram outro fator que contribuiu para a popularização do HTML e do desenvolvimento fora dos padrões, visto que estes editores priorizavam a aparência do site renderizado no navegador em oposição a qualidade do código gerado. Esta foi a época do design pelo design.

A virada

A história mostrou para aqueles vovôs da internet na pele algo que doía muito. Gastar tempo e esforço criando códigos redundantes por causa da indústria dos browsers. As pessoas das gerações seguintes, muitas delas, aderiram ao movimentos dos web standards e começaram a desenvolver de forma criativa seguindo os padrões de HTML e CSS da W3C. Surgia uma nova era.

Várias referências na web ficaram conhecidas pelos esforços em popularizar o desenvolvimento seguindo os padrões como o A List Apart, Web Standards Project, Jeffrey Zeldman, Dave Shea, Molly Holzschlag além de Tantek Çelik e Eric Meyer também conhecidos a pouco pelos avanços em Microformats, dentre vários outros. No Brasil os mais populares foram o site do Maujor e o Tableless. No geral o papel que eles tiveram foi o de pressionar a indústria (funcionou apenas em partes) ao chamar a atenção para técnicas de desenvolvimento em CSS, evitando hacks (sim evitando) e usando HTML de forma semântica, em oposição as infames tabelas. O principal valor que todas estas referências tiveram foi o de influenciar e o de liderar essa influência através do ensino de HTML e CSS de forma simples e prática.

Hoje, agradeça aos mecanismos de busca (sic)

Hoje a situação é infinitamente melhor do que a 5 ou 7 anos atrás. Antes era comum pessoas torcerem o nariz ao ouvirem “desenvolver código na mão“. Hoje isso é compreensível. A principal razão da popularização dos web standards foram os mecanismos de busca, mais especificamente o Google e a corrida de ouro que se tornou o SEO. Um site com melhor semântica de HTML ganha pontos nos primeiros resultados de busca.

Sem a popularização dos mecanismos de busca, o mundo inteiro estaria alguns passos atrás em relação aos padrões web. Eu não vejo nenhum outro fator decisivo nessa popularização. As ferramentas de codificação não ficaram semânticas e simples o suficiente para que um garoto de 7 anos consiga fazer uma página válida. Houve avanços é claro, mas desenvolver HTML de forma decente ainda exige saber o que se está fazendo. Pouquíssimos editores de HTML podem ser chamados de “bons”. Então não dá para atribuir a popularização dos padrões web a eles.

Desculpe também não atribuir estes avanços aquelas pessoas que bravamente lutaram em seus blogs para divulgar os padrões web (até mesmo porque me coloco nessa lista), mas o Google foi fundamental para este processo. Obviamente o papel dos blogs foi importante. Importante porque eles praticamente são a fonte de estudo da grande maioria dos desenvolvedores. Mas o papel do Google foi o de mostrar na prática (na pele e no bolso) para quem tem dinheiro (empresas e chefes empresários) os benefícios de estar nos primeiros resultados.

Como nós só seguimos algo pelo benefício que aquilo pode trazer ou pelo medo da coerção, medo da punição, ficar para trás nos mecanismos de busca é sinônimo de “perder dinheiro”. A ditadura dos primeiros 10 resultados impulsionou a popularização dos web standards. A relação custo x benefício deixou muito claro para muitas empresas as vantagens de se desenvolver sites semânticos. E isto está além de validação como os primeiros xiitas acreditavam.

Como está o Brasil nessa história?

A W3C possui um escritório no Brasil e procura estar presentes em eventos como o Campus Party. Essa proximidade é em partes a valorização e a popularização dos padrões no Brasil. Principalmente porque somos o segundo país do mundo em tempo de conexão e o segundo mais presente em redes sociais. Por mais que nem todos os portais sejam 100% semânticos (no sentido estrito do HTML), é difícil encontrar portais desenvolvidos em tabelas nos nossos dias. Argumento suficiente para a mudança de cenário certo?

Acho que nosso desafio em um futuro próximo mais latente e imediato deve ser a acessibilidade. Desenvolvedores experientes sabem que é possível ter um site bem indexado, otimizado para mecanismos de buscas e ainda sim com problemas de acessibilidade. Neste cenário falta pouco é claro, mas pode melhorar. Esse passo é algo mais complicado e precisaria de muita educação e um pouco de coerção.

Começando pela coerção, eu sugiro que o governo brasileiro pudesse punir todos os órgãos públicos que tivessem problemas com acessibilidade. Não vou entrar em detalhes dessa sugestão, é assunto muito complexo, mas já mostra um caminho. E essa punição deveria ser severa. O passo seguinte seria levar essa “lei” para sites de interesse público, turismo, etc. Algo mais difícil. Mas só isso seria suficiente para estimular empresas a quererem desenvolver de modo acessível, girando a economia daquelas empresas capazes de desenvolver com acessibilidade, e estimulando as periferias a fazer o mesmo. Só uma pincelada do que poderia ser feito.

Na Campus Party, a Lêda Spelta do Acesso Digital e Vagner Diniz, gerente do escritório da W3C no Brasil, apresentaram um painel sobre acessibilidade (veja foto abaixo). A palestra em si é o que muitos estão cansados de saber. Não adianta esperar nada de novo. Não existe nada novo para ser visto. O papel deles é o de popularizar o que já existe, a boa e velha acessibilidade. E se todos soubessem o que eles falaram no painel talvez o foco deles hoje seria bem diferente.

Alguma tendência?

Hoje eu arrisco algumas coisas que os desenvolvedores deveriam se preocupar e algumas tendências que na verdade não são “novidades”, e sim caminhos que já se mostram verdes. São sugestões que eu acredito que contribuem para a evolução da web.

• Não pare de estimular os padrões web. Ainda tem gente que nunca ouviu falar de SEO e acessibilidade;
• Use RDF, Microformats, Geo feeds, KML e outros padrões XML based, não por que eles são o futuro definitivo, mas porque esses padrões fazem parte da revolução;
• Não se esqueça especificamente da acessibilidade. Você ainda vai ganhar dinheiro com isso se souber o que está fazendo.
• Popularizar os padrões web de forma simples e compreensível para aquelas pessoas que não colocam a mão no HTML diretamente, como os analistas de sistemas, programadores que pegam o HTML pronto, arquitetos da informação, marketeiros, atendimento e comercial, etc.
• Desenvolvimento mobile. Comece com XHTML-MP!
• Leia sobre usabilidade na web. Está intimamente relacionado com acessibilidade.
• Desinstale o Internet Explorer 6 da máquina de usuários comuns, (valeu o convite Dulça, este texto em partes é uma resposta ao seu convite!). Quanto menos pessoas usarem esse browser obsoleto melhor para o mundo inteiro.

Texto grande, como a muito tempo eu não escrevia. Mas eu não queria picar esta reflexão em mais de uma parte. Alguma consideração?

Comentários: 29

Textos para relembrar

Por: Henrique Pereira

Categoria: Pessoal

Existem alguns textos que eu escrevi tempos atrás, que até hoje recebem muitos visitantes vindos do Google em busca de uma solução rápida e rasteira. Ou então são textos que eu mesmo indico quando vejo alguém que não sabe nem por onde começar a procurar pela solução. Também são textos que eu gostei muito de tê-los escrito. Se você já entende do assunto pode relembrar, e se é a primeira vez que está lendo sobre o assunto, escreva aí nos comentários dizendo o que achou!

Charset e encodings: Sempre tem alguém que me aprece com problemas em acentuação no texto. E este tipo de problema geralmente está relacionado a pessoas desesperadas, porque não sabiam que precisavam se precaver antes de salvar os documentos em ISO-8859-1. Em uma série de 5 artigos você ecnontra informações suficientes para não arrancar os cabelos com codificação de caracteres.

Microformats: escrito em dezembro de 2005, até hoje este texto é ponto de partida para muitas pessoas entenderem o que são os microformats. Escrevi em uma época em que eu não achei nada em português sobre o assunto e nem eu mesmo antes de sentar para escrever sabia exatamente do que se tratava.

Pullquotes em CSS: Uma técnica bem simples de como você pode criar destaques de trechos do textos para dar ênfase a determinada frase nos seus artigos.

Validação e semântica: Texto muito indicado para os novatos no mundo do desenvolvimento não confundirem caçar rolinha com caçarolinha. Validação era algo anos atrás buscado por alguns como o santo graal do desenvolvimento com padrões, mesmo que a semântica não fosse lá essas coisas o importante era validar e colocar o selinho de HTML strict no rodapé. Este texto mostra que as coisas não funcionam muito bem dessa forma.

Nenhum Comentário

A era dos selinhos de validação acabou

Por: Henrique Pereira

Categoria: HTML / CSS / JavaScript

Até um ano atrás eu me divertia colocando selinhos de “validado” do validador da W3C em qualquer projeto que eu pudesse fazer. Há 6 meses atrás eu deixei de fazer isso. Há 3 anos um site 100% compliant com os padrões era relativamente raro aqui no Brasil. Site com selinho de validação era site de geek, era pra poucos. Pra eu utilizá-los hoje não faz mais sentido. O tempo deles já era.

Um dos objetivos da origem destes selos era tornar as pessoas que o desconheciam, curiosas em relação aquilo. Era uma forma de divulgar os padrões web demonstrando que seu trabalho foi desenvolvido de acordo com os web standards. Era uma forma de evangelismo. Ele trazia também certo status, não podemos negar. Hoje padrões web não é mais diferencial. Entre os bons profissionais, conhecer semântica de HTML e saber bem CSS é o mínimo.

Depois que eu vi dezenas de blogs de caras que eu tinha certeza que nem sabiam o que era semântica, com seus sites validados (sim, realmente validados), eu parei de usar. Porque pelo menos eles já estavam no caminho certo, apesar das gafes. É comum no início nos empolgarmos com algumas coisas e cometer erros crassos em outras. Padrões web agora é commodity. A evangelização acabou? Não completamente, mas eu não tenho mais interesse em utilizar os selinhos de validação. Até mesmo porque validação só diz que seu site não possui erros de sintaxe, e não que ele seja 100% compliant. Como milhões de vezes já falado, eu posso ter um site 100% validado pelo validador da W3C e sem nenhuma tag utilizada corretamente.

Acredito que uma forma bem eficiente de evangelismo dos padrões web hoje seja SEO. Prática e não demagógica. A era dos selinhos acabou pra mim. Quer continuar utilizando? Fique á vontade. Eu os vejo mais como um souvenir retrô e nostálgico do que com algum propósito.

Comentários: 26

Tableless vs Web Standards

Por: Henrique Pereira

Categoria: HTML / CSS / JavaScript

<update:date="2006-07-27">
Dando continuidade ao debate pertinente sobre este assunto, o Diego Eis deixou sua contribuição com o texto quase homônimo em Web standards vs Tableless
</update>

Já faz muito tempo que não vejo uma discussão sobre esse assunto que na verdade eu sempre quis dar um pitaco. A discussão aqui trata-se sobre o que na prática cada um destes termos (tableless e web standards) representam na história recente da web e a forma com que eles se propagaram. Opiniões contrárias são muito bem vindas apesar que pretendo levantar tópicos mais históricos e objetivos e menos subjetivos.

Antes de começar, gostaria de dizer claramente (para os não iniciados no assunto) de que essa discussão trata-se da utilização dos termos “tableless” e “web standards” e não representa uma avaliação do site Tableless.com.br criado pelo Diego Eis e Elcio Ferreira que são amigos e estão do lado do bem da força (o melhor lado em que poderiam estar). Ou seja, isso não é um oposição ao nome do site deles (até eu queria ser dono desse domínio!) e sim ao falso conceito propagado sobre o termo “tableless“. Por isso sem comentários passionais, ok?

Tableless

O termo “tableless” (do inglês “sem tabelas“) foi criado em contrapartida a uma técnica antiga (e utilizada até hoje na verdade) para estruturar os sites utilizando-se tabelas para conseguir controlar a aparência dos elementos em um site. Em meados da década de 90 quando os browsers ainda não haviam implementado nada de CSS, todo o posicionamento dos elementos e a aparência deles era toda controlada através de marcação e delarações inline. A técnica de spacer (o uso de um gif transparente para empurrar elementos e deixá-los em um local específico) era amplamente utilizada. Naquela época era compreensível a utilização destas técnicas devido a ausencia de implementações de CSS nos browsers, considerando que o nível 1 do CSS foi publicado em 1996 e o nível 2 somente em 1998.

Antes disso então, todas as técnicas hoje consideradas sujas, eram verdadeiros macetes (e não gambiarras) para se alcançar o sucesso na web. Mesmo que desde o início o HTML não tivesse sido criado com estes propósitos, a necessidade e demanda por sites com design mais elaborado acabou fortalecendo muito a utilização dessas técnicas por muito tempo. Até as ferramentas de desenvolvimento foram aos poucos se adequando a esta metodologia de desenvolvimento o que acabou ficando conhecido como WYSIWYG.

Passados os anos e após praticamente todos os browsers em uso já tivessem implementado boa parte de CSS, os desenvolvedores continuaram por um tempo a criar sites como faziam anos atrás. O termo “tableless” então, surge em oposição a esta visão de desenvolvimento que utiliza tabelas (e não CSS) para estruturar e controlar a aparência de um site.

Web standards

Web standards é um termo mais amplo que refere-se aos padrões web como um todo e não somente as linguagens de marcação e CSS. Outra coisa importante é que “web standards” não é um termo de oposição como é o termo tableless, até mesmo porque ninguém defende racionalmente algo do tipo “não aos padrões web”.

A organização responsável por estes padrões é a famosa W3C e segui-los (web standards), nada mais é do que construir sites que sigam as especificações por eles propostas e implementada por desenvolvedores e pela industria mundial que está ao redor da web. Se você ainda está na fase de questionar a necessidade de “padrões” leia o texto “seguindo os padrões” do Diego Eis.

Este conceito de web standards envolve a utilização das diferentes tecnologias que constituem a web de forma que garanta a interoperabilidade da prórpia web como um todo. Isso envolve portanto um amplo conjunto de boas práticas para o desenvolmento web em diversas áreas que envolve linguagens de marcação (XML, HTML, XHTML), linguagens de apresentação (CSS), semântica (RDF), linguagens de comportamento (DOM), acessibilidade (WAI), protocolos (HTTP), mobile ( MWI) dentre outras. Em resumo, um site que segue os web standards preza pelos vários aspectos que o constitui e não somente o aspecto estrutural sobre usar <div> ou <table> no desenvolvimento de um site.

Tableless vs Web Standards

Acho que é neste ponto em que as diferênças se acentuam. E espero que você entenda a diferença entre os dois termos antes de qualquer avaliação dessa discussão. Algumas perguntas retóricas de exemplo vão demonstrar melhor essas diferenças.

Um profissional inexperiênte que nos dias de hoje sem conhecimentos mínimos de semântica mas que consegue a façanha de converter seu site feito em tabelas para algo cheio de divs (o cara consegue fazer uma convenção internacional de divs em uma única página) e utilizando CSS, significa que este site segue os padrões? Significa que ele é “tableless” simplesmente pelo fato de não utilizar tabelas para estruturar um site? Será que somente pelo fato do cara não utilizar tabelas mas coloca uma div com uma classe em cada cantinho do site dele, significa que este segue os web standards?

Seguindo os web standards muito além do tableless

Um site que não utiliza tabelas para estruturar um site (teoricamente um site “tableless”) mas que ainda usa algo do tipo <div class="titulo">Titulo do artigo aqui</div> no lugar de um <h1> ou <h2> é tão contrário aos web standards quanto aquele que utiliza tabelas para estruturar o site. Alguém discorda disso neste ponto? Se considerarmos o aspecto semântico, o <div> (que serve para criar estruturas lógicas) bem como a tag <table> (que serve para exibir dados tabulares) podem ser semanticamente vazias quanto qualquer outra tag utilizada no contexto errado. Podemos colocar no bolo também a questão da validação de um site, que nada pode dizer sobre ele, se segue ou não os padrões.

Tableless é um ótimo marketing (principalmente para o Diego que é sortudo dono do domínio no Brasil), é uma palavra com um fundo histórico interessante que representou uma oposição a uma metodologia de desenvolvimento que marcou a história recente da web, mas que não diz o que web standards diz. Uma não deve ser utilizada para expressar o que a outra diz.

Comentários: 43

A relevância dobrada

Por: Henrique Pereira

Categoria: HTML / CSS / JavaScript, Marketing / Comunicação

Um hábito quase que religioso que eu tenho com o meu site é o de analisar o tráfego do Revolução Etc periodicamente e procurar mensurar resultados do tráfego gerado pelo Google. Sim, basicamente só os do Google. Recebo também vários outros visitantes vindos do MSN e do Yahoo respectivamente, mas nada se compara ao gigante dos buscadores. Geralmente antes de publicar algum artigo eu faço buscas pelas palavras que fazem parte do título escolhido e verifico se meu site se encontra em alguma posição. Em seguida eu anoto pra não me esquecer e dias depois eu retorno com a mesma busca para observar se ouve ganhos e quais os fatores reais que resultaram nisso. Os resultados tem sido bastante satisfatórios. Aqui vai algumas dicas.

Costumo pensar nos sites que são desenvolvidos seguindo os web standards como sites de “relevância dobrada”. Enquanto não vivemos em um mundo perfeito de uma web semântica e em meio a milhares de sites obsoletos e mal desenvolvidos, seguir os padrões web é como ter os dois olhos e uma visão perfeita em uma terra só de cegos. De fato, na prática, uma palavra estratégica vinda de um site otimizado e seguindo os padrões possuiu até muito mais do que o dobro de relevância do que sites desenvolvidos pensando apenas na aparência e nada na arquitetura. Mas isso também depende de vários fatores além dos web standards.

O primeiro ponto a ser observado é a concorrência. Se existem vários sites sobre o mesmo assunto e todos eles possuem um código semântico e bem otimizado, a batalha a ser travada pela primeira página do Google (não vale pagar nenhum centavo de AdWords é claro) é levada ao nível da popularidade e da quantidades de links existentes na web apontando para determinado site. Muitos links para o seu site na web é o termômetro da popularidade. Mas ao mesmo tempo um site muito popular pode ceder lugar para um site que não seja tão popular assim se ele possuir um código muito mais otimizado que o do site popular. Não se pode controlar essas variáveis, mas podemos observá-las e aprender de forma estratégica a dançar a música dos mecanismos de busca.

Devo confessar que existe um horizonte de incerteza em toda essa história de search engine optimization (SEO) mas muito disso pode ser controlado em determinados contextos. Neste ponto eu estou desconsiderando as técnicas “sujas” de otimização e considerando apenas as corretas. Cada caso deve ser analisado separadamente e se alguém te procurar prometendo demais, esqueça. Quanto mais escasso é um assunto, e quanto menos informação existe sobre determinado assunto na web, mais fácil é pegar os primeiros lugares nos mecanismos de busca com um site bem otimizado e seguindo os web standards à risca. Mas quando existe muita informação sobre determinado assunto, e se muitos sites são desenvolvidos com objetivos que privilegiem a informação, a primeira página de nenhum mecanismo pode ser prometida, a não ser que você recorra ao AdWords. Caso contrário milagres não podem ser feitos mas medidas estratégicas a medio e longo prazo podem ser elaboradas. E quando nós falamos de resultados, conseguir estar na primeira página do Google em muitos casos será quase que impossível. Mas se um site de forma estratégica é planejado e analisado em um contexto de extrema concorrência e consegue sair sai da página 1859º e vai para a 6º ou 7º página do Google, isso já pode ser considerado um grande sucesso.

Outro fator de influência no posicionamento nos mecanismos de busca é o tempo. Sites mais relapsos em relação ao conteúdo, sites menos otimizados mas que são bastante populares, com o tempo, o hanking passam a dar lugar aos sites que são mais fieis em publicar sobre um determinado assunto. A popularidade na web sempre será um fator importante por várias razões. Primeiro porque os sites que geram muito tráfego tem a probalidade de serem mais relevantes sobre determinado assunto do que os sites menos populares e menos linkados. Ou seja, se muitas pessoas linkam e trafegam em determinado site é porque algo ele tem de relevante para justificar isso. Naturalmente. A popularidade é uma espécie de credencial de relevância.

O segredo para um tráfego de visitantes alto é investir em bom conteúdo, bons relacionamentos e fidelidade ao seu nicho ideológico. O tempo faz o resto. Ou seja, a solução é procurar também ser popular pelo valor do seu trabalho, pelo valor do conteúdo do seu site em si. Escrever textos irrelevantes pensando exclusivamente em mecanismos de busca não vai criar fidelidade de usuários e qualquer tipo de otimização sempre será em vão. A otimização dos mecanismos de buscas (SEO) é um meio e não um fim em si.

No final das contas se o objetivo da otimização é mostrar que você possuiu informação relevante sobre determinado assunto, a melhor maneira de começar isso não é se preocupar com a otimização e sim com o próprio conteúdo e a qualidade do seu trabalho que será compartilhado na web. A otimização é uma maneira muito importante de aproximar seu conteúdo ao seu público específico nos mecanismos de busca, mas se seu conteúdo não for realmente bom e relevante será apenas um ordinário em roupa de rei. E por pouco tempo.

Estatíticas e curiosidades

Esta parte deste texto está fadada a estar desatualizada em um prazo muito curto de tempo. Qualquer estatísticas de posicionamento de um site no Google está destinado a estar desatualizado logo após sua publicação. As informações listadas abaixo, podem ter variações para cima ou para baixo. De qualquer forma, compilei estas informações para deixar documentado algumas estatísticas curiosas sobre o Revolução Etc do mês de maio de 2006. Todas estas estatíticas estão relacionadas a buscas feitas no Google com a opção “páginas em português” selecionada.

A principal palavra que os visitantes vindos do Google digitam para chegar no meu site é a palavra “revolução”. Só no mês de maio mais de 1168 palavras diferentes foram digitadas no Google e que geraram visitas diretas. A palavra revolução correspondeu apenas a 2% dos visitantes.

Mesmo tendo escrito apenas dois artigo em que trazem o termo “web 2″ no título, até esta data um dos meus artigos está em 2 lugar na primeira página do Google. Uma das razões foi a quantidade de links em vários outros sites que este artigo recebeu aumentando sua popularidade.

A palavra “sorrir” se não me engano foi utilizada apenas uma única vez no meu site o que levou meu artigo a estar na primeira página do Google em apenas 5 dias. No mês de maio 8 pessoas chegaram ao meu site digitando a palavra “sorrir” no Google. Detalhe: meu artigo foi escrito no dia 19 de maio e estas visitas vieram em apenas 12 dias (desconsiderando o tempo de indexação do Google) através de uma palavra que é completamente irrelevante considerando-se os objetivos do meu site.

No artigo “Designing for Web 2” eu utilizei uma infame expressão na seguinte frase: “Valorizar design acima da organização da informação é mast**** na frente do espelho.” Coloquei asteriscos no restante da palavra por não ter o mínimo interesse em concorrer com sites que tratam sobre o assunto. Esta foi a única instância em que esta palavra apareceu no meu site, eu prometo. Durante o mês de maio esta palavra podia ser encontrada na segunda página do Google o que acabou resultando em 8 visitas. Curiosamente a frase digitada em todas as 8 visitas foi “como se mast****”. Esta é uma grande prova da relevância dobrada.

Neste momento, meu site se encontra na primeira página do Google na busca realizada em português nas seguintes palavras e/ou frases:

web standards, media types, CSS, microformats, revolução, henrique, charsets, encodings, dicas de css, !important, comentários condicionais, segredos google, semântica, markup, sorrir, target blank, tolltip, doctype, DTD, technorati, paypal, UTF-8, folksonomia, delicious, mime type, web 2.0, folha de estilos, bloglines, editplus, entitie, feedburner, hCalendar, hCard, ampersand, hReview, IE7, quirks mode, semântica web, unicode, validação

Este é apenas um exemplo simples do que um site que segue os web standards e é construído com ênfase na informação mais do que na aparência pode alcançar.

UPDATE

Leia este post do Élcio sobre como você pode acompanhar a relevância do seu site relacionado a algumas palavras. No Robô de Google Ranking você digita no campo busca algumas palavras (separadas por vírgula) relacionadas ao seu site. Embaixo você digita a sua URL e faz a busca. Um script vai verificar qual a posição em que o seu site está relacionado a cada palavra digitada na busca. Depois de completada a busca você ainda pode assinar um feed para sempre acompanhar as alterações do seu ranking. Simples e fantástico!

Comentários: 20

Doctype – DTD – Document Type Definition

Por: Henrique Pereira

Categoria: HTML / CSS / JavaScript

Introdução

Um documento de (X)HTML seguindo os padrões à risca nunca é completo sem utilizar uma declaração de tipo de documento corretamente. O Doctype de um documento deve ser o primeiro passo a se considerar antes mesmo de aprender qualquer tipo de sintaxe das linguagens de marcação como XML e XHTML. Porque é a escolha do doctype que vai influenciar no tipo de marcação que você deverá ou não utilizar. Se você quer aprender HTML 4 de forma a seguir corretamente todos os padrões você tem que trilhar um determinado caminho, e se quiser aprender XHTML também seguindo à risca os padrões, você deve seguir outro caminho com algumas diferenças.

Basicamente, tanto para o HTML quanto para o XHTML, você pode trabalhar com 2 tipos de doctypes, o transitional e o strict. Eu vou desconsiderar o frameset intencionalmente. A razão disso é que se alguém nos dias de hoje ainda trabalha com frames, usar um doctype mais ou menos apropriado não vai fazer diferença nenhuma no resultado final do trabalho na minha opinião. Se os frames não estão presentes nas recomendações para um documento strict, o que teoricamente deve apenas ter a sintaxe estrita (strict) de determinada linguagem, não vou considera-lo aqui.

Definição

“Doctype” é o acrônimo de “Document Type”, também conhecido como DTD (Document Type Definition). É o doctype que diz para os user agents qual o tipo de documento que ele tem que interpretar (parsing) e como ele deve renderizar esse documento. A definição de um tipo de documento (doctype) informa quais as regras que os user agents devem utilizar do que é e o que não é permitido em uma determinada versão de um XML e de um (X)HTML. É uma forma de dizer a eles quais são as regras que aquele documento pretende seguir e quais as regras que o browser deve utilizar ao analisar (parsing) o documento.

Diferenças CONCEITUAIS entre doctypes transitional e strict

O nome dos doctypes revelam o que são e para o que servem. O transitional é utilizado para quem está fazendo uma “transição” entre uma forma antiga de marcação para uma mais moderna e mais apropriada. Então se seu site não está livre dos velhos hábitos do passado, se a migração para strict seria muito trabalhosa, se seus documentos não seguem as regras á risca, você pode usar um doctype transitional. Você pode utilizar o doctype transitional enquanto você ainda utiliza muitas tags e marcações de forma inapropriada. Mas seu alvo final com o tempo deve ser escrever um documento que siga 100% os padrões de forma precisa com um doctype strict. Este é o alvo a ser seguido tanto para HTML 4 quanto para o XHTML 1, utilizar um doctype strict.

Para entender isso melhor vamos ver o que está escrito no Document Type Definition do HTML 4:

This is HTML 4.01 Strict DTD, which excludes the presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

Traduzido fica: “Este é o DTD do HTML 4.01 Strict, que exclui atributos apresentacionais e elementos que a W3C presume remover em estágios a medida que o suporte a folhas de estilos amadurece. Os autores devem usar um DTD Strict quando possível, mas utilize o DTD transitional quando precisar manter atributos e elementos apresentacionais.”

A principal razão de ainda existir outros doctypes que não sejam o strict, é porque velhos hábitos ainda persistem no desenvolvimento para web ao colocar sintaxe de apresentação no documento (X)HTML. A recomendação da W3C é que tudo que seja relativo a apresentação seja feito através de uma (ou mais de uma) folha de estilos externa. Se pensarmos em uma linguagem de marcação como o XHTML de forma estrita a seguir os padrões, um doctype transitional não deve nem ser considerado como uma “recomendação” e sim apenas como uma “aceitação” temporária por razões de retro-compatibilidade até o completo amadurecimento do desenvolvedor e da própria web.

Diferenças PRÁTICAS entre doctypes transitional e strict

Na prática, em um documento de HTML 4 com doctype transitional por exemplo, você pode usar uma dezena de tags e atributos como target, bgcolor, align, iframe, center etc mesmo que não sejam mais uma recomendação. Veja uma lista completa do que pode ou o que não pode organizado por doctype. A tag <center> por exemplo serve apenas para centralizar algum elemento. Ela não é uma recomendação da W3C por que trata-se de uma tag apenas para alterar a forma como um elemento deve ser exibido no browser, o que pode ser feito apenas por CSS, e não possui nenhum significado semântico. A tag <strong>, ao contrário do que muitas pessoas pensam, não serve para colocar texto em negrito, o que a caracterizaria como apenas uma tag de apresentação. A tag para negrito era <b> e caiu em desuso. A tag <strong> tem o significado semântico de “grande ênfase” e <em> tem o significado de “ênfase” apenas.

Documentos que utilizam doctypes strict na prática excluem qualquer tipo de tags e atributos com propósitos de apresentação, e doctypes transitional são mais permissivos e tolerantes a utilização de elementos e atributos que não são mais aceitos e recomendados na versão strict da linguagem.

A validação e os doctypes

Se seu documento possuiu algum tipo de sintaxe contrária as regras permitidas para o tipo de doctype que você está utilizando, isso é o que chamamos de “erro de sintaxe”. Óbvio não? Você não esperava outro nome não é mesmo? Ou seja, se você escolheu um doctype strict para seu XHTML, certas coisas que você estava acostumado a aplicar no seu HTML, seja ele strict ou transitional, não poderão ser mais feitas. O critério do validador de HTML da W3C para avaliar um documento é o doctype utilizado. A sintaxe é verificada de acordo com as normas permitidas para cada DTD escolhido. Se você escreveu determinado documento com uma sintaxe correta para XHTML mas utiliza um doctype de HTML 4 Strict, o validador vai acusar erros de sintaxe, mesmo que seu documento esteja 100% exato conforme a versão superior do HTML.

Se seus documentos possuem erros de sintaxe, os browsers vão ignorá-los e tentar renderizar seus documentos da forma em que cada um deles achar mais apropriado. Essa é a única importancia em manter um código válido e sem erros de sintaxe para não deixar nas mãos do browsers a escolha de como ele deve renderizar seu documento. E lembre-se que semântica nada tem haver com validação.

Na década de 90, devidos as implementações que cada nova versão dos browsers recebiam, e por causa da retro-compatibilidade, principalmente do Internet Explorer com as versões anteriores, os browsers foram treinados a renderizar os documentos que encontravam sem doctype a sua própria maneira. Se você não declarar nenhum tipo de doctype no seu documento, cada browser vai renderizá-lo de um forma diferente. Isso permitiu a expansão do HTML como uma tag soup. Isso ainda acontece com o HTML e o XHTML enviados com o mime-type de text/html. Para mais informações sobre mime-types, leia meu texto sobre “XHTML Media Types“. As diferentes formas de renderização são chamadas de “browsers modes”. Leia meu texto “O que é Quirks Mode?” para mais informações.

No caso do XML e do XHTML (enviado com o mime-type de application/xhtml+xml) essas variações de browsers modes não existem. Os browsers que suportam este tipo de mime-type possuem apenas a forma strict de renderização. Apenas duas coisas podem acontecer em documentos enviados como application/xhtml+xml. Ou o documento é exibido corretamente, se estiver tudo certo, ou nada dele é exibido. Se o browser não encontrar nenhum doctype, ele simplesmente não exibe nada. Apenas mostra uma mensagem de parser error na tela. Ele não tenta interpretar o documento a sua própria maneira como acontece com documentos com mime-type de text/html. Em linguagens baseadas no XML você realmente tem que saber o que você está fazendo caso contrário pode ser um completo desastre.

Para finalisar, veja abaixo os doctypes listados que podem ser encontrados nas referências normativas do HTML 4 e do XHTML 1.

Doctypes do HTML 4 :

A referência normativa (http://www.w3.org/TR/html4/sgml/dtd.html) do HTML 4 diz que você pode utilizar 3 tipos de doctype:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/html4/loose.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
  "http://www.w3.org/TR/html4/frameset.dtd">
 

Doctypes do XHTML 1:

A referência normativa do XHTML diz que você pode utilizar 3 tipos de doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

Referências:

• DTD XHTML
• Well-Formed XML Documents
• XHTML 1.0 Elements Attributes by DTD
• Transition vs Strict Markup
• XHTML: Differences between Strict & Transitional
• Comparison of Strict and Transitional XHTML
• CSS Mastery – Andy Buddy

Comentários: 21