Feito isso, o CSS para o estado :hover e/ou :active irão magicamente aparecer em seu console.

Esse recurso é bastente útil, especialmente se você for debugar CSS complexos de menu drop-down e outros efeitos. Atualmente o Firebug é o único console de desenvolvimento que dá suporte ao recurso. Eventualmente ele apareceça também no Chrome e Safari.

Tem alguma outra dica útil para compartilhar?

Para iniciar a sequencia dos tutoriais, resolvi falar sobre listas de ordenação e explicar um pouco mais sobre o uso e cada uma e o porque isso é importante na hora de se desenvolver um site dentro dos padrões w3c.

Listas desordenadas: <ul>

As listas desordenadas são, comumente, as mais utilizadas por todos nós desenvolvedores quando resolvemos criar menus. E porque utilizamos as <ul> na criação de menus? Simples! Porque, semânticamente, os menus são itens correspondentes a uma lista sem ordenação não se encaixando em qualquer outra tag, semânticamente, a não ser a <ul>.

Listas ordenadas: <ol>

Idêntica as <ul>, porém nela temos a obrigação de ordernarmos os itens, seja eles por ordem alfabética, numérica, crescente ou decrescente. Devemos utilizá-las quando queremos criar, por exemplo, um passo-a-passo, uma receita ou até mesmo uma lista de categorias do seu blog.

Listas de definição: <dl>

As listas de definição são as menos utilizadas e pouco entendidas por muitos. Uma maneira bastante fácil e simples para o entendimento da <dl> é pensarmos em um glossário. Todo glossário possui termos e, cada termos, suas descrições. Para os termos utilizamos <dt> e para as descrições <dd>. Uma coisa muito importante na <dl> é que: nunca termos, em hipótese alguma, um termo repetido com descrições diferentes. Cada termo tem sua descrição única, caso contrário o mesmo não poderá ser um <dl>, e sim uma <ul> ou uma <ol>.

Em tempo, basta sabermos o nome de cada tag para qu possamos entender o seu uso. Consegui ser claro na explicação?

Tá certo que o público não é tão específico quanto de um hotsite ou campanha, mas acredito ser muito mais específico e selecionado do que muitos possam imaginar. Por exemplo, é um público que compra na internet, que usa cartão de crédito, que viaja a turismo ou trabalho constantemente. Logo não é um público de pouca renda ou com baixo nível de conhecimento de internet, acredito eu apesar de alguns estudos e dados não confirmarem tanto.

Constantemente debato com meus colegas se nosso público é básico, se temos usuários com idades superiores a 60 anos (logo com dificuldade de leitura e coordenação montora – salvo raras excessões), se temos usuários com dificuldade de visão e por não ter uma resposta concreta ou a maioria deles achar que sim, acabo me frustando ao desenhar nossas interfaces.

Não acredito que isso seja verdade. Acredito que o nosso público seja de usuários médios pra avançados, que já tenham uma experiência de compra online e que não tenham mais medos e dúvidas sobre tal experiência. Assim como ter que manter um site/projeto pra IE6 e 1024×768 de resolução de tela. Se a pessoa não possui um computador atualizado, vai ter dinheiro pra gastar comprando online? Comprando objetos, livros, passagens aéreas, fazendo transações bancárias e etc, duvido.

Estudos dizem que brasileiros gastam boa parte do tempo pra fazer transações, compras e usar redes sociais durante o dia e no horário de trabalho. Se o cara trabalha numa empresa que mantém os computadores desatualizados, essa mesma empresa deve vetar o uso de alguns sites no horário do expediente, logo, essas pessoas devem realizar essas transações no conforto do lar no seu laptop, smartphone (alguns em suas tablets) ou desktop. É raro hoje em dia encontrar computadores a venda com monitores menor que 17″ e com isso resoluções menores que 1024×768 vão ficando cada vez menos comuns.

