Nossa, faz tempo que não escrevo nada por aqui né? Bom, hoje eu fiz um pouquinho de código que fiquei com vontade de compartilhar.

No mundo da web, um(a) slug é a representação de um título ou conteúdo que pode ser adicionado à URL de uma página. Nos últimos tempos, o(a) slug tem recebido maior atenção por ser um ótimo fator na hora de otimizar o seu site para buscadores (SEO), por ele(ela) está sempre presente nos principais CMS’s por aí como, por exemplo, o Wordpress.

Eu estava fazendo um sisteminha simples de e-commerce em CakePHP e precisava criar slugs para as categorias e produtos da loja. Eu já havia escrito um código que fazia isso pra mim, mas estava solto no app_model.php. Eu sabia que já existia um behaviour que fazia exatamente isto. Era o Sluggable Behaviour, escrito pelo Mariano Iglesias, um grande desenvolvedor que trabalha com Cake.

Apesar de ser um behaviour muito bem escrito e flexivel, eu fiquei com vontade de tentar fazer minha própria versão dele. Algumas coisas, com a própria geração do(a) slug poderiam ficar por conta da função Inflector::slug() por exemplo, dentre outras pequenas mudanças que eu gostaria de ver no código. Por isso eu fui lá e tentei fazer meu próprio behaviour. Na verdade, eu usei o código do Mariano como base e fui trabalhando em cima, o que me ajudou muito a entender como behaviours funcionam e devem ser escritos. Se você comparar os códigos, vai ver muitas coisas similares.

Eu não tenho a mínima pretenção de dizer que o que eu fiz é melhor que o original, porque tenho quase certeza que não é, mas é uma solução mais simples e mais leve, então alguma vantagem tem. Se quiser usar, crie um arquivo com o nome “sluggable.php” dentro da pasta /app/models/behaviours e coloque o conteúdo deste link lá.

Exemplo: Digamos que você tem um model chamado “Post”, e nesta tabela você possui um campo chamado “title” e outro “slug”. Para usar o meu Sluggable Behaviour, basta adicionar a seguinte linha no seu /app/modesl/post.php

var $actsAs = array('Sluggable');

Pronto! Isto basta para que, toda vez que você salvar um novo post, um(a) slug seja criada a partir to campo title inserido. Se os campos no seu banco tem outros nomes, fica fácil configurar o behaviour para que ele responda a essas diferenças. Exemplo:

var $actsAs = array('Sluggable' => array(
    'fields'    => 'titulo',
    'slugfield' => 'url'
));

Se você quiser concatenar as informações de mais de um campo para gerar a slug, basta indicar a chave ‘fields’ como uma array, assim:

var $actsAs = array('Sluggable' => array(
    'fields'    => array('titulo', 'codigo'),
    'slugfield' => 'url'
));

Por padrão, se você escrever um título como “Este é meu título” o(a) slug vai ficar assim: este-e-meu-titulo. Se você quiser, pode modificar o separador das palavras:

var $actsAs = array('Sluggable' => array(
    'fields'    => array('titulo', 'codigo'),
    'slugfield' => 'url',
    'separator' => '_'
));

Dentre outras opções, você ainda pode configurar as seguintes chaves:

var $actsAs = array('Sluggable' => array(
    'fields'    => array('titulo', 'codigo'),
    'slugfield' => 'url',
    'separator' => '_',
    'length'    => 256,    //define um tamanho padrão para o(a) slug - o padrão é "256"

    'overwrite' => true,   //se verdadeiro, modifica o(a) slug na hora da edição
                           //caso contrário, mesmo editando, o(a) slug permanecerá
                           //igual ao da adição - o padrão é "false"

    'lower'     => false   //se verdadeiro, transforma todo(a) slug em caixa baixa - o padrão é "true"
));

É isso! Gostaria de deixar claro, mais uma vez, que este behaviour é totalmente inspirado pelo behaviour do Mariano. Mantive o mesmo nome não porque eu ache que o meu possa substituir o dele, mas simplesmente porque eu queria que este fosse o nome do behaviour no meu projeto, deixando o código mais bonito e coerente.

Tenho certeza que pode ter alguns erros e outras coisas podem ser melhoradas, por isso, sinta-se à vontade para sugerir, criticar ou elogiar! Se houver alguma dúvida também, é só comentar! Abraços!

Na verdade, na época a coisa já havia mudado, mas eu não sabia. Foi quando eu encontrei este outro artigo aqui. O artigo ensina como fazer joins em casos específicos utilizando o Model::find().

