Após usar TextMate e CSSEdit, encontrei o Coda e testei durante seu período de avaliação… Foi o suficiente para comprá-lo! A licença custa U$99 e pelo que oferece vale muito, ainda mais se compararmos ao Dreamweaver.

Resolvi gravar um vídeo (screencast) demonstrando algumas qualidades do aplicativo mas, obviamente, há diversas outras funcionalidades interessantes que optei por não mostrar:

Após descobrir estas e outras qualidades, percebi que o melhor editor de códigos para Mac OS é o Coda, principalmente após descobrir que ele fazia find/replace de múltiplas linhas em diversos arquivos

Um dos grandes problemas do Microformats é a falta de divulgação por parte dos desenvolvedores e, talvez por isso, não é tão comum vermos projetos comerciais utilizando a técnica, mesmo que seja tão simples de usá-la. Desta forma seu futuro foi colocado em questão, já que o HTML 5 está sendo cada vez mais discutido e, com isso, muitos imaginam que os Microformats não terão mais utilidade… Será? Analisemos cada uma das partes para tirarmos nossas conclusões!

HTML 5

A quinta versão do HTML vem aí para solucionar diversos problemas que surgiram com a crescente diversidade de aplicações disponíveis na Internet. Cada vez mais é necessário termos tags específicas para ramificar nosso conteúdo e, desta maneira, classificá-lo mais especificamente, a fim de que humanos e máquinas o compreendam corretamente.

Para isso foi criada uma série de novas tags para facilitar a aplicação do conteúdo e, por que não, do CSS também. Seguem alguns exemplos:

• section – Como o nome diz, representa uma seção do documento ou artigo, por exemplo, que pode englobar um header e um footer;
• nav – Esta é uma das tags mais interessantes, já que foi criada especificamente para o menu do site ou uma simples navegação de links. Vale ressaltar que essa tag não elimina o uso de ul já que serve como elemento pai destas listas;
• article – Pode representar um post de um fórum, blog, notícia de jornal, etc.;
• aside – A definição dessa tag parece um pouco subjetiva; uma aplicação concreta seria a definição de um termo de determinado artigo. Por exemplo, se você está escrevendo sobre uma nova tecnologia, pode envolver um bloco de texto com a tag aside com uma pequena dissertação sobre ele, servindo como um conteúdo complementar, sem fazer o usuário sair do artigo;
• header – É o cabeçalho de uma seção, podendo englobar diversos títulos (leia-se h1, h2, h3 e assim por diante);
• footer – Rodapé da seção, contendo informações como autor do conteúdo, copyrights, data de postagem, etc.

Obviamente temos diversas outras novas tags disponíveis no HTML 5, mas estes são alguns exemplos que mostram bem o “espírito” desta nova versão, oferecendo maior flexibilidade para nosso código em relação a sua semântica.

O grande problema do HTML é que foi criado com o intuito de exibir as informações na Web, mas com o tempo foi crescendo a necessidade de criarem tags para estilização, até que os Web Standards fossem amplamente usados. Por isso confio muito na próxima versão do XHTML que, desde seu início, já foi construído da maneira correta, de certa forma “forçando” o desenvolvedor a escrever seu código corretamente, extinguindo totalmente as tags que representam estilização visual. Mas essa discussão deixamos para uma próxima oportunidade!

Microformats

Como foi dito no início deste artigo, a aplicação dos Microformats é bem simples: usam-se nomes pré-estabelecidos para id’s e classes que, desta forma, atribui significado aos elementos.

Porém muita gente acha que este padrão pode morrer no momento que o HTML 5 se tornar realidade mas, analisando os fatos mais profundamente, dá para concluirmos que isso não irá acontecer, já que cada lado tem um foco diferente.

O princípio dos Microformats é solucionar problemas específicos, tomando como base outros padrões como o vCard, iCalendar, usados há vários anos.

A partir do momento que este formado surgiu para aplicarmos em determinadas ocasiões, fica fácil compreendermos a diferença deste caso com as novas tags implementadas no HTML 5. Enquanto um se preocupa com as diversas aplicações surgidas durante toda a evolução da Internet, o outro se atém a aplicações localizadas oferecendo um detalhamento tão grande que seria quase inviável com tags e/ou atributos novos!