Claro que não posso ignorar os novos usuários que estão chegando, a famosa inclusão digital (como eu odeio esse termo). Esses novos usuários que ainda estão aprendendo a usar as coisas, aprendendo a comprar e que tem um poder de compra alto. Ou seja, não dá mesmo pra tirá-los da base. Porém a cada ano a curva de aprendizado ao uso de novas interfaces e mídias é mais curta e rápida, logo, não é motivo. E esses novos usuários já compram computadores melhores, do que disse no parágrafo anterior, graças as facilidades de carnês e cartões de crédito.

Outro grande problema que encontro é a famosa quebra de paradigmas. Pessoas que trabalham com internet, porém, são conservadoras demais e acabam não se atualizando com a mesma velocidade e frequência da rede (Brasil só levou um cyber, prata, em Cannes por exemplo). E não me venham falar de verba, porque o brasileiro é reconhecido mundialmente como um po(l?)vo criativo que dá nó em pingo d’água.

Não me falem que não tem tempo ou a equipe não pode ser parada para melhorar um projeto ou começar um novo do zero. Medinho é uma coisa que me deixa puto. Se você tem uma equipe de 1 front, 1 developer e 1 designer, realmente você não pode fazer muita coisa num projeto que já está todo errado. Mas se você pode dividir a equipe em duas, uma (re)constrói de forma certa o que está errado e a outra fica mantendo (por hora) o que está no ar, qual problema disso sr. 06? Quer passar o comando pra quem tenha colhão suficiente? Então passa.

Se grandes empresas seguem investindo em novas ideias, novas interfaces, empresas que tem um público variado e milhões de acessos por mês, tentam e fazem a coisa funcionar, por que você que tem alguns milhares e um público semelhante também não pode?

Brasileiro é assim mesmo, preguiçoso e com uma zona de conforto grande. Segundo minha grande amiga Ana Erthal: “O problema todo é que as agências ainda pensam, em pleno século XXI e no meio dessa turbulência de informações e mobilidade social e cultural, como se pensava há 40 anos. Elas pensam como veículos de massa. E não é mais assim. A comunicação se fragmentou juntamente com a identidade dos sujeitos e da cultura… e não tem mais volta. Desde a invenção do controle remoto a comunicação se tornou individualizada e promíscua na ultilização de meios e ferramentas. E as agências, em vez de perceberem esse movimento natural evolutivo, elas continuam olhando para trás, usando modelos ultrapassadíssimos para tentar entender o sujeito contemporâneo e sua pluralidade. É triste. E é esse o motivo que não as deixa caminhar pra frente: daqui não sairá nenhum cyber”. Aí se você vem com ideias e ideais que batem de frente e que forçem as pessoas a pensar e a inovar, você é de outro planeta ou tá tentando pensar muito na frente dando um passo maior que a perna e não vai alcançar a outra margem do rio.

Já ouvi pessoas dizendo que ainda não acreditam em mobile apps mesmo depois do sucesso astrnômico do iPhone e Android, mesmo com tudo se convergindo e mostrando o contrário. E não foi estagiário que falou isso não hein. No twitter mesmo, canso de ver pessoas que se dizem responsáveis por mídias sociais ou que tenham foco nelas, postarem coisas com 1 semana, 1 mês e as vezes mais tempo de atraso achando que é novidade com a desculpa que estava muito ocupado com o job do cliente e nāo teve tempo de ler ou ver o que aconteceu na semana.

Me desculpe, mas esse job desse cliente aí vai ser antigo quando ele for lançado então viu, capitão?

Felizmente em alguns casos não é assim, mas vejo muitos projetos, agências, empresas que ficam pensando muito no hoje e no ontem e não no amanhã.

É por isso que tem tanta gente boa saindo do país pra “fazer internet” lá fora. Agências dos EUA e da Europa estão anos luz a frente das tupiniquins em termos de planejamento, estrutura e principalmente condições de trabalho. Se você dá liberdade pro seu profissional criar, seja ele de criação ou não – porque boas ideias vem de qualquer um e de qualquer lugar – tenho certeza que os projetos vão ficar cada vez melhores.