Vou tentar parafrasear o artigo utilizando a motivação daquele meu artigo anterior.

Então imagine que temos duas tabelas, uma de Posts e outra de Tags e exista uma relação HABTM entre elas. Eu quero encontrar todos os posts com a Tag “design”, como fazer?

Uma vez dentro do controller dos posts eu posso escrever o seguinte código:

Obs.: Este código não foi testado e seu objetivo é apenas o de ilustrar as possibilidades aqui apresentadas.

$posts = $this->Post->find('all', array(
	'joins' => array(
		array(
			'table'      => 'posts_tags',
			'alias'      => 'PostsTag',
			'type'       => 'INNER',
			'conditions' => array('PostsTag.post_id = Post.id')
		),
		array(
			'table'      => 'tags',
			'alias'      => 'Tag',
			'type'       => 'INNER',
			'conditions' => array(
				'Tag.id = PostsTag.tag_id',
				'Tag.tag LIKE' => '%design%'
			)
		)
	)
));

Trazendo um caso da vida real, na Quitanda eu queria mostrar os últimos posts de uma determinada categoria dentro do painel dos usuários com lojas. O nosso blog é feito com Wordpress. Eu teria que criar um arquivo model para a tabela de posts do WP para poder fazer isso, mas fiquei com preguiça já que este seria o único lugar onde isto aconteceria, então ao invés de criar um arquivo de modelo, eu criei ele dentro do próprio controller utilizando a classe ClassRegistry e a função init.

Como minha tabela do Wordpress era diferente da utilizada pela aplicação, primeiro eu defini um novo vetor de configurações no meu arquivo config/database.php. Veja:

var $wp = array(
	'driver'     => 'mysql',
	'persistent' => false,
	'host'       => 'localhost',
	'login'      => 'root',
	'password'   => 'max7max7',
	'database'   => 'qolwp',
	'encoding'   => 'utf8'
);

Depois, já no meu controller, escrevi a seguinte linha:

$this->WpPost = ClassRegistry::init(array(
	'ds'    => 'wp',
	'table' => 'wp_posts',
	'class' => 'model',
	'alias' => 'WpPost'
));

Os parâmetros praticamente se auto explicam mas, a chave ‘ds’ guarda a variável de configuração do banco que vai ser utilizada, no caso ‘wp’, como definido anteriormente. Depois dizemos qual é a tabela a ser utilizada, o tipo de classe a ser registrada e o ‘alias’ para ser utilizado nas consultas.

Depois eu fiz a consulta. Ela ficou meio extensa e é claro que escrevendo isto direto no SQL seria muito mais simples, mas fica aqui a titulo de exemplo. Eu fiz isso mais para experimentar as possibilidades e ver o que acontecia. Olha só:

$posts = $this->WpPost->find('all', array(
        'joins' => array(
                array(
                        'table'      => 'wp_term_relationships',
                        'alias'      => 'WpTermRelationship',
                        'type'       => 'INNER',
                        'conditions' => array('WpPost.ID = WpTermRelationship.object_id')
                ),
                array(
                        'table'      => 'wp_term_taxonomy',
                        'alias'      => 'WpTermTaxonomy',
                        'type'       => 'INNER',
                        'conditions' => array('WpTermRelationship.term_taxonomy_id = WpTermTaxonomy.term_taxonomy_id')
                ),
                array(
                        'table'      => 'wp_terms',
                        'alias'      => 'WpTerm',
                        'type'       => 'INNER',
                        'conditions' => array('WpTermTaxonomy.term_id = WpTerm.term_id')
                )
        ),
        'conditions' => array(
                'WpPost.post_type'        => 'post',
                'WpPost.post_status'      => 'publish',
                'WpTermTaxonomy.taxonomy' => 'category',
                'WpTerm.slug'             => 'painel'
        ),
        'fields' => array(
                'WpPost.post_title',
                'WpPost.post_content',
                'WpPost.guid',
                'WpPost.post_date'
        ),
        'group' => 'WpPost.ID',
        'order' => 'WpPost.post_date DESC',
        'limit' => 5
));

O SQL que esta função vai criar fica assim:

SELECT `WpPost`.`post_title`, `WpPost`.`post_content`, `WpPost`.`guid`, `WpPost`.`post_date` FROM `wp_posts` AS `WpPost` INNER JOIN wp_term_relationships AS `WpTermRelationship` ON (`WpPost`.`ID` = `WpTermRelationship`.`object_id`) INNER JOIN wp_term_taxonomy AS `WpTermTaxonomy` ON (`WpTermRelationship`.`term_taxonomy_id` = `WpTermTaxonomy`.`term_taxonomy_id`) INNER JOIN wp_terms AS `WpTerm` ON (`WpTermTaxonomy`.`term_id` = `WpTerm`.`term_id`) WHERE `WpPost`.`post_type` = 'post' AND `WpPost`.`post_status` = 'publish' AND `WpTermTaxonomy`.`taxonomy` = 'category' AND `WpTerm`.`slug` = 'painel' GROUP BY `WpPost`.`ID` ORDER BY `WpPost`.`post_date` DESC LIMIT 5

Com isto você já pode ver que existem muitas possibilidades. Por exemplo, você pode fazer consultas com LEFT JOIN ao invés de INNER JOIN simplesmente trocando a chave ‘type’. Veja também que nas condições gerais da minha consulta eu pude colocar filtros diretamente relacionados às tabelas que eu dei join. No artigo original existe uma chave ‘foreignKey’ com valor false, mas analisando a API, não achei nenhuma referência a este valor em nenhum dos adaptadores de bancos de dados, então me parece ser algo totalmente dispensavel e a função funciona sem que ela seja declarada.

Acho que é isso. Duvidas, sugestões e agradecimentos são sempre bem vindos! Até a próxima!

Para fazer a coisa funcionar, basta extrair os arquivos do .zip numa pasta qualquer (eu coloquei em C:\sendmail\) e editar o arquivo “sendmail.ini” nas seguintes linhas:

default_domain=domain.com

auth_username=webmaster@domain.com
auth_password=password

force_sender=webmaster@domain.com

Pronto, modifique as áreas em negrito para corresponder às suas configurações e depois é só configurar o PHP para utilizar o novo servidorzinho. Abra o arquivo php.ini (o local deste arquivo varia muito de instalação p/ instalação… você deve saber onde o seu está) e procure as seguintes linhas:

; For Unix only. You may supply arguments as well (default: "sendmail -t -i").
; sendmail_path

Modifique para que fique assim:

; For Unix only. You may supply arguments as well (default: "sendmail -t -i").
sendmail_path = C:\sendmail\sendmail.exe -f

Reinicie o servidor e teste! O post original é bem mais esclarecedor e, se algo der errado, dê uma olhada nas dicas que o cara coloca por lá. Espero que ajude! Abraços!

A Quitanda pretende ser um site onde qualquer pessoa possa criar uma pequena loja virtual com tudo o que é necessário para realizar transações pela internet, com controle de estoque, imagens, lista de clientes e tudo mais. Cada lojista é independente e tem seu próprio cantinho, podendo personalizar sua loja e tudo mais. E adivinha. O SofaNews já está por lá

Eu estou muito feliz e espero que este projeto possa render muitos frutos. No mínimo, tem sido muito legal e proveitoso trabalhar neste projeto. Um grande aprendizado!

Na parte técnica, estamos rodando o site na SliceHost num slice de 256Mb de RAM, 10Gb de espaço e 100Gb de banda (espero que esta configuração precise ser mudada em breve). O servidor que escolhemos foi o lighttpd rodando php em fast-cgi. Estamos trabalhando o cache com APC por enquanto, e tem sido muito bom! Também estamos utilizando o Amazon S3 para guardar as imagens, o que reduz bastante o impacto no nosso servidor.

[edit]
Em tempo, o Edu Duccigne escreveu um post super legal sobre a gente no blog dele! Veja aqui!
[/edit]

Eu queria agradecer muito à minha namorada que sempre acreditou em mim e neste meu sonho. Ela é maluca de ficar comigo nesse pensamento louco. Sem ela, acho que não conseguiria! Também queria agradecer a Natália que comprou a idéia e mergulhou de cabeça junto comigo nessa empreitada! Seu toque feminino é muito importante neste projeto! Também queria agradecer ao meu pai, à minha mãe, que sempre me estimularam a seguir os meus sonhos sem desistir e me ensinaram que sem trabalho não se vai a lugar algum. Queria agradecer muito ao Rafa pelo nome genial que ele escolheu pra gente E por fim, mas não menos importante, meus agradecimentos ao Gustaf, papy Helmuth e mamy Shirley, por todo o apoio!

E agora vamo que vamo

Agora a classe está mais enxuta e desta vez ela foi feita apenas para PHP 5. Esqueça a classe antiga porque esta agora está muito melhor.