Por isso aconselho a todos estudarem as novidades do HTML 5 (apesar de achar que este é o “assunto da moda” e acreditar mais no XHTML 2) e continuarem atentos aos padrões estabelecidos nos Microformats, pois devido sua simplicidade e foco, é uma prática viável tanto em projetos pessoais como profissionais.

O cronograma do evento foi o seguinte:

• 09:00 – Painel de abertura com os afiliados Brasil – “Os padrőes web e seus impactos no futuro da gorvernança da TI”
• 11:00 – Convidado internacional – “The ways to Web Semantic“
• 11:45 – Convidado especial – “A Web Semântica no Brasil”
• 12:15 – Debate sobre a atuação do W3C Escritório Brasil

Neste artigo vou fazer uma análise do evento, destacando os principais assuntos abordados e o que concluímos para que, no próximo evento, entrem em pauta e auxilie no crescimento do escritório da W3C no Brasil.

Pioneiros no ensino dos Web Standards em nosso país, o pessoal da iLearn foi representado por Everaldo Bechara (Presidente da empresa), que comentou a necessidade de atuarem como evangelizadores, principalmente pela resistęncia natural que o brasileiro tem contra padrőes. Um dos pontos mais interessantes de sua palestra foi o comentário sobre a flexibilidade do uso dos Web Standards para Web Design, pois este não limita a criatividade, pelo contrário, amplia as possibilidades, pois não é necessário fazer uma arquitetura totalmente baseada na idéia de tabelas, como era feito antigamente. Muitos Designers pensam o contrário, mas a realidade é que a adoção dos Web Standards trará mais flexibilidade ao layout, ao mesmo tempo que padroniza os elementos.

Além disso, muito foi comentado sobre acessibilidade, principalmente pela adoção de certas regras para melhorá-la em projetos governamentais. O decreto 5296 ajudará na conscientização da necessidade do XHTML e CSS que, somente por serem utilizados corretamente, já garantem cerca de 60% do uso por deficientes. Para que este decreto vire lei, haverá uma convenção da ONU em breve, o que certamente possibilitará na normatização de tais regras de acessibilidade e os governos ficarão mais atentos a elas.

Porém, um ponto que ainda temos muita dificuldade, e pelo jeito ainda teremos por um bom tempo, é a incompatibilidade de certos navegadores com padrőes adotados pela W3C; é só vermos o exemplo do SVG, ainda não suportado pelo Internet Explorer 8, em fase BETA.

O governo adotando os Web Standards

A palestra de Ricardo Kobashi, Coordenador dos sites de governo e Secretaria de Comunicação, de São Paulo, mostrou como o pessoal está agindo para implementar os Web Standards no meio governamental. Sabemos que novidades nem sempre são bem-vindas, mas quando falamos em dinheiro o pessoal acaba prestando atenção. E foi tocando neste assunto que eles conseguiram convencer os governantes, pois a adoção dos Web Standards gera economia, pois se faz “mais com menos”, e esse é bom argumento para utilizarmos com qualquer cliente!

Mas não é só na economia que os Web Standards contribuíram: a comunicação entre os sites foi facilitada, ou seja, a interoperabilidade entre eles ficou mais prática, já que foi adotado um padrão e, sempre que adotamos padrőes, fica mais fácil para desenvolver e realizar manutençőes. O pessoal do Governo de São Paulo estava procurando por esse padrão a ser adotado e, certamente, a adoção dos padrőes estabelecidos pela W3C foi a melhor escolha.

Quer saber o que eles já fizeram em termos de acessibilidade no Governo de São Paulo? Um belo exemplo é o site da Secretaria dos Direitos da Pessoa com Deficięncia.

Acessibilidade sempre, em qualquer projeto

Como já comentei, acessibilidade foi um tema muito comentado neste evento e, como não poderia deixar de ser comentado, o fato de que devemos utilizar AJAX com muito critério. Na palestra de Gustavo da Gama Torres, foram exemplificados certos casos, muito comuns na era da “Web 2.0″ que prejudicam muito o uso do site por pessoas deficientes.

Por isso, ao elaborar novas aplicaçőes, sempre tenha em mente o público-alvo e tome cuidado para que todos possam aproveitar seus recursos, sem o uso de tecnologias específicas como o próprio AJAX ou Flash, por exemplo. Para ter mais segurança neste quesito, nada melhor que fazer testes de acessibilidade, elaborando certas metas a serem atingidas com o site e se estes objetivos foram alcançados com pessoas deficientes ou não.

