Subi hoje no sourceforge uma classe que fiz a quase um ano, e que me ajudou muito.
É uma classe para envio de emails no PHP, inclusive com arquivos anexados. A classe é bem simples, enxuta e muito útil (senão eu não estaria compartilhando).
Dúvidas? Deixe um comentário.
----------- keepReading
segunda-feira, 20 de setembro de 2010
sexta-feira, 17 de setembro de 2010
Tipografia básica para web
Desde o meu início com o desenvolvimento para web, sempre foquei mais em programação, códigos, bancos de dados do que em design. Isto por aptidão. E se falta talento e bom gosto, também me faltou informação simples, direta e suficiente para criar algo esteticamente atraente. Não uma obra-prima, mas visualmente decente.
Vamos ao básico da tipografia, que é a área do design que estuda as fontes, as letras e suas formas. A intenção não é gabaritar o leitor a ser um especialista no assunto, longe disso, e sim fornecer as bases para que as produções venham a ter funcionalidade e cumprir decentemente com seu propósito.
As serifas são os pequenos traços ou prolongamentos no fim das hastes das letras. A divisão das fontes entre tipos serifados e sem serifa é a principal divisão na tipografia.
Na mídia impressa, costuma-se usar fontes serifadas para o texto, e fontes sem serifa para títulos e outros elementos de destaque, isso mais por uma questão funcional do que estética. As serifas dão uma impressão de continuidade, o que facilita a leitura, e por isso é usada no fluxo de texto. Já as fontes sem serifa não dão esta sensação de continuidade, funcionando bem para elementos de destaque.
Mas na web a história muda. Fontes serifadas são mais difíceis de ler em monitores, e o uso de fontes sem serifa facilita a leitura.
Além da diferenciação entre fontes com e sem serifa, existem outras propriedades importantes de fontes. Os espaçamentos são uma dessas características. As fontes geralmente têm largura diferentes para letras diferentes. Quando a largura para cada letra é igual entre todas as letras, dizemos que a fonte é monoespaçada. Fontes monospace não são boas para leitura de textos, mas dão destaque em legendas e principalmente códigos fonte de programação, onde a organização visual que elas promovem ajudam o raciocínio e facilitam a leitura do código fonte.
Com o advento e suporte à propriedade @font-face no mainstream, com a abundância de formatos suportados (EOT, TTF, SVG, WOFF) pelos navegadores, e também pelo suporte a propriedades gráficas de transformação (scale, skew, rotate,...) a tipografia na web alcança um novo patamar a ser explorado pelos desenvolvedores.
Linhas muito longas ou muito curtas são mais difíceis de ler. Algo entre 50 e 90 caracteres por linha é o recomendado para leitura em telas de computador.
O distanciamento entre as letras também influi na qualidade da leitura. Encontrar o ponto de equilíbrio, de conforto, é a chave.
O distanciamento entre linhas é outro aspecto muito importante da composição. Linhas muito próximas dificultam a leitura, muito distantes não passam a sensação de unidade, de conjunto do texto.
Estes espaçamentos mudam conforme o propósito, o público-alvo, o tipo de texto, o tamanho da fonte, entre outras variáveis. Não existe uma regra de ouro, o bom senso é quem comanda (quando for o caso de mudanças). Mas via de regra, espaçamento entre linhas em 1.5 ou 1.4 é considerado como padrão para uma boa leitura. Para o espaçamento entre letras, só mude quando houver necessidade.
Não é somente através da mudança de fonte que podemos dar ênfase, destaque para algum elemento. Saber trabalhar com estes conceitos de contraste ajuda o design a ganhar volume e importância, mantendo a uniformidade do conjunto (sem bombardear o leitor com diversas fontes e cores diferentes), em outras palavras, criar a hierarquia visual.
Para texto comum, de fluxo, conteúdo, use fontes com as quais as pessoas estão habituadas. Arial, Verdana, Helvetica, Tahoma, Times New Roman, Courier New, Lucida... todas estas fontes são usadas pela maioria dos grandes sites e portais, e por um motivo simples: todos estão acostumados com elas, e geralmente tem estas fontes instaladas nos seus computadores ou celulares.
E as fontes bonitas? Use elas em elementos de destaque. No logotipo, na logomarca, nos cabeçalhos, em mensagens promocionais, etc, mas não nos textos, formulários, menus e barras de navegação.
E para completar a acessibilidade, não podemos esquecer de um antigo (mas não raro esquecido ou mal usado) recurso do CSS 2.1, as famílias genéricas de fontes. O CSS prevê 5 famílias genéricas (serif, sans-serif, monospace, cursive e fantasy), que podem (devem) ser usadas nas declarações de fontes, sempre ao final, provendo uma regra de fallback. A idéia é simples, se o usuário não tem instalada a fonte que você declarou, ou mesmo se por algum motivo a fonte não pode ser baixada/processada pelo @font-face, você fornece pelo menos a família de onde a fonte pertence, e o navegador do usuário utilizará a fonte configurada para tal fim (falando sério, isso é algo bem comum de acontecer), e ainda assim, seu site manterá a aparência de conformidade para o usuário.
Se você não entendeu, deixe-me explicar melhor com um exemplo meu, real. Eu uso Linux. Não tenho instalado aqui as fontes Helvetica e Tahoma. Alguns sites, como o google code, declaram a fonte Helvetica para ser usada (font-family: Helvetica, sans-serif;). Como eu não tenho, o Firefox, o Opera e o Chrome, vão utilizar a fonte que está configurada para o tipo sans-serif, que no meu caso é a FreeSans. O site, apesar de não aparentar da forma original que os designers gostariam, ainda podem se valer desta regra de fallback, e o Google Code, assim como muitos blogs e sites que não declaram a fonte, têm uma aparência familiar pra mim, o que gera conforto visual, e passa uma sensação de confiança (não é algo bizarro ou estranho).
Então fica o lembrete: SEMPRE usar uma família genérica junto das declarações de fonte no CSS.
10 typography tips to bring you to the next level (em inglês)
----------- keepReading
Vamos ao básico da tipografia, que é a área do design que estuda as fontes, as letras e suas formas. A intenção não é gabaritar o leitor a ser um especialista no assunto, longe disso, e sim fornecer as bases para que as produções venham a ter funcionalidade e cumprir decentemente com seu propósito.
Tipos de fonte
Com serifa e sem serifa (serif e sans-serif).As serifas são os pequenos traços ou prolongamentos no fim das hastes das letras. A divisão das fontes entre tipos serifados e sem serifa é a principal divisão na tipografia.
Na mídia impressa, costuma-se usar fontes serifadas para o texto, e fontes sem serifa para títulos e outros elementos de destaque, isso mais por uma questão funcional do que estética. As serifas dão uma impressão de continuidade, o que facilita a leitura, e por isso é usada no fluxo de texto. Já as fontes sem serifa não dão esta sensação de continuidade, funcionando bem para elementos de destaque.
Mas na web a história muda. Fontes serifadas são mais difíceis de ler em monitores, e o uso de fontes sem serifa facilita a leitura.
Além da diferenciação entre fontes com e sem serifa, existem outras propriedades importantes de fontes. Os espaçamentos são uma dessas características. As fontes geralmente têm largura diferentes para letras diferentes. Quando a largura para cada letra é igual entre todas as letras, dizemos que a fonte é monoespaçada. Fontes monospace não são boas para leitura de textos, mas dão destaque em legendas e principalmente códigos fonte de programação, onde a organização visual que elas promovem ajudam o raciocínio e facilitam a leitura do código fonte.
Com o advento e suporte à propriedade @font-face no mainstream, com a abundância de formatos suportados (EOT, TTF, SVG, WOFF) pelos navegadores, e também pelo suporte a propriedades gráficas de transformação (scale, skew, rotate,...) a tipografia na web alcança um novo patamar a ser explorado pelos desenvolvedores.
O conjunto
Não basta escolher a fonte visto que textos geralmente não são apenas uma palavra e sim um conjunto delas, com linhas e outros elementos em volta. Trabalhar este espaço é tão importante quanto a escolha da fonte, e na verdade influencia diretamente na escolha da fonte.Linhas muito longas ou muito curtas são mais difíceis de ler. Algo entre 50 e 90 caracteres por linha é o recomendado para leitura em telas de computador.
O distanciamento entre as letras também influi na qualidade da leitura. Encontrar o ponto de equilíbrio, de conforto, é a chave.
O distanciamento entre linhas é outro aspecto muito importante da composição. Linhas muito próximas dificultam a leitura, muito distantes não passam a sensação de unidade, de conjunto do texto.
Estes espaçamentos mudam conforme o propósito, o público-alvo, o tipo de texto, o tamanho da fonte, entre outras variáveis. Não existe uma regra de ouro, o bom senso é quem comanda (quando for o caso de mudanças). Mas via de regra, espaçamento entre linhas em 1.5 ou 1.4 é considerado como padrão para uma boa leitura. Para o espaçamento entre letras, só mude quando houver necessidade.
Contraste
Quando ouvimos falar de contraste, logo pensamos em cor, mas contraste é um termo mais abrangente em design. É algo que quebra o padrão de repetição. As formas básicas de contraste são: tamanho, posição, textura, cor, forma e orientação. E estes se aplicam também à tipografia.Não é somente através da mudança de fonte que podemos dar ênfase, destaque para algum elemento. Saber trabalhar com estes conceitos de contraste ajuda o design a ganhar volume e importância, mantendo a uniformidade do conjunto (sem bombardear o leitor com diversas fontes e cores diferentes), em outras palavras, criar a hierarquia visual.
Acessibilidade
Apesar de ser uma importante área do design, e existir uma infinidade de belas fontes, usar mal as fontes pode destruir o design ou pior, a credibilidade de toda a obra.Para texto comum, de fluxo, conteúdo, use fontes com as quais as pessoas estão habituadas. Arial, Verdana, Helvetica, Tahoma, Times New Roman, Courier New, Lucida... todas estas fontes são usadas pela maioria dos grandes sites e portais, e por um motivo simples: todos estão acostumados com elas, e geralmente tem estas fontes instaladas nos seus computadores ou celulares.
E as fontes bonitas? Use elas em elementos de destaque. No logotipo, na logomarca, nos cabeçalhos, em mensagens promocionais, etc, mas não nos textos, formulários, menus e barras de navegação.
E para completar a acessibilidade, não podemos esquecer de um antigo (mas não raro esquecido ou mal usado) recurso do CSS 2.1, as famílias genéricas de fontes. O CSS prevê 5 famílias genéricas (serif, sans-serif, monospace, cursive e fantasy), que podem (devem) ser usadas nas declarações de fontes, sempre ao final, provendo uma regra de fallback. A idéia é simples, se o usuário não tem instalada a fonte que você declarou, ou mesmo se por algum motivo a fonte não pode ser baixada/processada pelo @font-face, você fornece pelo menos a família de onde a fonte pertence, e o navegador do usuário utilizará a fonte configurada para tal fim (falando sério, isso é algo bem comum de acontecer), e ainda assim, seu site manterá a aparência de conformidade para o usuário.
Se você não entendeu, deixe-me explicar melhor com um exemplo meu, real. Eu uso Linux. Não tenho instalado aqui as fontes Helvetica e Tahoma. Alguns sites, como o google code, declaram a fonte Helvetica para ser usada (font-family: Helvetica, sans-serif;). Como eu não tenho, o Firefox, o Opera e o Chrome, vão utilizar a fonte que está configurada para o tipo sans-serif, que no meu caso é a FreeSans. O site, apesar de não aparentar da forma original que os designers gostariam, ainda podem se valer desta regra de fallback, e o Google Code, assim como muitos blogs e sites que não declaram a fonte, têm uma aparência familiar pra mim, o que gera conforto visual, e passa uma sensação de confiança (não é algo bizarro ou estranho).
Então fica o lembrete: SEMPRE usar uma família genérica junto das declarações de fonte no CSS.
Resumo
- Na maioria dos textos use fontes simples, comuns.
- Não utlize muitas fontes, nem muitos estilos (negrito/itálico/cores) diferentes. Se necessário, reescreva o texto.
- Use contraste como negrito, tamanho ou cores para elementos especiais ou específicos, mas procure manter a unidade e a hierarquia visual.
- Prefira fontes sem serifa para a maior parte do texto.
- Não crie linhas muito longas ou muito curtas.
- Respeite o espaçamento entre linhas.
- Sempre coloque regras de fallback.
- Permita-se usar fontes diferentes em elementos especiais como logotipos ou cabeçalhos de seção.
- Lembre-se sempre de ter famílias genéricas como fallback.
- Se possível não use fontes com tamanho abaixo de 12px.
- Use o bom senso. É melhor ficar com o lugar comum e funcional do que inventar um novo conceito que fique estranho.
Referências
On Web Typography (em inglês)10 typography tips to bring you to the next level (em inglês)
----------- keepReading
Algumas coisas sobre PHP que você provavelmente não sabia...
Pois é, tem milhares e milhares de páginas e posts na internet com um título semelhante, e chegou minha hora de escrever um também.
Depois de alguns anos de muito código e de muito polir eles me sinto confortável pra fazer um posts desse que relatem algo realmente útil e não apenas justifique o porque usar aspas simples ou duplas no echo.
Bom, o vetor $_SERVER[] tem muitas variáveis úteis, como SERVER_NAME, SCRIPT_NAME, REMOTE_ADDR, REQUEST_METHOD, HTTP_REFERER...
Claro que muitas dessas variáveis, como tudo quando se trata de web, podem ser manipuladas por usuários mal intencionados. Mas caso geral, são confiáveis.
Agora o bom mesmo é tirar vantagem da manipulação dessas variáveis, por exemplo para criar respostas on demand para requisições ajax. A idéia é setar uma variável no request header, que depois é lida pelo PHP. Se a variável estiver setada a requisição é Ajax.
No Javascript:
No PHP:
Ao invés de escrever vários códigos, um para cada plataforma (o caracter é diferente para UNIX, Mac e Windows), usei apenas essa constante. Mas existem outras úteis como o PATH_SEPARATOR.
NOTA: Muitas das constantes são REALMENTE úteis para internacionalização da aplicação, juntamente das funções setlocale.
Basicamente é a mesma coisa que um if else. Só que é interessante notar que dá pra usar ele (e aí sim ver toda sua elegância) diretamente em atribuições ou returns.
Funções são simples de escrever, rápidas, poupam trabalho, limpam o código principal... Enfim, são o primeiro passo rumo a deixar de ser o sobrinho que faz sites.
A extensão filter simplifica a validação e higienização de variáveis, além de fornecer funções prontas para tipos de validação comuns e/ou padronizadas. Checar se um email ou uma URL passada num formulário é válido e limpar se for o caso é muito fácil.
Claro, ela também é flexível, e fornece uma opção de callback. Então crie sua função para validar CPF, e use a extensão filter a partir de agora.
array_unique, uasort, array_intersect, array_search, array_diff, array_walk... Existe um grande número de funções úteis que geralmente por ignorância são reescritas (nem sempre da melhor forma) pelos programadores, incorrendo no caso da reinvenção da roda.
Além de poupar trabalho, você pode se valer disso para aprender através da leitura destes códigos, e com o tempo, pode inclusive modificar estes códigos quando for usar. Adaptar às suas necessidades ou corrigir um bug.
Geralmente o que se discute quando o assunto são boas práticas e estilo são formas e padrões de se escrever o código, mas quase nunca se fala em:
Até a próxima.
----------- keepReading
Depois de alguns anos de muito código e de muito polir eles me sinto confortável pra fazer um posts desse que relatem algo realmente útil e não apenas justifique o porque usar aspas simples ou duplas no echo.
1 - Use variáveis de servidor
Vemos muita aplicação dos arrays $_GET, $_POST e $_SESSION por aí. Fora eles, dificilmente vemos algum tutorial ou artigo falando dos outros arrays, como $_COOKIE, $_REQUEST, $_ENV, $_SERVER, $_FILES....Bom, o vetor $_SERVER[] tem muitas variáveis úteis, como SERVER_NAME, SCRIPT_NAME, REMOTE_ADDR, REQUEST_METHOD, HTTP_REFERER...
Claro que muitas dessas variáveis, como tudo quando se trata de web, podem ser manipuladas por usuários mal intencionados. Mas caso geral, são confiáveis.
Agora o bom mesmo é tirar vantagem da manipulação dessas variáveis, por exemplo para criar respostas on demand para requisições ajax. A idéia é setar uma variável no request header, que depois é lida pelo PHP. Se a variável estiver setada a requisição é Ajax.
No Javascript:
var myXHR = new XMLHttpRequest();
myXHR.setRequestHeader("X_HTTP_REQUESTED_WITH", "XMLHttpRequest");
// resto do código
myXHR.setRequestHeader("X_HTTP_REQUESTED_WITH", "XMLHttpRequest");
// resto do código
No PHP:
<?php
//código...
//agora na hora da saída
if (isset($_SERVER['X_HTTP_REQUESTED_WITH'] && $_SERVER['X_HTTP_REQUESTED_WITH'] == "XMLHttpRequest") {
echo $output;
} else {
include("header.php");
echo $output;
include("bottom.php");
}
?>2 - Constantes pré-definidas
Usar constantes do sistema deixa o código mais bonito e portável. Aprendi isso usando a constante PHP_EOL (fim de linha) para escrever uma classe de email.Ao invés de escrever vários códigos, um para cada plataforma (o caracter é diferente para UNIX, Mac e Windows), usei apenas essa constante. Mas existem outras úteis como o PATH_SEPARATOR.
NOTA: Muitas das constantes são REALMENTE úteis para internacionalização da aplicação, juntamente das funções setlocale.
3 - Operador Ternário
Seja lá qual for a lista de top 10, 20, 382 dicas de PHP, operador ternário tá no meio. E não é a toa. Ele é simples, higiênico e poderoso.Basicamente é a mesma coisa que um if else. Só que é interessante notar que dá pra usar ele (e aí sim ver toda sua elegância) diretamente em atribuições ou returns.
<?php
$var = 10;
echo ($var >= 10) ? 'Great!' : 'Damn!';
return (mail()) ? 'Sent with success' : 'Sorry... bad server';
?>
$var = 10;
echo ($var >= 10) ? 'Great!' : 'Damn!';
return (mail()) ? 'Sent with success' : 'Sorry... bad server';
?>
4 - Escreva funções
Outro jargão, mas que merece estar aqui também. Escrever funções e rotinas é o básico do básico em programação. Não adianta você querer aprender OOP, ou Design Patterns, se não sabe fazer o arroz com feijão.Funções são simples de escrever, rápidas, poupam trabalho, limpam o código principal... Enfim, são o primeiro passo rumo a deixar de ser o sobrinho que faz sites.
5 - Extensão Filter
Extensão não muito conhecida, e menos ainda falada e comentada. Disponível built-in desde a versão 5.2 do PHP (ou seja, tem em quase todo host decente).A extensão filter simplifica a validação e higienização de variáveis, além de fornecer funções prontas para tipos de validação comuns e/ou padronizadas. Checar se um email ou uma URL passada num formulário é válido e limpar se for o caso é muito fácil.
Claro, ela também é flexível, e fornece uma opção de callback. Então crie sua função para validar CPF, e use a extensão filter a partir de agora.
6 - Arrays
Mais um da galeria dos óbvios que estaria aqui. Bem, não tão óbvio, senão não estaria aqui. Se você já teve contato com programação mais de 3 dias na vida, já conhece os arrays. Mas o que você provavelmente desconhece são as funções para lidar com eles.array_unique, uasort, array_intersect, array_search, array_diff, array_walk... Existe um grande número de funções úteis que geralmente por ignorância são reescritas (nem sempre da melhor forma) pelos programadores, incorrendo no caso da reinvenção da roda.
PEAR, PECL e Tuning
Ainda no tema de parar de reinventar a roda, saiba que você pode - e deveria - consultar repositórios de códigos como o PEAR, o PECL e o PHPClasses. Existem muitas soluções prontas na web para resolver problemas que você tem exatamente agora. E geralmente soluções feitas por programadores mais experientes ou mesmo por comunidades inteiras.Além de poupar trabalho, você pode se valer disso para aprender através da leitura destes códigos, e com o tempo, pode inclusive modificar estes códigos quando for usar. Adaptar às suas necessidades ou corrigir um bug.
Conclusão
Todas as "dicas" que coloquei aqui se resumem a algumas noções não-tão-comuns sobre boas práticas.Geralmente o que se discute quando o assunto são boas práticas e estilo são formas e padrões de se escrever o código, mas quase nunca se fala em:
- Aproveitar o que o sistema te oferece de forma nativa
- Explorar o que a linguagem tem de recursos
- Explorar o que já foi feito pela comunidade
Até a próxima.
----------- keepReading
quinta-feira, 16 de setembro de 2010
Como os crawlers funcionam?
Crawler, spider, bot, entre outros nomes, são programas que navegam na internet e indexam conteúdo. Os mais famosos de longe são os do google e do yahoo. Mas existem diversos, e o funcionamento básico deles é bem parecido (o que difere é como cada sistema organiza e classifica as páginas para mostrar nos resultados).
De alguma forma eles chegam à sua página, seja buscando nos bancos de DNS disponíveis na internet, ou seguindo um link. E quando chegam na sua página, eis o que eles fazem:
Primero lêem sua página, mais especificamente, o código HTML da sua página. E antes de começarem a analisar o que sua página faz ou vende, eles tentam separar os links, links internos, action de formulários... Note que eles não leem e não executam scripts, formatos de arquivo estranhos como PDF, imagens, nem nada do tipo.
Alguns buscadores é claro também indexam fotos (juntamente com o atributo alt), arquivos em flash, PDFs e outros arquivos, mas isso é outro assunto. O importante é entender que eles, antes de qualquer outra coisa, tentam descobrir o quais são as páginas dentro do seu site, e isso só pode ser feito desta forma, através do seu código HTML.
Se você possui um arquivo ou mesmo um diretório inteiro, que não esteja conectado a nenhuma página, seja através de um link, de um atributo src ou href, este arquivo ou diretório não será magicamente descoberto pelo crawler.
Bom, os crawlers do buscadores geralmente procuram informações sobre permissões sobre o conteúdo. Em espcial existem duas formas de bloquear um crawler decente de indexar uma determinada página (e os links nela contidos). A primeira forma, e mais comum, é através do arquivo robots.txt. A outra forma é através da tag meta robots, com valor "noindex" ou "nofollow", usados para não indexar (a própria página) e não seguir (os links contidos na página), respectivamente. Há também uma terceira possibilidade, muito menos explorada, que é o uso do atributo rel="nofollow" em links, indicando ao crawler que aquele link em especial não deve ser seguido.
Recapitulando... o crawler chega na sua página, lê o código HTML, procura o arquivo robots.txt, confere os links da página, confere se há alguma tag meta específica para ele, depois organiza o que ele deve seguir ou não dentro e a partir do seu site.
Ah sim, uma outra forma de um crawler indexar páginas e conteúdos é através de outros sites. Vamos supor que você tem uma página no seu site, chamada apropriadamente de secredo.html.
Se você digitar direto na barra de endereço, você acessa essa página, mas a partir de todas suas outras páginas não existe link para esta página. Certo, os crawlers nunca descobrirão esta página, de acordo com o que expliquei acima. Porém um amigo seu coloca o link desta página no site dele. Pronto, agora sua página secreta está pronta para ser indexada pelos crawlers.
Claro que usar uma restrição no robots.txt ou uma tag meta basta para que os bons crawlers não indexem esta página, afinal o autor (no caso você) explicitamente não quer que isso aconteça.
Mas nem todos buscadores são tão corretos (google, yahoo, bing, ask, baidu,... esses são). Os crawlers do mal às vezes se baseiam exatamente nas restrições para fazer descobertas e indexar conteúdo. Mas isso não é de longe motivo para alarde, afinal, a maioria desses bad crawlers não são famosos, não tem visitantes, e na maioria das vezes nem mesmo cacife financeiro para sobreviver muito tempo.
Bem, espero que eu tenha esclarecido como o processo de descoberta e indexação funciona. O processo de organização das informações como eu disse, é o que é diferente entre os buscadores.
Até a próxima.
----------- keepReading
De alguma forma eles chegam à sua página, seja buscando nos bancos de DNS disponíveis na internet, ou seguindo um link. E quando chegam na sua página, eis o que eles fazem:
Primero lêem sua página, mais especificamente, o código HTML da sua página. E antes de começarem a analisar o que sua página faz ou vende, eles tentam separar os links, links internos, action de formulários... Note que eles não leem e não executam scripts, formatos de arquivo estranhos como PDF, imagens, nem nada do tipo.
Alguns buscadores é claro também indexam fotos (juntamente com o atributo alt), arquivos em flash, PDFs e outros arquivos, mas isso é outro assunto. O importante é entender que eles, antes de qualquer outra coisa, tentam descobrir o quais são as páginas dentro do seu site, e isso só pode ser feito desta forma, através do seu código HTML.
Se você possui um arquivo ou mesmo um diretório inteiro, que não esteja conectado a nenhuma página, seja através de um link, de um atributo src ou href, este arquivo ou diretório não será magicamente descoberto pelo crawler.
Bom, os crawlers do buscadores geralmente procuram informações sobre permissões sobre o conteúdo. Em espcial existem duas formas de bloquear um crawler decente de indexar uma determinada página (e os links nela contidos). A primeira forma, e mais comum, é através do arquivo robots.txt. A outra forma é através da tag meta robots, com valor "noindex" ou "nofollow", usados para não indexar (a própria página) e não seguir (os links contidos na página), respectivamente. Há também uma terceira possibilidade, muito menos explorada, que é o uso do atributo rel="nofollow" em links, indicando ao crawler que aquele link em especial não deve ser seguido.
Recapitulando... o crawler chega na sua página, lê o código HTML, procura o arquivo robots.txt, confere os links da página, confere se há alguma tag meta específica para ele, depois organiza o que ele deve seguir ou não dentro e a partir do seu site.
Ah sim, uma outra forma de um crawler indexar páginas e conteúdos é através de outros sites. Vamos supor que você tem uma página no seu site, chamada apropriadamente de secredo.html.
Se você digitar direto na barra de endereço, você acessa essa página, mas a partir de todas suas outras páginas não existe link para esta página. Certo, os crawlers nunca descobrirão esta página, de acordo com o que expliquei acima. Porém um amigo seu coloca o link desta página no site dele. Pronto, agora sua página secreta está pronta para ser indexada pelos crawlers.
Claro que usar uma restrição no robots.txt ou uma tag meta basta para que os bons crawlers não indexem esta página, afinal o autor (no caso você) explicitamente não quer que isso aconteça.
Mas nem todos buscadores são tão corretos (google, yahoo, bing, ask, baidu,... esses são). Os crawlers do mal às vezes se baseiam exatamente nas restrições para fazer descobertas e indexar conteúdo. Mas isso não é de longe motivo para alarde, afinal, a maioria desses bad crawlers não são famosos, não tem visitantes, e na maioria das vezes nem mesmo cacife financeiro para sobreviver muito tempo.
Bem, espero que eu tenha esclarecido como o processo de descoberta e indexação funciona. O processo de organização das informações como eu disse, é o que é diferente entre os buscadores.
Até a próxima.
----------- keepReading
Qual a diferença?
No meio do boom de possibilidades e novos recursos trazidos pelo CSS3 temos as Media Queries. E do meu ponto de vista esse novo recurso vem numa velha roupagem, trazendo junto algo que parece persistir no mundo do desenvolvimento para web.
Com as media queries do CSS3 essas possibilidades foram estendidas para propriedades dos meios. Por exemplo, largura ou altura da tela (ou da folha), quantidade de cores, resolução, etc. Isso é media query.
Com as medias queries é possível detectar larguras, alturas, orientação da tela, etc, e com isso formatar o conteúdo de acordo, deixando um aspecto muito mais agradável e legível para as páginas. Seja num smarthphone, seja numa TV full HD de 30+ polegadas, seja numa folha A4, seja num outdoor.
Assim, agora as folhas de estilo poderão se adaptar aos dispositivos e meios onde serão mostradas, tudo sem nenhuma linha de script ou programação adicional, apenas com marcação HTML/XML e CSS.
Mas falando sobre o lado ruim do operacional, da hora do vamos ver, o problema é que as media queries podem adicionar trabalho de forma desnecessária e ineficiente. Explico. Ou você vai aumentar muito o tamanho dos arquivos CSS, ou vai criar algumas dezenas.
Como mencionei antes, o CSS 2 já previa o uso de arquivos CSS diferentes, baseados em mídias e dispositivos diferentes. Uma das abordagens adotadas era - e ainda é - deixar um redirecionamento para um domínio específico ou uma folha de estilo específica quando acontecer do dispositivo se enquadrar na media handheld.
Para se ter uma idéia, o Yahoo!, o Youtube, o A List Apart, o McDonald's e o Walmart adotam esta solução ainda hoje.
Eles tem as tags
Frente ao mercado atual de tecnologias disponíveis e de dispositivos/suporte, temos algumas soluções que fazem sentido e outras nem tanto.
A primeira seria usar apenas o atributo media para importar um arquivo CSS para handhelds. É uma solução muito difundida, talvez a mais difundida. É eficiente, testada, funcional. O problema é que as capacidades variam de acordo com os dispositivos móveis. Largura, altura, resolução, cores e orientação são as mais significativas em termos de design (por isso as media queries foram criadas).
Outra solução é adotar um subdomínio diferente. Esta solução também é bastante popular, mas recebe duras críticas. O motivo é simples. Se para cada faixa de resolução for criado um novo subdomínio e uma nova folha de estilo, isso pode gerar um monstro dentro de alguns anos. Bem, isso é um ponto de vista dos teóricos. Na prática, esta abordagem traz alguns outros benefícios, como o lado do servidor, que pode processar e gerar respostas mais leves (usar outras imagens, remover flash, javascript, anúncios...), o que é muito interessante para quem usa dispositivos móveis, afinal é consumo de banda menor, download e processamento mais rápidos.
Usar media queries para importar diferentes estilos. A idéia queridinha do momento. Mas ninguém pensa (ou apenas ignora, ou dá importância menor) no fato de que neste caso, várias folhas de estilo são necessárias, o que representa um problema tão grande para a manutenção quanto ter um domínio separado. HTML com cabeçalho maior para TODOS os casos, e uma trabalheira muito grande para os desenvolvedores e designers.
Usar media queries dentro do arquivo CSS para criar regras específicas para determinados dispositivos. Parece interessante, mas o arquivo ficaria simplesmente gigante, com uma variação de regras repetidas várias vezes. Continua uma solução estranha, com um arquivo de CSS ruim de dar manutenção, e extremamente grande pra baixar e lento pra processar.
Usar um (ou mais, caso necessário) domínio alternativo, e fazer uso de redirecionamentos com a tag link. Um para dispositivos móveis, um para desktops normais, e talvez um para monitores grandes e TVs. Eu sou a favor do uso de domínios alternativos principalmente pelo fato de poder valer-se de programação server-side e fornecer conteúdos diferentes, economizando banda e outros recursos dos clientes.
Para cada domínio, um CSS diferente. Apesar de parecer mais complicado, é mais leve, depois de um arquivo CSS pronto, basta duplicar o conteúdo e adicionar/subtrair algumas regras.
Ah sim, nestes arquivos CSS diferentes sim usar as media queries. Continua aumentando o número de regras, mas é muito mais conveniente e leve fazer desta forma, ao invés de servir um único arquivo CSS grande.
Antes não haviam padrões W3C para realizar este tipo de tarefa, e sempre que o assunto pende para este lado, surgem defensores fanáticos ressaltando todos os pontos ruins de uma solução em javascript (não é standard, e não serve para todos os dispositivos). Apesar de ter um fundo de verdade nesta afirmação, na prática 99.8% do fluxo na internet vai para navegadores que contam com esta tecnologia, daí o porque deste fanatismo ser exacerbado em meu ponto de vista (que sou um standardista).
Agora temos as media queries, um jeito W3C de fazer essa diferenciação para dispositivos diferentes. No entanto, a necessidade de ter marcações ou regras diferentes para dispositivos diferentes continua existindo, assim como o trabalho de criar regras diferentes.
O fiel da balança, junto desta necessidade de servir conteúdos/formatos diferentes, é o usuário. Se por um lado temos como servir estes conteúdos, o forma de serví-los pode não ser otimizada. Por que ter um aumento de 150% no tamanho do arquivo CSS, sendo que pode-se criar um domínio separado, e servir arquivos menores (inclusive o output HTML menor)? O que é melhor para os usuários? E para os desenvolvedores? Será que criar mais de uma folha de estilo é tão complicado assim, ou seria melhor para fazer manutenção?
Sou a favor do uso das media queries, mas não como solução única, absoluta e ótima. Cada caso deve ser analisado, e outros fatores devem sim ser levados em consideração, principalmente no que diz respeito aos usuários.
----------- keepReading
O que são as media queries?
No CSS 2, havia a possibilidade de definir folhas de estilo diferentes para meios diferentes. O exemplo clássico é usar duas folhas distintas, uma para leitura na tela com fontes sans-serif, e uma para impressão com fontes serif, melhorando a legibilidade do conteúdo segundo onde ele for usado. O CSS 2 define alguns tipos de media, a saber:- all
- braille
- embossed
- tv
- tty
- handheld
- screen
- projection
- speech/aural
Com as media queries do CSS3 essas possibilidades foram estendidas para propriedades dos meios. Por exemplo, largura ou altura da tela (ou da folha), quantidade de cores, resolução, etc. Isso é media query.
Por que o estardalhaço com isso?
Resumidamente: por causa da expansão da internet 3G e nos dispositivos móveis capazes de navegar na internet.Com as medias queries é possível detectar larguras, alturas, orientação da tela, etc, e com isso formatar o conteúdo de acordo, deixando um aspecto muito mais agradável e legível para as páginas. Seja num smarthphone, seja numa TV full HD de 30+ polegadas, seja numa folha A4, seja num outdoor.
Assim, agora as folhas de estilo poderão se adaptar aos dispositivos e meios onde serão mostradas, tudo sem nenhuma linha de script ou programação adicional, apenas com marcação HTML/XML e CSS.
Se essas media queries são um recurso tão legal, qual o problema?
O problema disso é a carga de trabalho para criação e manutenção, além da postura de alguns sites e entusiastas que proclamam esta solução como definitiva. Rotular algo como definitivo é um tiro no pé, e isso é duplamente verdade no mundo da tecnologia. Nada é definitivo porque ninguém pode prever o mercado dentro de 5 ou 10 anos.Mas falando sobre o lado ruim do operacional, da hora do vamos ver, o problema é que as media queries podem adicionar trabalho de forma desnecessária e ineficiente. Explico. Ou você vai aumentar muito o tamanho dos arquivos CSS, ou vai criar algumas dezenas.
Como se fazia antes?
É engraçado notar que sites para dispositivos móveis existem a mais de 10 anos. Claro que a quantidade de sites aumentou muito com o aumento da participação do mercado na internet destes dispositivos, e com a evolução das tecnologias. O que antes era raro, agora é tendência. Antes era WAP, agora é HTML e CSS mesmo, só que mais enxuto.Como mencionei antes, o CSS 2 já previa o uso de arquivos CSS diferentes, baseados em mídias e dispositivos diferentes. Uma das abordagens adotadas era - e ainda é - deixar um redirecionamento para um domínio específico ou uma folha de estilo específica quando acontecer do dispositivo se enquadrar na media handheld.
Para se ter uma idéia, o Yahoo!, o Youtube, o A List Apart, o McDonald's e o Walmart adotam esta solução ainda hoje.
Eles tem as tags
<!-- este faz o redirecionamento para um domínio separado -->
<link rel="alternate" href="http://m.domain.com" media="handheld" />
ou
<!-- este aponta para uma folha de estilo separada -->
<link rel="stylesheet" type="text/css" href="mobileStyle.css" media="handheld" />
<link rel="alternate" href="http://m.domain.com" media="handheld" />
ou
<!-- este aponta para uma folha de estilo separada -->
<link rel="stylesheet" type="text/css" href="mobileStyle.css" media="handheld" />
Abordagens alternativas e seus pontos positivos e negativos
Estas claro que não são as únicas soluções, mas são as mais difundidas atualmente. E com as Media Queries do CSS3, surge uma leva de críticos teóricos a este modelo. Uma das críticas é que o conteúdo fica espalhado. Vários domínios, várias folhas de estilo... É ruim para o controle, etc...Frente ao mercado atual de tecnologias disponíveis e de dispositivos/suporte, temos algumas soluções que fazem sentido e outras nem tanto.
A primeira seria usar apenas o atributo media para importar um arquivo CSS para handhelds. É uma solução muito difundida, talvez a mais difundida. É eficiente, testada, funcional. O problema é que as capacidades variam de acordo com os dispositivos móveis. Largura, altura, resolução, cores e orientação são as mais significativas em termos de design (por isso as media queries foram criadas).
Outra solução é adotar um subdomínio diferente. Esta solução também é bastante popular, mas recebe duras críticas. O motivo é simples. Se para cada faixa de resolução for criado um novo subdomínio e uma nova folha de estilo, isso pode gerar um monstro dentro de alguns anos. Bem, isso é um ponto de vista dos teóricos. Na prática, esta abordagem traz alguns outros benefícios, como o lado do servidor, que pode processar e gerar respostas mais leves (usar outras imagens, remover flash, javascript, anúncios...), o que é muito interessante para quem usa dispositivos móveis, afinal é consumo de banda menor, download e processamento mais rápidos.
Usar media queries para importar diferentes estilos. A idéia queridinha do momento. Mas ninguém pensa (ou apenas ignora, ou dá importância menor) no fato de que neste caso, várias folhas de estilo são necessárias, o que representa um problema tão grande para a manutenção quanto ter um domínio separado. HTML com cabeçalho maior para TODOS os casos, e uma trabalheira muito grande para os desenvolvedores e designers.
Usar media queries dentro do arquivo CSS para criar regras específicas para determinados dispositivos. Parece interessante, mas o arquivo ficaria simplesmente gigante, com uma variação de regras repetidas várias vezes. Continua uma solução estranha, com um arquivo de CSS ruim de dar manutenção, e extremamente grande pra baixar e lento pra processar.
Usa ou não usar?
Faladas as soluções (ou futuras tendências de), hora de pesar cada coisa, e de escolher uma abordagem. Claro que isto irá variar de caso para caso, mas no geral, as minhas consideração estão abaixo.Usar um (ou mais, caso necessário) domínio alternativo, e fazer uso de redirecionamentos com a tag link. Um para dispositivos móveis, um para desktops normais, e talvez um para monitores grandes e TVs. Eu sou a favor do uso de domínios alternativos principalmente pelo fato de poder valer-se de programação server-side e fornecer conteúdos diferentes, economizando banda e outros recursos dos clientes.
Para cada domínio, um CSS diferente. Apesar de parecer mais complicado, é mais leve, depois de um arquivo CSS pronto, basta duplicar o conteúdo e adicionar/subtrair algumas regras.
Ah sim, nestes arquivos CSS diferentes sim usar as media queries. Continua aumentando o número de regras, mas é muito mais conveniente e leve fazer desta forma, ao invés de servir um único arquivo CSS grande.
Conclusões
Media queries são um novo recurso muito interessante e poderoso sem sombra de dúvidas. Mas do meu ponto de vista ele não resolve perfeitamente a condição de ter que filtrar de alguma forma informações do cliente. Aliás, esta realidade de exibir páginas diferentes (layouts diferentes) é algo que depende do mercado de monitores, dispositivos, browsers, e não tem como servir um conteúdo único, apenas um arquivo html e um arquivo CSS, que enquadre todas as soluções de forma otimizada. No passado e no presente bibliotecas javascript serviram a este propósito, agora temos como fazer isso em CSS.Antes não haviam padrões W3C para realizar este tipo de tarefa, e sempre que o assunto pende para este lado, surgem defensores fanáticos ressaltando todos os pontos ruins de uma solução em javascript (não é standard, e não serve para todos os dispositivos). Apesar de ter um fundo de verdade nesta afirmação, na prática 99.8% do fluxo na internet vai para navegadores que contam com esta tecnologia, daí o porque deste fanatismo ser exacerbado em meu ponto de vista (que sou um standardista).
Agora temos as media queries, um jeito W3C de fazer essa diferenciação para dispositivos diferentes. No entanto, a necessidade de ter marcações ou regras diferentes para dispositivos diferentes continua existindo, assim como o trabalho de criar regras diferentes.
O fiel da balança, junto desta necessidade de servir conteúdos/formatos diferentes, é o usuário. Se por um lado temos como servir estes conteúdos, o forma de serví-los pode não ser otimizada. Por que ter um aumento de 150% no tamanho do arquivo CSS, sendo que pode-se criar um domínio separado, e servir arquivos menores (inclusive o output HTML menor)? O que é melhor para os usuários? E para os desenvolvedores? Será que criar mais de uma folha de estilo é tão complicado assim, ou seria melhor para fazer manutenção?
Sou a favor do uso das media queries, mas não como solução única, absoluta e ótima. Cada caso deve ser analisado, e outros fatores devem sim ser levados em consideração, principalmente no que diz respeito aos usuários.
----------- keepReading
terça-feira, 14 de setembro de 2010
Web Semântica: HTML5 e Microformats
O que é Web Semântica?
No início da internet, tivemos o HTML para criar e marcar o conteúdo. Com ele, que é usado até hoje em todas as páginas existentes, é possível criar textos, links, inserir imagens e tabelas, formulários, e muito mais. Porém a classificação e o uso destes elementos permite apenas funcionalidade e não significado. Um link geralmente assume a forma de um texto ou imagem, que uma vez clicado leva a outra página, mas não diz o significado, a natureza dessa relação. Adicionar significado à relação dos elementos é a idéia principal por trás da semantica na web.Por que é importante?
Para os usuários a diferença não é tão transparente ou mesmo útil no dia a dia. Pouca ou nenhuma funcionalidade nova é agregada para a intereção do usuário. Mas para os buscadores e indexadores, isso faz toda a diferença, e isso sim acaba afetando a qualidade da navegação dos usuários, além das relações comerciais (ou não) entre os próprios sites. Um exemplo seria procurar restaurantes, com determinada faixa de preço, com boa avaliação dos frequentadores, em determinada região. Outro exemplo seria procurar todos os artigos de um determinado autor que estão publicados sob determinada licensa de uso.Hmm... será que isso pega?
Essa idéia é relativamente antiga. Nenhum buscador tinha esse tipo de tecnologia, por isso ninguém investia em desenvolver padrões ou criar sites com esses recursos. Hoje os buscadores (Yahoo!, Google, Bing entre outros) já tem suporte a ler e classificar essas informações. O que está em falta são sites que implementem esses recursos. Os que implementam certamente ganham destaque (e todos os grandes sites já implementaram ou estão implementando).Não existe um único formato de se adicionar significado aos elementos. Dos padrões mais conhecidos temos o RDFa e os Microformats, com uma certa vantagem em maturidade e simplicidade para este último. Mas a semantica ganhou mais força junto com o suporte dos buscadores, e com o HTML5 (que é o grande preferido entre os buscadores agora).
Se faltam páginas com microformats, falta ainda mais páginas feitas em HTML5. E pra completar a história, o HTML5 já preve o uso de muitos microformats, entre outros mecanismos úteis para adicionar significado de uma forma ordenada.
#Comofas?
A semantica é adicionada através de atributos dos elementos. Os microformats usam geralmente o atributo class, mas também se valem em alguns casos dos atributos id e rel.Como este post NÃO É um tutorial, por hora recomendo a leitura das especificações: HTML5 Metadata, HTML5 rel values, Microformats.
O único ponto de conflito que vejo entre microformats e HTML5 é o uso do atributo rel. O HTML5 define uma lista de possíveis valores que podem ser usados (e alguns valores sugeridos pelos Microformats não estão nesta lista). O jeito de contornar estes conflitos, mantendo consistência com a especificação do HTML5, seria adotar o mecanismo de metadados do próprio HTML5 para fazer essas marcações ao invés de usar os Microformats. No mais, geralmente os dois, Microformats e HTML5 são completamente compatíveis.
Conclusão
A web semântica é vista como tendência futura a muito tempo, e com o impulso dado pelos buscadores e pelo HTML5, espero que os desenvolvedores comecem a adotar o uso dos mesmos em breve.----------- keepReading
sábado, 4 de setembro de 2010
Criando bordas semi-transparentes com CSS3 (ou CSS3 glass effect borders)
Criando bordas semi-transparentes com CSS3
O CSS3 está aí, junto com o HTML5, e mesmo que ainda não seja seguro ou mesmo viável pela disponibilidade de suporte, usar todos os recursos, existem muitos efeitos que podem ser usados a partir de agora.
O que vamos fazer aqui não é nada novo, afinal, as bordas arredondadas ou molduras estão presentes na maioria dos sites, mas a criação das mesmas ainda é feita de forma que a partir de agora é desnecessariamente complicada. O CSS3 traz um jeito clean de se alcançar estes efeitos.
Onde cai bem?
Lightboxes, overlays, mega dropdowns... elementos de destaque em geral.
A marcação
O estilo
Isto funciona bem para o Firefox 3.5+, Chrome, Safari e Opera. Como podemos ver as regras necessárias para criar o box e estilizá-lo são bem simples. Fazemos uso apenas de border-radius e cores rgba dos recursos do CSS3. Note que apesar de tudo, ainda temos duas divs (o que semanticamente não é tão correto assim, mas é melhor que as soluções anteriores, onde haviam 10 ou mais divs aninhadas). Isto por causa do box model. Quando usamos apenas uma div a cor de fundo da div se mescla com a cor de fundo da borda, tirando o efeito desejado.
Para o IE, o border-radius não funciona - pra variar. Antes de continuar com a seção dos poréns, vale dar uma lida no meu artigo anterior.
OK, hora das regras de fallback. Para as bordas a regra mais acessível é ligeiramente diferente de background. Para a cor de fundo vamos usar a seguinte cadeia de regras: cor sólida, imagem, cor rgba. Para bordas utilizaremos cor sólida e cor rgba. Isto porque os navegadores que suportam imagens de fundo para bordas, através da propriedade CSS3 específica border-image, via de regra aceitam cores rgba.
Então reescrevendo as regras com os fallbacks (na folha de estilo exclusiva para IE) temos:
Até a próxima
----------- keepReading
O CSS3 está aí, junto com o HTML5, e mesmo que ainda não seja seguro ou mesmo viável pela disponibilidade de suporte, usar todos os recursos, existem muitos efeitos que podem ser usados a partir de agora.
O que vamos fazer aqui não é nada novo, afinal, as bordas arredondadas ou molduras estão presentes na maioria dos sites, mas a criação das mesmas ainda é feita de forma que a partir de agora é desnecessariamente complicada. O CSS3 traz um jeito clean de se alcançar estes efeitos.
Onde cai bem?
Lightboxes, overlays, mega dropdowns... elementos de destaque em geral.
A marcação
<div id="moldura">
<div>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum vitae venenatis nisl. Nulla eu convallis ante. Nam non lectus mi. Proin porta, ante eu aliquam vestibulum, ligula sem pellentesque lectus, sit amet pulvinar dolor neque vel arcu. Duis id tellus eu purus blandit adipiscing. Phasellus malesuada rhoncus elit id semper. Curabitur mollis aliquam elit. Aenean in enim vitae massa pretium viverra vitae sit amet ipsum. Donec in lorem felis. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos.</p>
</div>
</div>
<div>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum vitae venenatis nisl. Nulla eu convallis ante. Nam non lectus mi. Proin porta, ante eu aliquam vestibulum, ligula sem pellentesque lectus, sit amet pulvinar dolor neque vel arcu. Duis id tellus eu purus blandit adipiscing. Phasellus malesuada rhoncus elit id semper. Curabitur mollis aliquam elit. Aenean in enim vitae massa pretium viverra vitae sit amet ipsum. Donec in lorem felis. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos.</p>
</div>
</div>
O estilo
* {margin:0px; padding: 0px;}
.moldura {width: 360px; border: 8px solid rgba(0,0,0,0.3); -moz-border-radius: 10px; border-radius: 10px;}
.moldura div {background-color: rgba(255,255,255,0.7); padding: 0.5em;}
.moldura {width: 360px; border: 8px solid rgba(0,0,0,0.3); -moz-border-radius: 10px; border-radius: 10px;}
.moldura div {background-color: rgba(255,255,255,0.7); padding: 0.5em;}
Isto funciona bem para o Firefox 3.5+, Chrome, Safari e Opera. Como podemos ver as regras necessárias para criar o box e estilizá-lo são bem simples. Fazemos uso apenas de border-radius e cores rgba dos recursos do CSS3. Note que apesar de tudo, ainda temos duas divs (o que semanticamente não é tão correto assim, mas é melhor que as soluções anteriores, onde haviam 10 ou mais divs aninhadas). Isto por causa do box model. Quando usamos apenas uma div a cor de fundo da div se mescla com a cor de fundo da borda, tirando o efeito desejado.
Para o IE, o border-radius não funciona - pra variar. Antes de continuar com a seção dos poréns, vale dar uma lida no meu artigo anterior.
OK, hora das regras de fallback. Para as bordas a regra mais acessível é ligeiramente diferente de background. Para a cor de fundo vamos usar a seguinte cadeia de regras: cor sólida, imagem, cor rgba. Para bordas utilizaremos cor sólida e cor rgba. Isto porque os navegadores que suportam imagens de fundo para bordas, através da propriedade CSS3 específica border-image, via de regra aceitam cores rgba.
Então reescrevendo as regras com os fallbacks (na folha de estilo exclusiva para IE) temos:
.moldura {border: 8px solid #000;}
/* criamos uma imagem PNG de 1x1 pixel de cor branca, e com opacidade de 80% */
.moldura div {background-color: transparent; background-image: url('white_80.png');}
/* criamos uma imagem PNG de 1x1 pixel de cor branca, e com opacidade de 80% */
.moldura div {background-color: transparent; background-image: url('white_80.png');}
Até a próxima
----------- keepReading
Por que tudo igual?
Este artigo é inspirado nos artigos Ignorance Is Bliss, de Andy Clarke, e Make Your Mockup In Markup, de Meagan Fisher, publicados no 24ways.
Um dos pontos mais problemáticos no desenvolvimento de um site, ao lado da acessibilidade, é o layout. Em especial fazer com que o site tenha exatamente a mesma aparência em todos os navegadores, em todas as plataformas e em todas as resoluções de tela.
Para esta tarefa, esta meta, não preciso dizer que além de muito trabalho, limita o desenvolvedor nos recursos que podem ser utilizados e na infinidade de hacks necessários. Este ideal é praticamente utópico e conflita diretamente com dois interesses: o do desenvolvedor de realizar um trabalho de qualidade (criar uma solução efetiva, padronizada, acessível) e com o do cliente, porque influi diretamente em prazos e custos.
Pois bem, em primeiro lugar, se você ainda cria algo no Photoshop ou qualquer outro software de processamento de imagem, fornecendo uma foto do trabalho que será realizado ao cliente, pare agora. Quando você fornece uma foto, uma imagem, você cria expectativas no cliente, e mais tarde quem vai ralar para conseguir atingir esta expectativa a qualquer custo é você mesmo.
Para o processo de aprovação do layout, use um site. Crie um site, sem efeitos, sem interatividade, e esclareça isso ao cliente. Diga que fará um site, sem programação ou interatividade porque isto demandam trabalho, e que não é a versão final, é apenas para avaliação estética, do layout.
A partir de então, faça a marcação em HTML bem feita, e trabalhe o CSS. Pronto. Se você fizer, utilizando o Firefox ou o Chrome, e o cliente ver no Firefox, ótimo. Se ele ver no Internet Explorer, mas mesmo assim aprovar, não tem porque você gastar horas polindo alguns detalhes mínimos.
Trabalhando desta forma, sem gerar expectativas complicadas no cliente, você reduz o trabalho sobre detalhes, aumenta sua produtividade, a qualidade da produção e, de quebra, sua competitividade.
Muitas vezes somos tão aficcionados pela perfeição, que esquecemos o que realmente importa no negócio: a satisfação dos usuários. Usuários comuns não abrem um site, e depois abrem ele novamente em outro navegador só para conferir como ficou o layout, nem redimensionam a janela compulsivamente afim de achar um elemento quebrado. Usuários comuns leem o que querem ler, falam o que querem falar, compram o que querem comprar, fazem o que querem fazer. Se o site lhes dá os meios suficientes para eles completarem suas tarefas, ótimo, isso lhes basta. Quanto mais simples e direto for o processo que leva o usuário atingir seus objetivos, melhor. Nenhuma borda arredondada, ou fonte, ou efeito visual é tão importante ao julgamente quanto a facilidade de uso.
Bem, é isso. Chega da busca da perfeição milimétrica a qualquer preço, e mais respeito às normas e aos usuários.
----------- keepReading
Um dos pontos mais problemáticos no desenvolvimento de um site, ao lado da acessibilidade, é o layout. Em especial fazer com que o site tenha exatamente a mesma aparência em todos os navegadores, em todas as plataformas e em todas as resoluções de tela.
Para esta tarefa, esta meta, não preciso dizer que além de muito trabalho, limita o desenvolvedor nos recursos que podem ser utilizados e na infinidade de hacks necessários. Este ideal é praticamente utópico e conflita diretamente com dois interesses: o do desenvolvedor de realizar um trabalho de qualidade (criar uma solução efetiva, padronizada, acessível) e com o do cliente, porque influi diretamente em prazos e custos.
Pois bem, em primeiro lugar, se você ainda cria algo no Photoshop ou qualquer outro software de processamento de imagem, fornecendo uma foto do trabalho que será realizado ao cliente, pare agora. Quando você fornece uma foto, uma imagem, você cria expectativas no cliente, e mais tarde quem vai ralar para conseguir atingir esta expectativa a qualquer custo é você mesmo.
Para o processo de aprovação do layout, use um site. Crie um site, sem efeitos, sem interatividade, e esclareça isso ao cliente. Diga que fará um site, sem programação ou interatividade porque isto demandam trabalho, e que não é a versão final, é apenas para avaliação estética, do layout.
A partir de então, faça a marcação em HTML bem feita, e trabalhe o CSS. Pronto. Se você fizer, utilizando o Firefox ou o Chrome, e o cliente ver no Firefox, ótimo. Se ele ver no Internet Explorer, mas mesmo assim aprovar, não tem porque você gastar horas polindo alguns detalhes mínimos.
Trabalhando desta forma, sem gerar expectativas complicadas no cliente, você reduz o trabalho sobre detalhes, aumenta sua produtividade, a qualidade da produção e, de quebra, sua competitividade.
Muitas vezes somos tão aficcionados pela perfeição, que esquecemos o que realmente importa no negócio: a satisfação dos usuários. Usuários comuns não abrem um site, e depois abrem ele novamente em outro navegador só para conferir como ficou o layout, nem redimensionam a janela compulsivamente afim de achar um elemento quebrado. Usuários comuns leem o que querem ler, falam o que querem falar, compram o que querem comprar, fazem o que querem fazer. Se o site lhes dá os meios suficientes para eles completarem suas tarefas, ótimo, isso lhes basta. Quanto mais simples e direto for o processo que leva o usuário atingir seus objetivos, melhor. Nenhuma borda arredondada, ou fonte, ou efeito visual é tão importante ao julgamente quanto a facilidade de uso.
Bem, é isso. Chega da busca da perfeição milimétrica a qualquer preço, e mais respeito às normas e aos usuários.
----------- keepReading
quinta-feira, 2 de setembro de 2010
Evolução dos navegadores... de novo
No começo de 2008 ouvi o burburinho sobre o navegador do Google, o Chrome. Baixei para experimentar. Minha primeira impressão foi: é a mistura do Opera com o Firefox. Visual clean, alguns recursos de customização, mas fora o rápido engine de javascript, o resto era MUITO imaturo ainda. Faltavam muitos recursos para poder ser considerado um browser do mainstream, mas sendo do google, isso era apenas uma questão de tempo. Abandonei ele até agora. Testei a poucos dias a versão 5 do Chrome. Muito melhor. Mas créditos não só ao google, mas também ao pessoal do Webkit.
Esse mercado de browser eu acompanho, ainda que não tão de perto, bastante, assim como os padrões da web. E isso me surpreende bastante. Tanto pela inovação das partes, quanto pela velocidade das mudanças.
Abertamente, Opera, Firefox, Safari e Chrome trazem a cada release novidades interessantes. O Opera com o layout clean e recursos embutidos, o Safari com o anti-aliasing das fontes, o Firefox e o Chrome dispensam maiores apresentações. Uma mudança que me chamou muito a atenção foi o Opera e o Webkit (Chrome e Safari) embutirem ferramentas para desenvolvedores, no melhor estilo Firebug. Certamente eles focaram o mercado de quem leva a web a sério. Gostei.
Mas o que mais me chama a atenção é a velocidade das releases (e a adoção dos novos padrões, HTML 5, CSS 3, novas APIs de Javascript). De 2008 pra cá, o Opera saiu da versão 8 para a versão 10. O Chrome, saiu da versão 1 para a versão 5, o Firefox, da 2.5 para a 3.6. Todos eles implementam atualizações menores com uma frequencia praticamente mensal, e pelo menos duas atualizações significativas por ano.
Já o nosso amigo Internet Explorer está tentando dar adeus à versão 6, que já existe há 10 anos (e conta com o "apoio" do Google que declarou o fim do suporte para a problemática e custosa versão do IE.). A versão 7 e a versão 8 dividem o mercado, e estão bem atrás da concorrência em termos de inovações tecnológicas. O IE domina o mercado, mas já sente a pressão, principalmente porque quem usa mais do que orkut e MSN na internet, tende a procurar um navegador com mais recursos. Isso mostra que esse público, que é economicamente interessante, já percebe a falta de qualidade e de opções das versões atuais do internet explorer, e a falta de atualizações por parte da MS para o IE é um problema, que a Microsoft vem trabalhando sério, mas ainda falta o ritmo dos concorrentes.
Para ser sincero, gostei de todas as iniciativas de todas as partes. Na busca de trazer resultados para os grupos que realmente importam no fim das contas: os usuários e os desenvolvedores. E o fiel da balança, o Internet Explorer, já mostra sinais de que tende a rumar para o mesmo caminho, lentamente como sempre, mas já tomou um norte e em questão de 4 ou 5 anos, creio que o cenário estará ainda melhor.
----------- keepReading
Esse mercado de browser eu acompanho, ainda que não tão de perto, bastante, assim como os padrões da web. E isso me surpreende bastante. Tanto pela inovação das partes, quanto pela velocidade das mudanças.
Abertamente, Opera, Firefox, Safari e Chrome trazem a cada release novidades interessantes. O Opera com o layout clean e recursos embutidos, o Safari com o anti-aliasing das fontes, o Firefox e o Chrome dispensam maiores apresentações. Uma mudança que me chamou muito a atenção foi o Opera e o Webkit (Chrome e Safari) embutirem ferramentas para desenvolvedores, no melhor estilo Firebug. Certamente eles focaram o mercado de quem leva a web a sério. Gostei.
Mas o que mais me chama a atenção é a velocidade das releases (e a adoção dos novos padrões, HTML 5, CSS 3, novas APIs de Javascript). De 2008 pra cá, o Opera saiu da versão 8 para a versão 10. O Chrome, saiu da versão 1 para a versão 5, o Firefox, da 2.5 para a 3.6. Todos eles implementam atualizações menores com uma frequencia praticamente mensal, e pelo menos duas atualizações significativas por ano.
Já o nosso amigo Internet Explorer está tentando dar adeus à versão 6, que já existe há 10 anos (e conta com o "apoio" do Google que declarou o fim do suporte para a problemática e custosa versão do IE.). A versão 7 e a versão 8 dividem o mercado, e estão bem atrás da concorrência em termos de inovações tecnológicas. O IE domina o mercado, mas já sente a pressão, principalmente porque quem usa mais do que orkut e MSN na internet, tende a procurar um navegador com mais recursos. Isso mostra que esse público, que é economicamente interessante, já percebe a falta de qualidade e de opções das versões atuais do internet explorer, e a falta de atualizações por parte da MS para o IE é um problema, que a Microsoft vem trabalhando sério, mas ainda falta o ritmo dos concorrentes.
Para ser sincero, gostei de todas as iniciativas de todas as partes. Na busca de trazer resultados para os grupos que realmente importam no fim das contas: os usuários e os desenvolvedores. E o fiel da balança, o Internet Explorer, já mostra sinais de que tende a rumar para o mesmo caminho, lentamente como sempre, mas já tomou um norte e em questão de 4 ou 5 anos, creio que o cenário estará ainda melhor.
----------- keepReading
Assinar:
Postagens (Atom)