Uma coisa bacana que eu coloquei é que agora ela retorna o próprio objeto quando as funções são chamadas, então você pode chamar diversas funções uma atras da outra como é possível, por exemplo, no jQuery. Olha um exemplo:

$image = new EasyGD();
$image->startFromFile('image.jpg')->crop(100, 50)->save();

Enfim, foram diversas melhorias mas eu ainda estou trabalhando bastante nela, por isso não foi liberado nenhum download dela ainda mas você pode baixar a fonte aqui ou aqui. Você também pode acompanhar o respositório.

Ainda preciso melhorar a forma como eu lido com erros, por isso, qualquer sugestão e colaboração é muuuito bem vinda Se você quiser participar do projeto, entre em contato comigo!

E quem pode dizer o contrário? Os exemplos de Ron são bem categóricos e quase nos convencem de que tabela é o melhor caminho para se criar um layout. Muitas pessoas vieram apontar o site CSS Zen Garden como exemplo máximo de que CSS é a resposta para layouts, mas Ron teve um bom argumento para rebater: Fica fácil criar layouts para sites onde o conteúdo é fixo e você não tem que se preocupar com o que pode acontecer se as coisas saírem de controle. Tables win again.

Ron também diz que, assim como o significado das palavras pode mudar pelo uso, o significado das tags também muda, de forma que, por mais que a tag "table" deva ser usada para dados tabulares, seu uso extensivo em layouts mudou seu significado. Faz sentido, mas pra mim existe um problema aí. Nós nunca poderemos tirar vantagem dos padrões se eles não forem seguidos. Se as pessoas começarem a colocar parágrafos dentro da tag "address", criar um motor de busca de endereços será muito mais difícil. O Google faz uso extensivo da catalogação de termos através da utilização de tags "dd", "dt" e "dl" (é só usar o "define: css" para ver isto em ação), ou seja, não é legal usar esses elementos para criar formulários mais bonitos, eles servem para definições! O fato é que as coisas vão ficar mais fáceis se não utilizarmos padrões, e usar CSS é uma forma de manter estes padrões disponíveis.

Agora, existe o outro lado da história. Os fãs mais aficionados de CSS devem prestar atenção porque nem sempre tudo numa marcação é estritamente semântico. No próprio CSS Zen Garden existem algumas tags extras e vazias para propósitos puramente visuais. Qual o significado delas? Se é puramente visual, estamos deturpando a tag div assim como a tag table é deturpada. Aliás, a tag "span", de acordo com a w3school serve apenas para modificações visuais, e então temos coisas como “<h1><span>Meu header</span></h1>”, o que não é exatamente semântico, mas é necessário que eu quiser fazer um "image replacement" no meu header.

Ah! Mas existe uma nova técnica ótima de image replacement onde eu não preciso da tag "span". Basta definir o "text-indent" do elemento para algo como "-9999px" no seu CSS e pronto! Todos sabem que esta é uma gambiarra, assim como é o uso de tabelas! Afinal, desde quando "text-indent" foi feito para sumir com um texto? Este não é o "propósito semântico" da propriedade. Poderia existir uma nova propriedade chamada "text-visibility" que seria semanticamente correta neste caso.

Eu acredito que sempre iremos esbarrar em algum problema semântico, querendo ou não. Mas não podemos ser extremistas, nem de um lado, nem do outro. O que devemos fazer é trabalhar para que a web seja um lugar melhor. Que a indexação de conteúdo seja feita corretamente. Que organizar e encontrar aquilo que se procura seja simples. E embora o CSS tenha suas limitações, elas servem para nos ensinar que a web é uma plataforma diferente da mídia impressa ou da televisão e deve possuir sua própria linguagem visual e forma de organização. Como já dizia McLuhan "o meio é a mensagem".

No Slicehost, o pessoal te dá acesso a uma máquina totalmente limpa, apenas com o sistema operacional, onde você tem que instalar e configurar tudo via SSH. Eu não sou nenhum expert em Linux, muito pelo contrário, estou aprendendo agora, mas para treinar, resolvi fazer alguns experimentos no meu Ubuntu virtualizado aqui comVirtualBox.

Até hoje, minha experiência com servidores se limitou à utilização do Apache (e no windows), mas o Felix do Debuggable me mostrou algumas coisas realmente interessantes no Lighttpd (também conhecido como Lighty), um servidor que diz ser muito levinho e simples de utilizar. Como eu vou ter uma quota limitada de memória no VPS, quanto mais eu puder economizar nisto, melhor, por isso comecei a considerar a utilização real do Lighty. Instalá-lo no Ubuntu foi muito fácil, via apt-get e, pela primeira vez, instalei o PHP direto da fonte, selecionando todas as opções que queria e etc. Foi muito divertido!