Os caminhos para a Web Semântica

Uma das gratas surpresas do evento foi a presença de Klaus Birkenbihl, Coordenador dos Escritórios Internacionais do W3C, que falou um pouco sobre a função da W3C e a importância da padronização no modo de exibir os dados, como foi feito na criação e é um dos princípios básicos do HTML.

A W3C tem como um dos fundamentos, passar a idéia de que a tecnologia web deve ser interoperável, os padrőes devem ser abertos e, consequentemente, possibilitar que tudo deve ser acessível, independente do lugar no qual está sendo acessado, capacidade do dispositivo usado, etc.

Achei bem interessante Klaus falar sobre o uso do texto “Clique aqui” em links, o que é totalmente errado e ainda praticado. Posso dizer que ainda vejo muito disso, mas o fato é que esse texto não diz nada sobre o que o usuário irá visitar (com leitores de tela, por exemplo) e, em caso dos robôs de busca, também não será nada relevante. Por isso sempre descreva seu link de maneira correta, facilitando a vida dos usuários e dos sistemas de busca!

Foi comentado, também, que o princípio básico da Web Semântica é classificar as informaçőes, categorizar o conteúdo para que as máquinas possam entendę-lo também. Já vemos belos exemplos em Microformats, mas também temos o RDF, padrão adotado pela W3C. Houve até uma certa discussão sobre RDF, em quais casos é mais utilizado e, inclusive, Klaus falou que o indicado é tentar converter todos os que conseguir, apesar de não ser o necessário.

Consideraçőes finais

O evento foi muito interessante, pois abordou diversos assuntos presentes em nosso cotidiano, principalmente na questão da acessibilidade, que vem sendo adotada cada vez mais e ainda vai se tornar um assunto muito comum para quem trabalha com web. Porém, acho que a maior contribuição foi a reunião de um grupo de pessoas realmente interessadas em contribuir com o escritório brasileiro da W3C e, certamente, outros encontros como este acontecerão no futuro.

O importante é o pessoal juntar idéias e propostas para que a representatividade do Brasil, nas questőes internacionais, seja cada vez maior, e possamos ajudar a criar novos padrőes, além de simplesmente adotá-los.

Quem quiser ver algumas fotos do evento, montei uma galeria de imagens no Flickr.

Já escrevi por aqui um artigo bem interessante sobre como melhorar seu rendimento profissional, além de outro fator que influencia diretamente no assunto deste post, a colaboração que deve ocorrer entre Web Designer e desenvolvedor CSS.

Agora falaremos de algo que envolve a organização do trabalho, seja numa equipe com várias pessoas, como um simples freelancer: a padronização.

Como foi comentado no evento da W3C, o brasileiro geralmente não gosta da palavra padrão, pois pode parecer “engessado”, algo que realmente não combina com as práticas em nosso mercado de trabalho. Mas com o tempo a gente aprende e vę que a organização do desenvolvimento e fluxo de trabalho garante um resultado mais preciso e, conseqüentemente, com nível de qualidade superior.

Digamos que chegue um grande site para desenvolvermos e, logicamente, existe um prazo a ser cumprido. No entanto, deveremos tomar algumas providęncias para que o tempo não seja excedido e, em casos extremos, não percamos o cliente.

Supondo que o layout já esteja feito, assim já pulamos a parte de briefing, Arquitetura da Informação e Criação, indo diretamente ao desenvolvimento HTML e CSS. Então, deve-se iniciar pelos códigos HTMLs, focando totalmente nesta parte, mantendo sempre os princípios do KISS (keep it simple stupid) e semântica do código pois, como sempre digo, o código HTML bom é aquele que não precisa ser ajustado de acordo com “firulas” do layout.

Padronização de HTML

Na etapa do HTML devemos adotar uma padronização no desenvolvimento, como por exemplo estabelecer um estilo de DOCTYPE dependendo do foco do site (grandes portais tendem a ser administrados por uma ferramenta, por isso o XHTML 1.0 Transitional é o mais indicado por ser mais tolerante a erros no código) e um arquivo padrão, com um header e suas meta tags pré-escritas. O modo pelo qual inserimos o CSS também deve ser padronizado: alguns preferem utilizar @import com estilo inline, enquanto a maioria (como eu) preferem utilizar o <link rel="stylesheet"... />.

