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

• IE 8 Compatibility – Meta Tags, Http Headers, User Agent Strings etc etc – Este artigo mostra variações que podemos utilizar nos headers de nosso site para mudar o comportamento do Internet Explorer 8. Interessante conhecermos antes de começarmos a desenvolver para ele, dependendo da necessidade de cada site.
• Vertical Centering With CSS – Excelente artigo que mostra 5 métodos para fazer alinhamento vertical pelo CSS. Sabemos que não é nada fácil como aplicar valign numa célula de tabela, mas pode quebrar um galhão!
• 12 resources for getting a jump on HTML 5 – Como diz neste artigo, o mundo ainda não está preparado para usar o HTML 5, mas para podermos chegar neste ponto, temos que conhecê-lo. Então, esta página serve como referência a diversos outros sites com textos sobre o assunto. Obrigatório!
• Web Standards Test: Top 100 Sites – Zeldman resolveu fazer uma pesquisa dos 100 sites mais populares da Internet (via Alexa) e concluiu que apenas 25% deles usam os Web Standards. Veja uma pequena análise dos sites mais bem colocados.
• Como testar o site no IE6, IE7 e IE8? – Artigo que apresenta algumas maneiras de testar seu site nas diversas versões de Internet Explorer, para acabar de vez com o problema nos testes!
• 10 Rare HTML Tags You Really Should Know – Lista de 10 tags HTML que, na grande maioria, são esquecidas mas podem acrescentar muito valor e qualidade ao nosso código, se bem utilizados!

Como de costume, o evento acontece no dia 9 de Abril, e o project.47 participará novamente!

Caso queira automatizar o processo, pode-se utilizar um plugin para WordPress que faz tudo sozinho

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.

Há tambem diversas maneiras de definir determinadas propriedades do CSS como background, font, margin, padding, etc. E este é o intuito deste artigo, mostrar para aqueles que ainda não conhecem estes “atalhos” que ajudam (e muito) a diminuir seu código.

Background

Como o próprio nome diz, a propriedade background define o fundo do elemento, com uma cor sólida ou uma imagem. Neste último caso, pode-se dizer se esta será repetida, seu posicionamento e comportamento.

seletor {
background-image: url(imagem.jpg);
background-color: #fff;
background-repeat: no-repeat;
background-position: bottom;
}

Como pode-se perceber, esta maneira deixa seu código muito extenso, então vamos abreviar estas propriedades em uma única linha. Neste caso, não há importância na ordem pela qual vocę dispőe os valores, mas é interessante manter um padrão de escrita:

seletor { background: url(imagem.jpg) #fff bottom no-repeat; }

Color

Como nem todos ainda sabem, é importante comentarmos sobre a abreviação na declaração da escrita das cores. Quando utilizamos os valores hexadecimais, há casos nos quais podemos escrever apenas 3 caracteres, ao invés dos 6 que estamos acostumados.

seletor { color: #aaff00; }

Podemos abreviar desta forma:

seletor { color: #af0; }

A lógica da abreviação é simples: cada caractere representa um par de caracteres da escrita não abreviada. Veja o esquema abaixo:

Margin e padding

A lógica para abreviação das propriedades margin e padding é a mesma. Vejamos o exemplo da escrita sem abreviação:

seletor {
margin-top: 1px;
margin-right: 1px;
margin-bottom: 1px;
margin-left: 1px;
padding-top: 1px;
padding-right: 1px;
padding-bottom: 1px;
padding-left: 1px;
}

Para abreviar existem algumas maneiras:

Neste caso, os valores são aplicados para todos os lados do elemento:

seletor { margin: 1px; padding: 1px; }

Se as unidades do topo e rodapé forem as mesmas (1px), esquerda e direita forem iguais entre si (5px), podemos escrever de outra forma:

seletor { margin: 1px 5px; padding: 1px 5px; }

Mas há situaçőes nas quais precisa-se utilizar uma unidade para o topo (1px), outra (igual) para os lados (5px) e mais uma para o rodapé (6px):

seletor { margin: 1px 5px 6px; padding: 1px 5px 6px; }

E, por fim, uma maneira simplificada de escrever as dimensőes para todos os lados, mas deve-se seguir o sentido horário, ou seja: top (1px), right (2px), bottom (3px) e left (4px):

seletor { margin: 1px 2px 3px 4px; padding: 1px 2px 3px 4px; }

Border

Para abreviar a propriedade border é tão fácil quanto a background, pois não exige uma ordem padrão. Segue abaixo exemplo da escrita sem abreviaçőes:

seletor {
border-width: 1px;
border-style: solid;
border-color: #000;
}

Para abreviar esta propriedade é simples:

seletor { border: 1px solid #000; }

Caso queira estilizar somente a borda do topo, por exemplo, é só acrescentar “-top” após o “border”:

seletor { border-top: 1px solid #000; }

Font

Esta propriedade tem a função de estilizar o tamanho da fonte, sua linha, família, peso, etc. A forma mais complexa de escrita é a seguinte:

seletor {
font-style: normal;
font-variant: small-caps;
font-weight: bold;
font-size: 1em;
line-height: 1.3em;
font-family: "Trebuchet MS", Arial, sans-serif;
}

Muitos não sabem que a propriedade line-height se inclui nesta abreviação, por não ter o prefixo “font”. Veja agora a maneira simplificada de escrever a propriedade font:

seletor { font: normal small-caps bold 1em/1.3em "Trebuchet MS", Arial, sans-serif; }

Fique atento para a ordem de escrita e, caso o nome da fonte tenha espaço, escreva utilizando aspas duplas, como no exemplo acima.

List-style

A propriedade list-style é utilizada para estilizar a marcação de itens de lista. A escrita não abreviada é a seguinte:

seletor {
list-style-type: circle;
list-style-position: inside;
list-style-image: url(bullet.gif);
}

Para escrevę-la de forma simplificada não é necessária uma ordem certa das propriedades. Veja o exemplo da abreviação:

seletor { list-style: circle inside url(bullet.gif); }

Há outras propriedades que podem ser simplificadas, como a outline mas, devido sua falta de suporte, não é necessário exemplificá-la aqui.

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.

• As premissas da Web Semântica – Precisa dizer mais? Este artigo aborda de maneira bem clara o que é essa tal de Web [tag]Semântica[/tag] e a importância de seu compreendimento no desenvolvimento de sites. Para quem está começando no mundo do desenvolvimento Web, é um artigo de extrema utilidade.
• Design para CSSers – Outro grande artigo do Luli, agora abordando certos conceitos de Design que são extremamente essenciais para qualquer desenvolvedor de HTML e [tag]CSS[/tag]. Na verdade, costumo falar muito aqui sobre a necessidade dos Web Designers saberem sobre CSS, mas o contrário também deve acontecer. Claro, falo isso no sentido profissional, ou seja, aqueles que trabalham com Web Standards, assim como eu, devem ter conhecimentos sobre Design, mas não temos como exigir que um programador saiba de tudo isso ao mesmo tempo!
• Image Replacement + Google – Ahh, a velha discussão sobre image replacement e o Google. Este artigo vem elucidar muita coisa sobre o assunto, mostrando principalmente que não temos a perder com esta técnica, somente devemos ter certas precauçőes ao utilizá-la.
• Using CSS to Fix Anything: 20+ Common Bugs and Fixes – Como o próprio nome diz, este é um artigo que mostra diversas técnicas de CSS para corrigir bugs que enfrentamos corriqueiramente, seja com browsers (leia-se Internet Explorer) ou com propriedades que os desenvolvedores não conhecem muito bem e acabam tendo dificuldades, como o bom e velho float.
• Cheat Sheets for Front End Developers – Coleção de cheat sheets, ou seja, aqueles guias rápidos com propriedades e elementos a serem utilizados naqueles momentos que esquecemos a nomenclatura ou modo de uso. Excelente link para todos nós, Front End Developers e, claro, para quem não é da área e precisa daquela consulta rápida para resolver algum problema de última hora.
• Finding Harmony Between Categories and Tags on Blogs – Para finalizar, este artigo que acabei achando de última hora ajuda principalmente os blogueiros iniciantes, que não sabem a diferença entre tags e categorias, mostrando em quais casos é melhor usar um ou outro. O importante é ter bom senso principalmente na hora de usar as tags!

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.

Vejamos a seleção de links que fiz para esta semana:

• Opera Web Standards Curriculum – Este site, oferecido pelo Opera, nada mais é do que um guia de boas práticas para o desenvolvimento de sites dentro dos [tag]Web Standards[/tag], com uma boa coletânea de artigos envolvendo as áres do HTML e CSS, além de conceitos gerais sobre o tema.
• Informação e Formatação; As duas camadas do desenvolvimento web – O artigo apresenta o conceito sobre a separação entre conteúdo e formatação do site, um dos princípios básicos para desenvolvimento nos Web Standards. É algo que pode parecer batido, mas para quem está querendo aprender como fazer sites, a contextualização é muito importante e este artigo cumpre bem este papel.
• Creative Use of PNG Transparency in Web Design – Sabemos que o uso de PNG 24 bits nos dá uma certa dor-de-cabeça com o Internet Explorer 6 mas, se usado de maneira correta, pode ampliar nosso leque de possibilidades, oferendo um ótimo recurso visual para nossos sites. Este artigo dá algumas dicas de aplicaçőes deste PNG 24 bits, aproveitando ao máximo o recurso da transparęncia alpha, enriquecendo nossos layouts.
• Otimizar seu site para a pesquisa do Google – A otimização de sites para sistemas de busca já não é mais uma novidade e, inclusive, é uma área que vem crescendo muito nos últimos tempos. Este artigo vem justamente auxiliar na compreensão desta área e o que podemos fazer para melhorar o posicionamento de nosso site, aumentando sua relevância para o sistema de busca. Claro, não é um guia que oferece fórmulas mágicas, mas é uma ótima introdução para o assunto!
• 10 CSS Form Examples – Sem idéias para implementar algum novo formulário em seu site? Não sabe como desenvolvę-los? Este artigo oferece 10 exemplos de formulários bem feitos, usando e abusando das possibilidades do CSS, aliado ao visual agradável e funcional.
• CSS Compability and Internet Explorer – Felizmente o pessoal da MSDN (Microsoft Developer Network) reconheceu as limitaçőes de seus browsers e fez um site especialmente voltado para a compatibilidade do Internet Explorer com o CSS, listando as propriedades CSS e quais delas são suportadas (ou não). O interessante é que este site não se restringe ao IE 6 ou 7, na verdade ele faz uma tabela comparativa desde a versão 5 até a 8, que está em fase beta.

Sabemos que o propósito real de um experimento desses não é mostrar que podemos fazer desenhos com [tag]CSS[/tag], mas para conhecermos os limites que esta tecnologia nos oferece e, com certeza, oferece um resultado muito interessante.

É incrível ver o empenho do pessoal para chegar em tal resultado que, surpreendentemente funciona em browsers como: Internet 5 até o 7, Opera 9, Firefox 2, Safari 3, etc.

Certamente vocę ficou curioso para ver a “imagem”, então é só entrar neste link.