Não vou falar aqui sobre a instalação destes carinhas, nem da configuração, porque isso você pode aprender em outros lugares muito melhores do que aqui.

O fato é que eu consegui instalar e configurar tudo direitinho pra rodar o Lighty processando PHP com FastCGI e etc e tal. Em comparação com a instalação do Apache e tudo mais, achei a configuração do Lighty muito mais simples. Em questão de minutos tudo já estava funcionando da forma que devia sem maiores problemas. A minha duvida era, será que oLighty executa bem meus aplicativos escritos com CakePHP? Inicialmente, se o PHP está sendo executado, não deveria existir nenhum impedimento, mas existe uma característica do Cake que recai sobre o servidor, que é a construção das URL’s com o mod_rewrite. O Lighty possui um mod_rewrite, mas em comparação com o Apache, ele é muito inferior.

Pesquisando um pouco mais no grupo de discussão do Cake, descobri que é possível emular o mod_rewrite do Apache de forma específica para o Cake. A primeira coisa que você tem que fazer é habilitar o mod_magnet na configuração do seu Lighty (geralmente fica em /etc/lighttpd/lighttpd.conf), deixe a configuração de lado um pouquinho e salve (geralmente com o nome de “cleanurl-v6.lua”) em algum lugar o seguinte script: http://bin.cakephp.org/view/1811010000. Este é um script feito em Lua e o mod_magnet faz exatamente isso, utiliza scripts escritos em Lua para modificar ou adicionar comportamentos ao seu servidor, bacana não? Bom, depois que você fez isso, fica fácil. Basta voltar ao seu arquivo de configuração e adicionar a seguinte linha:

magnet.attract-physical-path-to = ( "%s" )

Substitua o “%s” pelo caminho onde você salvou o script lua para realizar a substituição e pronto! Testando inicialmente, tudo funcionou muito bem e fiquei super feliz, mas o designUp utiliza “query strings” em algumas URL’s, precisando interpretar coisas como “designup.pro.br/controller/action/?variavel=parametro”. Quando testei este cenário, o script falhou! Ele só conseguia interpretar algo se eu adicionasse mais de uma variável, tipo “designup.pro.br/controller/action/?variavel=parametro&outra=coisa”. Lendo o script entendi que o problema estava na interpretação do caracter “?”, então fiz uma pequena modificação para que tudo ocorresse corretamente. No link acima a modificação já está feita, mas é importante lembrar que este script não é de minha autoria! Se eu descobrir quem foi o autor dele, coloco os devidos créditos aqui.

É isso. Qualquer duvida, se eu puder responder, é só comentar aí! Um abraço!

Bom, queria compartilhar com vocês algumas das minhas idéias e objetivos pra 2009:

• Blogar mais – Não só aqui, mas no blog do designUp, no Pensamentos Cativos e, quem sabe, recomeçar o Web Junky!
• Estabelecer o sono polifásico – Por causa de algumas alergias, não tenho conseguido continuar com o experimento do sono polifásico. Vou fazer uns exames, tomar as devidas providências e voltar ao experimento!
• Aprender Python e ActionScript – Aí estão as duas linguagens que eu vivo lendo a respeito mas que nunca desenvolvi nada nem aprendi tão a fundo. Realmente quero aprendere essas linguagens este ano.
• Colocar quatro novos projetos no ar – Já estamos trabalhando nisto! Por enquanto é um só, mas espero colocar até quatro projetos on-line este ano.
• Me dedicar mais à vinda de freelancer – É, apesar de querer colocar todos estes projetos na rede, eu preciso ter um plano backup. Quero me estabelecer melhor como freelancer e ter onde me apoiar caso tudo dê errado. Na melhor das hipóteses, é dinheirinho extra na certa
• Ganhar dinheiro – SIM! Até hoje eu só estava ensaiando. Agora eu quero ganhar dinheiro de verdade, pra casar e tudo mais. Chega de brincadeira!

Espero que realmente consiga atingir estes objetivos. Todos eles são muito importantes para mim! Quero re-fazer este blog, quero dar continuidade aos screencasts (não pensem que eu esqueci). Enfim! 2009 é “o” ano para definir as coisas e tudo isto será fruto de muito, mas muito trabalho, então tá na hora de eu parar de ficar no Twitter e realmente trabalhar um pouco, rsrs…