Segue abaixo o exemplo de “template” HTML que utilizo:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt-br" dir="ltr">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="keywords" content="" />
<meta name="description" content="" />
<meta name="author" content="Carlos Eduardo de Souza" />
<title>T&#237;tulo do site</title>
<link href="css/estilo.css" rel="stylesheet" type="text/css" media="screen" />
<!--[if IE 7]><link rel="stylesheet" type="text/css" href="css/estilo_ie7.css" media="screen" /><![endif]-->
</head>
<body>
</body>
</html>

Além do código propriamente, deve haver um consenso entre os desenvolvedores da nomenclatura dos arquivos e organização de pastas, assim com o decorrer do projeto e sua manutenção, não perde-se tempo para encontrá-los.

Fica também a sugestão do controle de versőes, ítem importante principalmente em equipes numerosas como aqui na agęncia e, para este fim, utilizamos o Eclipse.

Padronização de CSS

Já na parte do CSS a padronização é um pouco mais complicada, pois muita coisa é subjetiva, ou seja, está relacionada com as preferęncias de cada desenvolvedor. Ao começar pela escrita das regras: muita gente prefere escrever uma regra com uma propriedade por linha, enquanto outros aderem a prática de uma regra por linha, com todas as propriedades seguidas lado a lado. Particularmente prefiro esta última opção, pois o documento fica muito menor e para encontrar as regras fica muito mais fácil.

Também temos que nos ater aos comentários, também estabelecendo um padrão para que o documento fique mais legível:

/*
Cliente: Nome do Cliente
Projeto: Nome do Projeto
*/

/*
--------------
ELEMENTOS e CLASSES
--------------
*/

/* ------- GERAL ------- */

Este é um exemplo do início de código CSS que adotei em meus projetos pessoais e na agęncia. Pode-se observar que o código começa com o nome do cliente e projeto, seguido de um “comentário principal”, para os elemtentos e classes aplicados a todo o site. Já o comentário “geral” é um exemplo de código utilizado para separar as seçőes, algo como um “comentário secundário”.

Além da escrita dos comentários e regras, também temos que mentalizar a forma que iremos exibir as propriedades. Muitos desenvolvedores optam por escrever as propriedades em ordem alfabética, mas eu prefiro escrever em ordem de relevância, por exemplo, colocando as propriedades de posicionamento, float, display, width, height, margin, padding, etc., na frente, enquanto as outras relativas a fontes, alinhamentos de texto, etc., ao final de cada linha. Assim todos os desenvolvedores da equipe encontrarão as informaçőes principais em primeiro lugar.

Também temos que nos ater aos hacks pois há diversas soluçőes, principalmente no que se diz a respeito de Internet Explorer. Há a possibilidade de usarmos conditional comments ou os famigerados hacks dentro do CSS. O importante é que haja uma padronização e a equipe siga o mesmo caminho para solucionar tais problemas.

Padronização é a chave para o sucesso

Sei que este artigo não é direcionado aos novatos da área, até porque envolve aspectos mais administrativos de nossa profissão, mas nada impede que estas dicas sejam seguidas desde seu começo na área.

O importante é que saibamos a relevância de seguirmos certas regras e que, com elas, nosso rendimento aumentará, além de termos uma base para que não aconteçam ou, pelo menos, diminuam as chances de erros durante o processo do projeto.

Já escrevi um arquivo dando algumas dicas para melhorar seu rendimento como profissonal, na área dos Web Standards, e a proposta deste artigo é parecida, mas unindo a área de Design com o desenvolvimento do site.

Comunicação como primeiro passo de um projeto bem sucedido

A comunicação entre ambas as partes é extremamente essencial para o sucesso do projeto, seja ele de pequeno, médio ou grande porte.

Fazendo um pequeno estudo de caso, aqui na agęncia estamos finalizando um grande site que exigiu muita cooperação entre as equipes, tudo baseado na comunicação entre seus integrantes.

Mas para quę serve essa comunicação? Como disse anteriormente, mais especificamente no caso dos Web Designers, os profissionais devem saber as limitaçőes que o meio oferece. Uma boa maneira de esclarecer todas essas dúvidas, encontrada aqui na Mídia Digital, foi a execução de um workshop para o pessoal da equipe de Criação, no qual fiz uma apresentação e um documento, expondo as principais limitaçőes que a diversidade de resoluçőes, navegadores, etc., impőem em nosso trabalho.