Um exemplo disso são os hackdays e hackathons da vida como fazem o Facebook, o Google e o Linkedin. Boas, não, excelentes ideias surgiram desses exemplos: Orkut, Gmail, GoogleDocs no Google, vídeo, like, face tag no Facebook, exportar seu currículo, grupos no Linkedin. Os profissionais são incentivados a estar sempre buscando novas soluções por puro prazer e não porque é o trabalho deles.

É aí que está toda a diferença cultural da coisa.

post by Daniel de Paola

Como muitos sabem, principalmente os desenvolvedores, essas diferenças de valores atrapalham no desenvolvimento e por isso temos que zerá-los antes de qualquer coisa para que podemos ter certeza, não tanta assim, de que estamos trabalhando fora desses valores default dos browsers.

Procurando no google você irá encontrar diversas formas de aplicação do CSS Reset, umas mais implementadas e outras bastante simples que, particularmentes, é a que gosto de usar. Dentre todas essas soluções, temos as mais conhecidas como a do Eric Meyer, Tantek Celik, sugestões de empresas como a do Yahoo! ou a mais simples possível.

* {margin:0;padding:0;height:100%;list-style:none}

PS: A forma de escrita do CSS vai de cada um. Eu, por exemplo, consigo ler melho o CSS em linha, como feito acima, do que escrevendo cada propriedade em cada linha.

O script é bem simples e fácil de entender, porém temos que definir qual o tamanho padrão que iremos ter em nosso site.

Na maioria dos browsers – se não todos – utilizando 16px como tamanho de fonte padrão, podendo ser alterado pelo usuário caso prefira. Vamos trabalhar com o valor padrão, sem alteração.

Primeiro, iremos definir o tamanho padrão de fonte para o noso site. Optei por 0.69em (11px)

var tam = 69; //número inteiro e tamanho relativo "em"

Criaremos a função chamada mudaFonte recebendo o parâmetro obj. O parâmetro será utilizado para sabermos se foi clicado no a+ ou no a-

function mudaFontes(obj) {
//conteudo do script
}

Iremos utilizar switch como nossa condição. Se for “+”, aumentaremos o tamanho e se for “-”, diminuiremos. Assim…

switch (obj) {
  case '+':
    tam = tam + 9;
    break;
  case '-':
    tam = tam - 9;
    break;
}

Por fim, ajustaremos o valor padrão de nossa div principal – ctPrincipal ou o nome que escolheu colocar em sua div – com o valor final que obteremos no script, dividiremos por 100 e adicionaremos “em” para indicar um valor relativo.

document.getElementById('ctPrincipal').style.fontSize = (tam / 100) + 'em';

Finalizando, nosso sript ficaria assim:

var tam = 69;
function mudaFonte(obj) {
  switch (obj) {
    case '+':
      tam = tam + 9;
      break;
    case '-':
      tam = tam - 9;
      break;
  }
  document.getElementById('ctPrincipal').style.fontSize = (tam / 100) + 'em';
}

Para ativar a função basta utilizar onclick=”mudaFonte(‘+’)” – para aumentar – e onclick=”mudaFonte(‘+’)” – para diminuir. Outras versões ou dicas são bem vindas nos comentários

Quando criamos um formulário temos que ficar atentos a, no mínimo, três tags fundamentais para a marcação correta do form, são elas: <form>, <label> e a nossa famosa <input>.

• <form> – indicará o início e fim do nosso formulário;
• <label> – irá conter todo o respectivo texto de cada campo do formulário;
• <input> – nosso formulário em si (campo texto, radio buttons etc).

<form action="/">
  <p>
    <label for="txtNome">Nome</label>
    <input type="text" id="txtNome" />
  </p>
  <p>
    <label for="txtEmail">Nome</label>
    <input type="text" id="txtEmail" />
  </p>
  <p>
    <input type="submit" value="Enviar" />
  </p>
</form>

Reparem que, para cada <label>, temos um for e, para cada <input>, temos uma id, ambas com o mesmo valor. Cada “id” representa uma identificação para cada campo do formulário enquanto cada “for” representa uma ligação do label com o campo.