Para mostrar que não estou de brincadeira, já comecei este ano lançando mais um projetinho Open Source. Se trada do EasyGD, uma classe que criei para manipular imagens (jpg e png) com facilidade. Fiz uma página no Google Code, coloquei tudo lá, bonitinho, inclusive a documentação!

Talvez eu escreva ela toda de novo em português aqui no blog mesmo né? Se você chegar a utilizar, não esqueça de me avisar, ok? Será um prazer saber q tem alguém realmente usando esta classe!

Bom, acho que é isso por hoje! Tentarei postar aqui com mais frequencia (sem trema), por isso aguardem mais posts legais (ou não) por aí! Abraço!

As mensagens de alerta do tema possuiam a seguinte marcação:

<p class="alert"><span class="success"></span><span class="success_text">Success! Your item has successfully been added.</span></p>

Para produzir um resultado como este:

Até aí, visualmente, nada de demais. Mas olhando a marcação, existem algumas tags desnecessárias ali. O que é aquele “span” vazio com a classe “success” e por que o texto está dentro de um outro “span”? Pra responder a estas perguntinhas, basta uma olhadinha rápida nos estilos destes elementos:

p.alert {
	width: 652px;
	height: 39px;
	background: url("images/alert_bg.png") no-repeat;
}

.success {
	width: 24px;
	height: 24px;
	padding: 10px 0px 0px 15px;
	margin: 6px 0px 0px 15px;
	background: url("images/success.png") no-repeat;
	float: left;
}

.success_text {
	margin: 11px 0px 0px 5px;
	float: left;
	color: #73ae0b;
}

O resultado é bonito? Sim! Mas a lambança também é bem bonita! Como você pode ver o ícone que indica sucesso ou erro esta contido dentro do “span” vazio, e possui um float. Já o texto está num outro “span” que possui um outro float para ficar ao lado do ícone! Que bangunça, isso é realmente necessário? Eu creio que não!

Utilizar uma marcação destas é péssima pois não oferece nenhuma flexibilidade. A altura e a largura dos elementos estão definidas e qualquer texto que extrapole estas definições não ficará bem no elemento. Sentindo o cheiro de problema no ar, resolvi tentar consertar esta marcação e os estilos. Veja como ficou o html depois do tapinha:

<p class="alert success">Success! Your item has successfully been added.</p>

Uh! Bem mais simples não? Olha o resultado visual disso:

E como ficou o css? Dá só uma olhada aí:

p.alert {
	-webkit-border-radius: 10px;
	-khtml-border-radius: 10px;
	-moz-border-radius: 10px;
	border-radius: 10px;
	background-color:#EEEEEE;
	padding: 10px 10px 10px 40px;
}

.success {
	background: url('../../img/adm/success.png') no-repeat 8px;
	color: #73ae0b;
}

O que foi feito? Primeiro eu retirei as limitações de tamanho do elemento. Assim eles podem expandir e se reduzir de acordo com o conteúdo do elemento. Depois removi a imagem de background que dava as bordas arredondadas ao elemento. Existem muitas maneiras de se conseguir bordas arredondadas sem imagens no seu layout, mas a maioria é com javascript. A galera do blog Perishable Press criou um artigo recentemente mostrando como é possível conseguir bordas arredondadas apenas com css! E foi isso que eu fiz. Você pode dizer “Ah, mas isso não é suportado em todos os browsers, apenas nos mais recentes”, daí eu te respondo com este link AQUI! O importante é ter consciência das formas que este elemento vai tomar em browsers que não suportam estes comandos ainda.

Coloquei como cor de fundo a cor da imagem e defini alguns paddings. Depois ficou fácil, foi só colocar a imagem de background na classe “success” e posicioná-la a 8 pixels das bordas do elemento, definir uma cor para a fonte e pronto! Não ficou tudo mais lindo e flexivel e sem tags desnecessárias?

Com um pouco mais de raciocínio, a gente consegue fazer coisas muito boas com css, é só experimentar!

O próximo desafio será utilizar a técnica de “sliding doors” para os botões de submit, que também possuem um background fixo! Quando eu fizer isto, posto aqui como foi que fiz

FalaFreela vai ao ar toda segunda-feira (eu acho) e conta com a participação do Mauro Amaral (aqui e aqui) Humberto Oliveira (aqui) e Carol Vigna-Maru (aqui e aqui). Se eu fosse você, assinava o feed e ouvia toda semana