Partindo para a prática

Com a difusão de conhecimentos, através dos workshops sobre as limitaçőes do Web Design, para que se faça um site conciso e acessível ao maior número de usuários, chegou a hora da execução dos layouts.

Sugerimos que fossem criados padrőes para os elementos visuais, mantendo a unidade visual, conceito muito bem aplicado em revistas e jornais que, em muitos casos, é esquecido quando analisamos as páginas na Internet.

Elementos criados e aplicados, é a hora do Designer desenvolver um arquivo contendo os elementos padrőes do site e agrupá-los em uma espécie de arquivo modelo, para que o Front End Developer (desenvolvedor da parte HTML e CSS) possa utilizá-los e criar seus códigos flexíveis, ao ponto de poder utilizá-los quando necessário.

Por exemplo, há tręs tipos de títulos nas páginas internas, botőes de formulário e selos para diferentes tipos de produto que, ao serem inclusos neste arquivo, mostram que serão utilizados em qualquer página do site. Assim os desenvolvedores fazem as classes no CSS sem especificidade, para que possam ser aplicados a qualquer momento.

Desenvolvendo o código

Após passar a etapa do diálogo inicial, expondo todas as limitaçőes da Web e criação dos padrőes visuais, além dos layouts em geral, chega a hora o desenvolvedor pôr os Web Standards em prática, produzindo seu código HTML e CSS flexível o bastante para aplicar tais elementos nas páginas, quando necessário.

Para projetos maiores, recomendo dividir seu CSS em arquivos separados, por exemplo, o primeiro serve como índice, anexando outros dois arquivos. Um deles abriga as definiçőes gerais do site como fontes, alinhamentos, botőes, links, selos, etc., ou seja, tudo que envolve aquele arquivo padrão criado pela Criação. Depois disso, o terceiro arquivo envolve todas as especificaçőes de cada página, contendo os elementos específicos, que não são aplicáveis nos padrőes do site.

Um ponto bem interessante é que muito Web Designer, ao ver seu site aplicado, fica um pouco frustrado, seja por certos exageros cometidos na criação (sem saber das limitaçőes do meio), ou por falha do desenvolvedor do HTML e CSS. Neste último caso, após um bom diálogo entre ambas as partes e a criação do arquivo padrão de layout, não haverá desculpas para falhas na construção do site.

Como resultado, um site bem resolvido

No desenvolvimento de todo e qualquer projeto, se nos basearmos na comunicação entre as equipes envolvidas, a chance de sucesso é muito grande. Inclusive, como saldo de todo esse processo, as chances de haver a temida refação são muito menores, pois o número de ajustes tende a ser bem menor.

Voltando ao nosso estudo de caso, a nossa Designer ficou satisfeitíssima com o resultado da produção do HTML e CSS, devido a fidelidade com os layouts que ela nos entregou.

Inclusive, esse fato não se deve somente a qualidade da equipe envolvida no projeto, mas a toda essa organização e padronização do processo, facilitando o trabalho em ambas as partes.

Todo mundo que tem bom senso sabe que devemos nos preocupar em manter o layout de nosso site o mais padronizado possível, independente da plataforma e sistema utilizado para acessá-lo.

Por isso, surgiram técnicas para “driblar” essa dificuldade, utilizando imagens ao invés de texto puro. Só que esta prática acabava dificultando a indexação do conteúdo, caso o desenvolvedor do site não utilizasse o atributo “alt” nas imagens, pois os sistemas de busca não conseguiam interpretar o conteúdo utilizado na imagem.

Para resolver este problema, utilizando CSS, surgiram as técnicas de image replacement, ou seja, o código HTML permanece intacto, com o texto puro mas, através das folhas de estilo, trocamos o texto por uma imagem. Essa prática é muito utilizada pelos desenvolvedores, pois serve como uma verdadeira mão-na-roda no momento que o designer escolhe uma fonte fora do padrão dos sistemas.

Porém, surgiu uma notícia de que o Google poderia penalizar quem utilizasse esse tipo de técnica pois o desenvolvedor do site não estaria mostrando exatamente o que está no código HTML, fazendo com que este texto não aparecesse na tela para exibir uma fonte diferente em seu lugar.