Pronto! Já temos todas as ligações feitas, agora é só clicar no texto para que, automaticamente, o campo texto seja selecionado. O mesmo acontece com os demais objetos de um formulário (radio button, checkboxes etc).

Para que um formulário seja realmente acessível, precisamos estar cientes da existência de algumas tags básicas e para que elas servem. Vamos a elas:

• form: cria uma área para a entrada de dados podendo conter campos de texto, checkboxes, radio-buttons etc.
• fieldset: utilizado para agrupar elementos no formulário. ex: dados pessoais, dados profissionais etc.
• legend: define um nome para cada fieldset criado
• label: define um “label” para um determinado controle.
• input, checkbox e radiobutton: elementos de um form.

Conhecida as principais tags, vamos a criação do formulário. Primeiro criaremos a área válida do form:

<form action="/">
    aqui iremos montar nosso form
</form>

Dentro da área criada pela tag <form>, iremos dividir as informações em Dados Pessoais e Dados Profissionais utilizando as tags <fieldset> e <legend> para então adicionarmos os campos a serems preenchidos:

<fieldset>
    <legend>Dados Pessoais</legend>
    <p><label for="txtNome">Nome <input type="text" id="txtNome" value="" /></label></p>
    <p><label for="txtEmail">Email <input type="text" id="txtEmail" value="" /></label></p>
</fieldset>
<fieldset>
    <legend>Dados Pessoais</legend>
    <p><label for="txtNome">Nome <input type="text" id="txtNome" value="" /></label></p>
    <p><label for="txtEmail">Email <input type="text" id="txtEmail" value="" /></label></p>
</fieldset>

Para finalizar, um botão para o envio dessas informações:

<p><input type="submit" value="Enviar" /></p>

Para muitos, ou até para a maioria, usuários internet tudo é abreviação mas na realidade não é a verdade. Acrônimos são palavras formadas por letras ou sílabas iniciais de uma locução – Ex.: CSS = Cascading Style Sheets – enquanto abreviação é uma forma curta da palavra excrita – Ex.: Av. = Avenida.

No xHTML, a utilização da tag abrr se dá na seguinte forma:

<abbr></abbr>

Para cada <abbr> gerado, é altamente recomendável, no meu ponto de vista obrigatório, o uso da propriedade <title> ao qual, com ela, podemos visualizar o significado daquele abreviação ao passarmos o mouse por cima da palavra.

<abbr title="Avenida">Av.</abbr>

Fazendo isso, estaremos ajudando a quem não tem o conhecimento de certas abreviações e faremos nossos sites mais acessíveis e de acordo com os padrões w3c.

[update]
Uma ótima pedida é mudarmos o cursor do mouse, ao passarmos por cima do <abbr>, para o ícone de help (ajuda).

abbr { cursor: help }

Já parou para imaginar o quanto é difícil memorizar urls do tipo americanas.com.br/home/begin.do?home=AcomMat&mat=6056? Difícil né? Não seria mais fácil e objetivo se fosse americanas.com.br/todos-os-departamentos? Fica mais claro sabermos que essa URL é para área de todos os departamentos do site Americanas.com.

Além do critério memorização, uma grande vantagem das URLs amigáveis são com relação aos robôs de busca (google, yahoo, live search etc). Alguns desses diversos robôs deixam até de indexar suas páginas devido ao uso de caracteres em suas URLs como o “?” e o “&” além de, com isso, você estar deixando claro o uso de algumas tecnologias utilizadas em seu site/blog – php, jsp etc – e deixando expostas variáveis GET para seus usuários.

Na parte de administração do WordPress em configurações – links permanentes, você pode – na minha opinião, deve – alterar essas configurações e setá-las para estrutura personalizada ou alguma das opções exceto a primeira /?p=123. Ah, seu site não é em wordpress? Ok, existem outros métodos para que essa alteração possa ser feita. Uma dela é alterando o arquivos .htaccess.

Caso não exista o arquivo .htaccess na raiz de seu site, bata criá-lo – é nele que ficaram as regras de reescritas de seu site. Leia mais sobre .htaccess e como tornar suas URLs amigáveis a partir dele.