Blog

Nós, designers voltados para a Web, sabemos muito bem que este tipo de mídia oferece várias limitações (como qualquer outra) e, entre elas, está utilização de fontes diferentes do padrão adotado pelos sistemas operacionais. Ou seja, se eu desejar utilizar uma fonte Helvetica, os usuários de Mac poderão abrí-la tranqüilamente, enquanto os usuários de Windows só poderão visualizá-la caso consigam instalá-la em seus computadores.

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).

Mais um ano chega e, claro, para começar com o pé direito, iniciamos com a décima edição da Sexta-feira dos Web Standards!

Essa lista envolve mais conceitos do que aqueles tutoriais que costumo passar, mas, claro, são muito úteis a todos!

• Standards Overview - Ótimo texto que explica bem o que são os Web Standards (ou Padrões Web), seus conceitos e alguns pontos importantes que devemos saber antes de desenvolvermos nosso site como Doctype, diferenças existentes entre os browsers, Acessibilidade, código semântico, etc.
• IE7-JS - Trata-se de uma biblioteca JavaScript (já conhecida por muitos) que, ao ser inserida em seu site, faz com que o Internet Explorer 5 e 6 reconheçam seu site da mesma maneira que o IE7, corrigindo vários erros relacionados a renderização do HTML e CSS. Já existe o script IE8, mas ainda em fase beta.
• Levels of CSS knowledge - Como o título diz, este artigo mostra os diversos níveis de conhecimento em CSS e suas particularidades. Interessante para saber em qual nível você se enquadra.
• CSS, Acessibility and Standards Links - Lista muito interessante com diversos links relevantes sobre tutoriais, noções básicas de CSS, Acessibilidade, guias, layouts e templates, livros, técnicas entre outros, direcionados para quem desenvolve sites.
• Become a Better Web Standards Developer - Este artigo mostra várias dicas para quem quer se aperfeiçoar no desenvolvimento de sites em Web Standards, além de fornecer uma ótima lista de links relevantes ao final do texto.
• maxdesign - Ótima referência para aqueles que querem aprender mais sobre estilização de listas, uso de floats e seletores CSS. Muito bem explicado e exibe vários exemplos práticos.

Espero que tenham gostado dessa lista. Semana que vem, com certeza, tem mais!

Technorati Tags: Web Standards, browsers, JavaScript, HTML, CSS

Mais uma semana se passa e chega a quinta versão do Sexta-feira dos Web Standards. Separei uma lista de links interessantes sobre CSS Hacks, Web Standards em geral e técnicas CSS.
Espero que aproveitem e deixem suas sugestões para a próxima edição!

• The 7 CSS Hacks that we should use - Artigo que mostra exemplos de hacks e práticas que podemos utilizar para “driblar” certas incompatibilidades existentes entre os browsers. Claro, todos nós sabemos que devemos tentar evitar ao máximo esse tipo de solução, mas quando não há outra saída, é uma boa pedida.
• Top 30 popular websites are NOT using tables as main layout structure - Artigo que comenta a listagem dos 30 sites mais populares que, curiosamente ou não, todos não utilizam tabelas para construção do layout.
• Layout CSS sem tabelas - Página especialmente dedicada à introdução do assunto para aqueles que ainda desejam aprender a desenvolver o layout de seus sites sem tabelas. Extremamente indicado para os iniciantes e para quem ainda deseja ter embasamento teórico.
• Writing a CSS cross-browser - Artigo que vem em contrapartida à primeira sugestão da lista pois explica como fazer um site aplicável a vários browsers distintos, tentando ao máximo não utilizar CSS Hacks.
• Pullquotes em CSS - Este tutorial nos motra como fazer os famosos “pullquotes” utilizando um código simples, enriquecendo seu text, além de facilitar a leitura.
• Construindo sites com CSS e XHTML - Site voltado ao lançamento do livro dando maiores detalhes sobre seu conteúdo. Como ainda não temos um livro nacional no nível dos estrangeiros sobre este assunto, estou ansioso para ver se a espera valeu a pena.
• Acessibilidade web: 7 mitos e um equívoco - Artigo extremamente relevante que fala mais sobre acessibilidade e idéias, muitas vezes erradas, que temos sobre o assunto.

Technorati Tags: Web Standards, CSS, browsers, acessibilidade

Nós, defensores dos Web Standards, sabemos que um código bem escrito, prezando a semântica e uma boa estruturação, não pode ser trocado por algo criado em um editor WYSIWYG (editor visual, como Dreamweaver, Front Page, etc.). Porém, devido a certas incompatibilidades entre browsers mais antigos (leia-se Internet Explorer 6) e modernos (Firefox, Opera, Safari, Internet Explorer 7, etc.), perdemos tempo adequando nossos sites a estas diferenças, acarretando prejuízos no projeto.

Neste ponto, quase todos nós concordamos que o Internet Explorer deveria perder seu cargo de liderança no mercado, fazendo-nos ter menos dor de cabeça ao adaptar nossos sites a ele. Mas alguns vão além, achando que deveria existir apenas um browser no mercado, facilitando o processo do desenvolvedor.

Mas, se pararmos para pensar no sentido da concorrência, neste caso, não haveriam mais disputas pelo mercado e, portanto, não haveria necessidade por maiores inovações e melhoria nos recursos oferecidos pelo navegador. Claro, adaptações ocorreriam, mas em velocidade menor, acredito.

O ideal, no meu ponto de vista, seria a implementação da mesma engine para renderização os sites, ou seja, qualquer site que desenvolvêssemos seria visualizado da mesma forma em todos os navegadores, mas só isso. Ainda assim haveria disputas e concorrência por funcionalidades externas, pois os browsers podem oferecer muito mais do que apenas uma forma de acessar sites… Acredito que desta forma o negócio ficaria muito mais interessante, principalmente para nós desenvolvedores e, claro, usuários, pois no final das contas são eles que acabam perdendo com o quadro atual deste contexto.

Unificando a forma de desenvolvimento, poderíamos nos concentrar em tantos outros pontos importantes, como a acessibilidade, modernizando nosso site a ponto de ser visto sem dificuldades por deficientes. Porém, devido a “perda” de tempo que temos para otimizar nossos códigos aos diversos navegadores, essas implementações podem ficar prejudicadas, devido a falta de prazo para entrega dos projetos.