E o que vocęs acham? Uma imagem com o atributo “alt” substitui a relevância de um título (h1, h2, h3…) no código?

Acredito que há lugares onde devemos utilizar o image replacement e até mesmo o sIFR, quando necessário, assim não perdemos a hierarquia no código e relevância do conteúdo.

Como sempre, cabe a nós pensar sempre no usuário. Há várias maneiras para se fazer a técnica do image replacement, algumas que dificultam ou não a acessibilidade do site. Por isso, indico escolher o método mais acessível, assunto discutido neste artigo (em inglęs).

• Metatags – Breve introdução de uso e teoria – Artigo que explica o que são as metatags, as maneiras de utilizá-las e quando devemos usá-las.
• XHTML – Nove regras – Definição de algumas regras para bom desenvolvimento de um código XHTML, servindo como um guia rápido para quem está iniciando na linguagem. Porém, fica a observação para o exemplo número 3, no qual o autor do artigo utilizou as tags <b> e <i>, as quais não devem ser mais utilizadas.
• Resetting Again – Exemplo de CSS global reset, uma prática que pode facilitar muito o início do trabalho de qualquer site em CSS. Cada um possui a sua maneira de desenvolver, mas sempre é válido conhecermos outras maneiras de fazę-lo.
• Web Typography – an introduction to font families, font choinces and HTML punctuation – Artigo que trata de forma simples os diferentes tipos de famílias de fontes disponíveis para uso na Internet, comentários e comparaçőes de boas fontes para usar em seu site, etc.
• Developing With Web Standards – Excelente site que serve tanto como introdução, como referęncia para quem desenvolve sites seguindo os Web Standards (ou Padrőes Web). Fala da história, estrutura, desenvolvimento em camadas, diferenças entre os browsers entre outros tópicos relevantes.
• Serving XHTML with the Right MIME Type588 – Artigo publicado no Web Standards Project com o intuito de auxiliar na escolha do MIME Type para seu site, variando pela forma como quer servir o conteúdo do mesmo.

Sempre lembrando que, caso vocęs tenham mais sugestőes para inserção nesta série de posts, não hesitem em comentar ou enviar um e-mail para mim. Obrigado

• Iconize Textlinks with CSS – Este site oferece um CSS e pacote de imagens para aqueles que desejam inserir ícones em seus links automaticamente, através do [tag]CSS[/tag]. Uma aplicação muito interessante e fácil de ser utilizada.
• 2007: More Web Design Trends & Cliches – Artigo que cita as tendęncias do [tag]Web Design[/tag] atual e, claro, alguns clichęs que acabam por surgir, devido ao novo estilo de Design proveniente, principalmente, da era “Web 2.0″.
• 10 Usability Nightmares You Should Be Aware Of – Neste artigo são citados 10 tipos de erros em termos de [tag]Usabilidade[/tag] que não podem ser cometidos, para não comprometer a facilidade com seu site é acessado. Para muitos, alguns desses itens não são novidades, mas vale a pena frisar, pois este é um tema de suma importância para qualquer projeto, independente de seu tamanho.
• CSS Rounded Box Generator – Este é um gerador de caixas com cantos arredondados, utilizando CSS. Para muitos esse tipo de recurso pode trazer muitos problemas, devido a seu grau de complexidade, então esse tipo de gerador pode ajudar não só com o código pronto, mas para sabermos como fazę-lo.
• The most coolest web tools – Trata-se de uma lista enorme de utilidades, geradores, etc., direcionados para quem desenvolve sites. Pode ter muita coisa inútil, mas com certeza há ferramentas que auxiliam a deixar nosso trabalho mais prático.
• Activating the Right Layout Mode Using the Doctype Declaration – Este site explica detalhadamente os tipos diferentes de layout (ex: Standards mode, no qual renderiza o CSS de modo correto, seguindo os Padrőes, e Quirks mode, no qual o browser se comporta como uma versão antiga, oferecendo certas limitaçőes ao desenvolvedor), de acordo com o doctype escolhido e em quais browsers são suportados.
• Styleshout.com – Galeria de layouts prontos (de boa qualidade) e gratuitos, feitos via CSS. Esse tipo de site pode ser útil para aqueles que desejam aprender como fazer um determinado tipo de layout e, baixando um tema pronto, podem ver exatamente como pode ser construído.
• A Preview of HTML 5 – Este artigo dá uma luz sobre a próxima versão do [tag]HTML[/tag] 5, mostrando alguns pontos interessantes que estão por vir, que prometem facilitar a vida do desenvolvedor e adicionar mais semântica ao código.
• X/HTML 5 Versus XHTML 2 – Aproveitando o “gancho” do link anterior, este site fala um pouco mais sobre as diferenças existentes entre as próximas versőes do HTML e [tag]XHTML[/tag], respectivamente. Vale a pena darmos uma olhada e comparar os pontos fortes e fracos de cada um. Com certeza esse assunto ainda vai dar o que falar!
• Maximum and Minimum Height and Width in Internet Explorer – Um dos grandes problemas que nós, desenvolvedores de sites temos, é a incompatibilidade do Internet Explorer 6 com determinadas propriedades CSS e, algumas delas são a max-width, max-height, min-width e min-height. Claro, há maneiras de se dar um jeito nisso e esse link nos dá soluçőes.
• Embedding YouTube Videos as Valid XHTML 1.0 - Artigo que mostra como inserir vídeos Youtube em seu site de maneira correta, ou seja, deixando seu código XHTML 1.0 válido.

