Desenvolver sites e aplicações pra web usando os padrões web significa, basicamente, usar cada tecnologia para o propósito único para o qual ela foi desenvolvida. Com isso, acabamos por organizar nosso código em “camadas”. São elas conteúdo, apresentação e comportamento. Vamos ver, separadamente, o que significa, para que serve e como desenvolver cada camada separadamente.
Neste texto vamos dar uma rápida passada pelas duas primeiras camadas, a de conteúdo e a de apresentação. A de comportamento fica para um próximo post.
Conteúdo
A camada de conteúdo é, sem sombra de dúvida, a mais importante de todas. É onde colocamos a parte mais preciosa do nosso site, aquilo que realmente faz a diferença no fim das contas — o conteúdo (surpresa!).
Para desenvolver essa camada usamos as chamadas linguagens de marcação de hipertexto, no nosso caso HTML ou XHTML.
O desenvolvimento deve sempre começar por esta camada. Antes de se preocupar com a parte visual ou comportamental de um site ou aplicação, deve-se estruturar com o maior cuidado e critério possível o conteúdo.
Quando você for começar a realmente pôr a mão na massa e escrever código, mesmo que já tenha um layout definido, tente não pensar na parte visual. Se atenha ao conteúdo. Como esse conteúdo é dividido? Que partes compõem esse conteúdo? Qual a função de cada parte do conteúdo dentro do site?
Tendo isso em mente, ordene essas partes por ordem de importância e relevância para os usuários. Certifique-se de que o que é mais importante seja colocado antes no código.
Preocupe-se com a semântica. Use os elementos certos para marcar o conteúdo. O HTML te dá uma quantidade consideravelmente boa de elementos para estruturar o seu conteúdo.
Abra o seu HTML puro em um browser. O que você vê na tela faz algum sentido? Verifique se é possível navegar tranquilamente pelo conteúdo usando o teclado.
Lembre-se, todo o restante do processo de desenvolvimento do seu site vai depender de como o seu conteúdo está estruturado. Se as coisas não estiverem bem estruturadas nessa camada, você vai, certamente, ter problemas no futuro. Revise o seu código, mexa no que tiver de ser mexido agora. Mais tarde pode ser tarde demais e o tempo que você vai perder será muito maior, acredite.
Estando tudo certo com a estruturação do conteúdo, podemos passar para a próxima camada.
Apresentação
Agora é a hora de aplicar aquele belo layout que você (ou o seu designer) criou para tornar o seu conteúdo mais atraente.
Nessa camada, vamos usar o CSS para definir propriedades visuais para cada elemento do seu conteúdo.
O mais importante aqui é manter as coisas simples. Evite usar propriedades que possam causar problemas em diferentes browsers. Em geral é possível criar qualquer tipo de layout usando apenas aquilo que é largamente suportado.
Resista à tentação de mexer na camada de conteúdo para satisfazer uma necessidade especificamente de apresentação. Pense um pouco mais. A solução pode ser mais simples do que você pensa. Use esse artifício apenas em casos de desespero total, quando tudo o mais falhar.
Lembre-se, se você tem um problema, é grande a chance de que alguém já tenha tido o mesmo problema e o tenha resolvido. Também é grande a chance de que esse alguém tenha publicado, em algum lugar, a solução, quem sabe, com uma bela explicação. Uma busca no google é sempre uma boa pedida.
Teste freqüentemente o resultado, de preferência em diversos browsers. Principalmente nos mais usados (IE, Firefox, Opera e Safari).
Quer uma dica? Use como base de testes um browser que tenha um melhor suporte aos padrões web. Firefox é uma bela opção para os usuários de windows. Para quem usa Mac, o Safari é a melhor opção.
O Internet Explorer é, de longe, o browser mais usado, mas tem um suporte bastante precário aos padrões. Por isso, se você tomá-lo como base para o seu desenvolvimento, será muito mais complicado consertar as falhas que serão notadas nos outros browsers.
Se você fez tudo direitinho até aqui, você tem um site bem estruturado e visualmente agradável e consistente.
Update: Leia o post sobre a camada de comportamento.
É importante conhecer a nomenclatura correta e, principalmente, usá-la corretamente, quando tratamos de um determinado assunto.
Uma nomenclatura freqüentemente confundida pelos usuários é a do HTML. É comum ouvir (ou pior, ler) pessoas dizendo, por exemplo, “tag alt”. Isso está errado.
Mas, então, o que é uma tag, o que é um atributo e o que é um elemento em HTML? Simples. Vamos lá:
- Elemento
- Um elemento é uma estrutura semântica, composta de: tag de abertura, conteúdo e tag de fechamento.
Um parágrafo, por exemplo, é um elemento. Da seguinte forma:
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
Ao encontrar essa estrutura, um user-agent vai entendê-la como sendo um parágrafo. Simples assim. - Tag
- Tag é um código usado para marcar o início e, onde for requerido, o fim de um elemento HTML. Há, como exposto acima, tags de abertura e de fechamento. Uma tag de abertura é representada por um sinal de menor (<), um nome de elemento HTML, e um sinal de maior (>) (ex. <p>) e deve ser colocada imediatamente antes do início do conteúdo do elemento. Uma tag de fechamento se diferencia de uma de abertura apenas por uma barra (/) antes do nome do elemento (ex. </p>) e deve ser colocada imediatamente após o fim do conteúdo do elemento.
- Atributo
- Atributos servem para definir uma propriedade de um elemento HTML. Os atributos HTML devem ser colocados sempre na tag de abertura, logo após o nome do elemento, precedido de um espaço e é composto de um nome de atributo, um sinal de igual (=) e um valor de atributo, cercado por aspas duplas (") ou simples (‘)
Um bom exemplo de atributo é o id, que serve para identificar, de maneira única, um elemento dentro de um documento HTML. Exemplo:
<p id="nome">
Outro bom exemplo é o atributo href, usado para definir uma referência de hipertexto (link) em um elemento A ou LINK. Exemplo:
<a href="http://brunotorres.net/">
A “tag alt” referida no início do texto é, na verdade, um atributo, usado para definir um texto, que deve substituir uma imagem, caso a mesma não esteja disponível ou não seja suportada pelo user-agent (alt é abreviatura de “alternate”, que significa “substituto” e não “alternativo”, como se pensa em geral). Exemplo:
<img src="/img/bruno_um_milhao.jpg" alt="Foto do Bruno Torres com um milhão de dólares">.
Como vocês puderam (assim espero) ver, é bem simples distingüir elementos, de tags, de atributos.
O Roger Johansson já escreveu sobre isso, mas na língua de Shakespeare. Aqueles que puderem ler, vale a pena.
O método de requisição é o primeiro dado enviado pelo user-agent ao fazer uma requisição HTTP ao servidor.
Vamos usar o código de exemplo do post de introdução ao protocolo HTTP.
Vejamos a primeira linha de uma requisição HTTP de exemplo: GET / HTTP/1.1
Essa linha informa que a requisição se trata de uma recuperação de dados (método GET), usando o protocolo HTTP, versão 1.1. Esse método, GET, é justamente o primeiro de que vamos tratar, principalmente pelo fato de ser ele o método usado como padrão por qualquer user-agent e, por isso, ser, de longe, o método mais usado. O método GET tem duas propriedades importantes: deve ser seguro (safe) e idempotente (idempotent).
Ser seguro significa que o método não deve ser usado para produzir mudanças nos dados que estão no servidor. Ou seja, nunca se deve usar o método GET para, por exemplo, atualizar um dado em um banco de dados.
Idempotente quer dizer que múltiplas requisições ao mesmo recurso usando o método devem ter o mesmo resultado que teria uma requisição apenas. A título de curiosidade, idempotente é a propriedade de um número que, multiplicado por ele mesmo, tem ele mesmo como resultado (n x n = n), em termos de números reais, apenas 0 e 1 têm essa propriedade.
Em termos de métodos de requisição HTTP, os métodos GET, HEAD, PUT e DELETE são os que possuem a propriedade de ser idempotentes. Claro que há exceções. Por exemplo, digamos que o recurso requisitado seja a home page de um blog, que mostra os posts e o número de comentários submetidos em cada um. Se, ao mesmo tempo que você faz suas requisições GET um outro usuário postar um comentário ou mesmo o autor do blog postar um novo texto, o resultado da requisição será diferente.
O que não pode acontecer é as suas requisições resultarem em mudanças no conteúdo da resposta. A função do método GET é pura e simplesmente recuperar um recurso existente no servidor. O resultado de uma requisição GET é “cacheável” pelo cliente.
Ou seja, se o seu browser possui a capacidade de guardar cópias das páginas visitadas para uso posterior, ou seja, tem cache, após uma requisição GET bem sucedida, o conteúdo da resposta (headers e corpo) serão guardados neste cache e em uma requisição posterior ao mesmo recurso, caso sejam verificadas algumas condições (que veremos quando formos falar especificamente sobre cache), não será necessário baixar novamente todo o conteúdo do recurso. A versão em cache é usada. Você estará usando o método GET quando:
- digitar uma URL na barra de endereços do seu browser e apertar Enter
- Seguir um link em uma página na web, email, programa externo ou nos bookmarks (favoritos) do seu browser
- Submeter, em uma página web, um formulário cujo método seja get (
method="get")
No caso de formulários HTML, cabe aqui uma observação: caso o método do formulário seja GET, as informações submetidas estarão explicitamente expostas ao usuário por meio de uma query string na URL que aparecerá na barra de endereços do browser. Além disso, deve-se tomar cuidado com formulários usando esse método porque, caso a quantidade de informação submetida seja grande demais, pode resultar em problemas em alguns user-agents que, por questões de segurança, limitam o tamanho de URL que pode ser aceito. A especificação oficial do método GET pode ser lida (em inglês) na página de definição dos métodos HTTP, no site do W3C.
Há muito tempo vocês me escutam contar essa historinha de que vou escrever uma série intitulada “O básico da web” e nada acontecer.
Realmente, vontade não tem me faltado pra escrever esta série, mas alguns fatores tem feito com que eu a deixe sempre pra depois.
Primeiro, o tempo tem estado meio curto, mas vou tentar não usar mais essa desculpa, porque já virou cliché; segundo, o tipo de texto que eu quero escrever nesta série me parece não caber no meu blog principal, porque são textos que pretendem tratar realmente do básico, focando em leitores com um nível de conhecimento mais baixo sobre as tecnologias e técnicas para a web e o meu público, em geral, já tem um conhecimento maior, e ficaria entediado com esse tipo de texto.
Portanto, surgiu a idéia de criar este blog. Tanto para me forçar a escrever a famigerada série quanto para conquistar um público diferente e tentar ajudar o máximo de pessoas a entender como as coisas funcionam na web e, obviamente, aprender coisas novas e compartilhá-las com vocês.
Estou pensando em usar um método de escrita parecido com o que o Joel Spolsky usou (não sei se ainda está usando) em sua série de artigos sobre design.
É o seguinte, quando nascer o texto, vou publicá-lo no ato, como um draft (e isso será notado em algum lugar para que fique bem claro para o leitor que o texto ainda não é uma versão final) e, após a publicação, vou lapidando, fazendo edições no texto até chegar a uma versão final (que, mesmo sendo final, ainda pode sofrer alterações se for realmente necessário). Essas modificações poderão facilmente ser acompanhadas pelos leitores via RSS e, talvez, por email, se assim quiserem.
Não sei se vai funcionar, mas vou testar. Assim que este blog começar a ter leitores, vou medindo, a partir dos comentários, o nível de satisfação com o método e, se for o caso, não terei problema algum em mudá-lo.
Vamos ver no que dá. Essa semana ainda vou postar alguma coisa por aqui. Sejam bem-vindos e sintam-se em casa.