Bom, por enquanto é só. Tenho certeza que esse pequeno atraso fez valer a pena, pela qualidade dos links apresentados!

Separei alguns links interessantes, principalmente sobre [tag]CSS[/tag] com tutoriais, bons exemplos de Design e boas maneiras no desenvolvimento de formulários.

• Wufoo – HTML Form Template & CSS Design Gallery – Site direcionado ŕqueles que desejam aprender mais sobre desenvolvimento de formulários, tanto na forma do código [tag]HTML[/tag] como na produção visual do mesmo.
• Best of CSS Design 2007 – Como o nome diz, trata-se de uma listagem dos melhores Designs feitos com CSS durante este ano de 2007. Bela seleção que mostra todo o potencial que temos em nossas mãos, contradizendo aqueles que afirmam o fato de que “todo site feito em CSS tem cara de blog”.
• Transparent PNGs in Internet Explorer 6 – Trata-se de mais um artigo explicando o funcionamento e soluçőes para a aplicação de PNGs transparentes no Internet Explorer 6.
• 9 CSS Ethics Every Designer Should Have – Este artigo lista 9 boas práticas que podem agilizar e facilitar seu desenvolvimento em CSS.
• Creating Sexy Stylesheets – Como o link anterior, este artigo dá várias dicas para melhorar a forma como escrever seu CSS e, realmente, coisas simples como estas podem ajudar muito no desenvolvimento de grandes projetos.
• The All-Expandable Box – Tutorial que mostra, de maneira simples, como fazer uma caixa expansível (sombreada), até mesmo quando o usuário aumenta o tamanho da fonte.
• CSS drop shadow – A exemplo do link anterior, este tutorial ensina como fazer caixas expansíveis com sombra, utilizando CSS.

• 50+ CSS Best Practices and Coding Guidelines – Site com listagem de 50 boas práticas para melhorar seu [tag]CSS[/tag] e modo de escrevę-lo. Possui maior utilidade como guia do que tutorial propriamente dito.
• Ensuring your HTML emails look great and get delivered – Como o nome diz, este artigo nos dá dicas para formatação de e-mails e maneiras para termos certeza de que os usuários os receberão de maneira correta. A parte mais interessante é a listagem de propriedades CSS suportada pela maioria dos clientes de e-mail.
• Bring on the tables – Este, com certeza, é o melhor artigo que encontrei sobre utilização de tabelas. Explica detalhadamente desde a maneira mais simples até a mais complexa que, em termos de usabilidade, é a mais correta a ser utilizada.
• CSS-only, tableless forms – Este site mostra exemplos de formulários desenvolvidos apenas com CSS e HTML puro, sem utilização de tabelas.
• Top Ten Search Engine Optimization Myths – Artigo que lista os 10 maiores mitos sobre SEO e explicaçőes do porque de serem apenas mitos. Vale a pena conferir!
• A List Apart: Articles: Suckerfish Dropdowns – Tutorial feito pela A List Apart mostrando como se faz um menu dropdown com utilização de CSS e JavaScript.