@font-face é uma das funcionalidades mais esperadas do CSS. Ela permite que você utilize famílias de fonts em websites sem que o usuário tenha a font instalada no sistema. Veja abaixo a sintaxe:

1
2
3
4

@font-face {
     font-family: helveticaneue;
     src: url('HelveticaNeueLTStd-UltLt.otf');
}

Na primeira linha você dá um nome para a Font que você está importando. Pode ser qualquer nome.
Na segunda linha, você inclue o endereço de onde a font se encontra. Para facilitar, crie uma pasta font dentro da pasta onde está o CSS.

Feito isso, você a utiliza como qualquer outra font:

1
2
3

p {
	font:36px helveticaneue, Arial, Tahoma, Sans-serif;
}

Fiz alguns testes aqui e em algumas máquinas e conexões lerdas, o browser carrega primeiramente o texto com a font padrão do sistema e logo depois monta o texto com as fonts corretas. Nada de outro mundo para quem utiliza imagens para substituir textos. Mesmo assim, pode ser um incomodo para alguns.

Suponhamos que você queira oferecer a font para os que não a tem disponivel no sistema, mas para que o site carregue mais rápido, queira utilizar a cópia local do sistema do usuário caso ele a tenha instalado:

1
2
3
4

@font-face {
     font-family: helveticaneue;
     src: local(HelveticaNeueLTStd-UltLt.otf), url(HelveticaNeueLTStd-UltLt.otf);
}

O valor local() faz com que o browser procure a font no computador do visitante antes de executar o download da font que está no servidor.

Abaixo segue uma série de formatos que podem ser usados e que os browsers podem adotar:

Compatibilidade

A compatibilidade é melhor do que você pode imaginar. Mesmo assim há alguns entraves que chateiam. Entretando, se você pratica Gracefull Degradation, vai achar uma maravilha.

As versões 7, 8 e 9 do Internet Explorer aceitam o @font-face apenas se a font for EOT.
Safari, Firefox, Chrome e Opera aceitam fonts em TTF e OTF.
Você pode converter suas fonts para EOT diretamente no Font Squirrel.

É sempre bom você não abusar. Uma porque o design não fica bonito se você utilizar muitas fonts diferentes. Outra que o site pode ficar carregado. Lembre-se que o browser carrega o arquivo da font para só assim aplicar no layout.

Veja um exemplo pronto.

Fonts pagas

O principal problema com o @font-face o download de font ilegal. Há uma pancada de fonts que são grátis, estas não há problema. Mas há uma outra grande parte que são pagas. O problema é que você tem a licensa de utilizar essa font nos seus projetos, mas não tem o direito de compartilhá-la ou dar para alguém. Quando você utiliza @font-face, você praticamente disponibiliza para o mundo o arquivo da font. Qualquer um pode fazer o download sem problemas. Por isso, cuidado com a font que você utiliza. Certifique-se de que ela é uma font gratuita.

Leia mais direto da fonte.lan

• Conteúdo, Flash e HTML
• Colocar Rodapé fixo no fim da página
• Ah, o maravilhoso mundo real
• Propriedade do CSS: nth-child
• CSS 3 Columns

Em primeiro lugar, é importante distinguir o ideal daquilo que é possível fazer. Li um bocado sobre RDF e ontologias há uns dez anos. Li “A Revolução Inacabada”, vi o RSS nascer e se tornar popular, vi as primeiras aplicações entenderem o formato. RDF falhou. Dez anos se passaram e continuamos escrevendo HTML para ser lido por navegadores e só. Há poucos exemplos de aplicações semânticas na vida real, e a maioria seria desenvolvida de uma forma ou de outra.

Há muita gente, por exemplo, definindo seu próprio padrão de XML para trocar dados com sistemas parceiros. Quantos desses estão usando RDF, com uma ontologia interpretada automaticamente por sistemas que “descobrem” os serviços um do outro? Ou seja, não há novidades nisso nos últimos dez anos.

Escrever HTML bom é importante, porque vai ajudar o Google a indexar seu site e vai facilitar a vida de quem tentar HTML parsing nele. Mas, seja sincero, você tem mesmo esperanças de que alguém vá lê-lo como XML? Vê alguma vantagem real em validar seu código como XHTML, além de provar a si próprio que fez tudo direito? E onde está a promessa dos microformats? Microformats só fazem diferença se forem usados por muita gente. Ninguém vai fazer um parser de um formato usado em apenas um site. Você consegue citar, de cabeça, cinco sites que usem microformats e não foram feitos por você? Ah, claro, não vale incluir na lista o microformats.org.

Nem RSS é um bom exemplo de aplicação de semântica XML. Existem pelo menos dois formatos populares do padrão, além do padrão Atom, que serve para a mesma coisa. E não sei de nenhum leitor de RSS de sucesso que faça parsing dos feeds como XML. O que todos fazem é ler e interpretar a string. É isso mesmo que você entendeu, quase tão bom quanto um CSV! Outro exemplo digno de nota é o SOAP, que foi criado para fornecer aos webservices a capacidade de “autodescoberta”. Você conhece alguém que use isso de verdade? Já viu algum robô que varre a web em busca de serviços e entende sozinho como usá-los? SOAP só tem a vantagem de oferecer tooltips para ajudar os programadores .Net que usam Visual Studio. Enquanto isso, lá fora, XMLRPC e REST (com JSON) estão mudando o mundo.

Por que essas tecnologias falharam, embora pareçam todas boas idéias? Meu palpite é que elas exigiam um raciocínio de longo prazo, um tipo de aposta, que é muito difícil de conseguir. Embora XHTML, Microformats ou SOAP sejam idéias muito boas, aplicá-las em seu site só vai ter valor se muito mais gente o fizer. Se você aplicar o formato sozinho vai perder seu tempo.

O que é muito diferente de, por exemplo, deixar de usar tabelas para layout, escrever bom HTML ou usar jQuery. Essas coisas lhe devolvem um benefício imediato. Se deixar de usar tabelas para layout vai ter um site mais leve e vai perder muito menos tempo quando tiver que mudar o layout, se escrever HTML bom vai ter menos trabalho para escrever CSS, para fazer o CSS mobile e o de impressão, e se usar jQuery vai escrever javascript em um terço do tempo.

Note que esses três exemplos também tiram benefícios do fato de muita gente estar usando. Há muitos bons lugares para se aprender HTML e CSS, há muitos sistemas Open Source que já trabalham gerando código bom e os buscadores entendem a semântica do bom HTML. Mas você não depende desses benefícios para tomar a decisão de uso. Quando começamos, há dez anos, a fazer layouts tableless, não aparecíamos melhor no Google e praticamente não havia sistemas gerando HTML direito. Mas o fizemos assim mesmo porque os benefícios imediatos compensavam o esforço.

É por isso que eu temo que nunca teremos uma web semântica de verdade, e estamos condenados a fazer HTML parsing para sempre.

Há exceções. RSS, por exemplo. RSS é uma sombra do que poderia, mas é um padrão de sucesso, amplamente adotado. E não pode ser explicado com minha teoria do benefício individual imediato. Se você estiver usando RSS sozinho no mundo, não terá nenhum benefício. Talvez o sucesso do RSS se deva ao fato de precisar de uma pequena rede de usuários para oferecer um grande benefício.

Você já se perguntou como foram vendidos os primeiros aparelhos de FAX? Ter um FAX só faz sentido se mais gente tiver. Foram vendidos aos pares. As empresas o compravam para trocar documentos entre a matriz e as filiais. O fato de poder trocar documentos com o resto do mundo era, no início, um “benefício adicional”. Se você precisa trocar conteúdo com um site parceiro e vocês forem os únicos usuários de RSS no mundo, terá valido a pena. Conforme a comunidade de usuários aumentava, o valor de ter RSS crescia. Muita gente começou a usar Bloglines e todo mundo queria entrar na festa.

Há alguns anos eu percorri o país com o pessoal da Locaweb comparando o modelo de adoção do RSS com o que eu imaginava que seriam os microformats. Eu estava errado. Pense um segundo no formato de reviews dos microformats. Qual o real benefício de usá-lo? Há alguma aplicação indispensável, onde você realmente quer estar, baseada em hReview? Para que você vai perder seu tempo?

Será que não estamos resolvendo o problema errado? Quando o Diego diz que bordas arredondadas são mais importantes que RDF, será que ele não tem razão? Para meus clientes, hoje, bordas arredondadas com CSS significam um site mais rápido, mais barato (menos tempo gasto recortando imagens) e, para os sites muito visitados, economia de banda. É uma diferença pequena, mas é uma vantagem. E RDF? Além de oferecer RSS, que nem vai ser lido como XML, o que eu posso fazer de real hoje com RDF para meus clientes?

Desculpe se meu raciocínio parece mesquinho. Ele é. Estou tentando ser realista. Uma das principais influências sobre as decisões humanas é a inércia, e não acredito que o mundo vá, num futuro próximo, adotar de maneira revolucionária o RDF ou mesmo o XHTML. Ainda acho essas idéias fantásticas, só não sei se são possíveis.

O realismo também me faz crer que a nova estratégia de especificações modulares do W3C é uma coisa boa. Sofremos décadas com implementações parciais do HTML 4 e do CSS 2. Agora vamos assumir a realidade inevitável. Os desenvolvedores de navegador se sentirão mais à vontade para dizer a você o que funciona ou não. E não precisamos esperar anos para a definição de um padrão. Podemos usar os recursos com os quais o consórcio já concordou hoje. Leva mesmo alguns anos para o W3C bater o martelo sobre determinado padrão, e as especificações modulares representam um ciclo de releases muito mais dinâmico.

Já temos um acordo sobre CSS Transform, bordas arredondadas, múltiplos backgrounds, repetição no DOM, validadores de formulários, SVG, DOM Storage, querySelectors e uma série de outros recursos legais. Por que esperar até a próxima Olimpíada para dizer aos desenvolvedores de browsers: “Ok, pessoal, fechamos tudo, HTML 5 e CSS 3 já são padrões, podem implementar”? De qualquer maneira, a adoção modular das especificações do W3C é inevitável. Embora a especificação tenha saído inteira, a adoção foi modular no HTML 3, no HTML 4, no CSS 2. Sabendo que não vai ser diferente mesmo, não é melhor que tenhamos bonitas tabelas de compatibilidade entre o que existe e o que cada navegador suporta?

Dá uma olhada na lista de módulos do CSS3. Você não quer esperar isso tudo ficar pronto para ter bordas arredondadas.

• O Caminho Suave para o Tableless
• O que é Tableless?
• Sobre Internet Explorer para Mobile – Breve impressão
• Não “otimize” seu código
• O que são Media Types do CSS?

Essa minha iniciativa me gerou um conhecimento terrível sobre o assunto. Eu sabia muito bem o que funcionava e o que deixava de funcionar em diversos tipos de layouts. Eu descobri que TUDO é possível com CSS, em uma época que todo mundo falava que ele era limitado.
A maior parte dos problemas que eu enfrentei de compatibilidades de browsers em layouts em projetos de clientes, eu já tinha solucionado nos layouts que implementei nos estudos. E isso foi ótimo. Eu me valorizei como profissional, e depois até me chamavam de especialista… Veja só que honra. Tudo isso, porque eu não fiquei de nhê nhê nhê como alguns por aí.

Como programar, implementar XHTML/CSS também é de graça! Não tem desculpa.
Não há nada que te impeça de sentar o bundão na cadeira e escrever código. Nada.
Mas aí você pode dar a desculpa de: “- Naquele tempo nenhum site era escrito nos padrões, hoje todos são Tableless!” E eu digo: “- E daí?”.
Será que são escritos de forma semântica? Será que não tem muito código? Não há solução melhor?

A minha revolta aqui é contra aqueles profissionais que não fazem questão de aprender mais. Que simplesmente fazem apenas o que mandam e não tem o desejo de mudar o mundo em nenhum sentido.

• Ah, o maravilhoso mundo real
• Não “otimize” seu código
• Formulário Básico em 8 minutos – Tableless form
• Informação e Formatação; As duas camadas de desenvolvimento web
• Fiat Uno e Peugeot 206

Há várias maneiras de organizar os arquivos CSS de um site. Há sites que não precisarão de vários arquivos, bastando apenas um. Para estes devemos apenas ter cuidado com o código. Deixando-o simples e legível. Sempre tomando cuidado com a quantidade de linhas e código desnecessário. A estrutura seria mais ou menos essa:

Grandes portais e sites com uma visitação extrema, podem querer otimizar esse código. Isso é considerável apenas para estas excessões. O preço da banda é alto e qualquer 1Kb que economizarem será um caminhão de dinheiro que economizarão. Para sites pequenos, e até mesmo alguns sites de médio porte, na minha opinião, não é necessário haver uma “otimização de código“.

Se você perceber que as páginas são muito diferentes uma das outras e que o código está aumentando descontroladamente, é muito aconselhável você dividir o código CSS para cada padrão de página. Isso ajuda a controlar o tamanho do código e permite que você modifique uma parte do site sem interferir em outras páginas.

Essa opção é ótima para um site que tenha várias seções e cada seção tem um design diferente. Há um inconveniente: o código dentro do HEAD pode ficar enorme com tantas tags de LINK importando os arquivos de formatação. Para mudar isso, você pode fazer duas coisas: a primeira é fazer um arquivo CSS que importe todos os outros arquivos e linkar no HEAD apenas este arquivo.

Com essa primeira opção, o browser ainda carregará todos os arquivos CSS de uma vez. Pode ser que o carregamento fique pesado.
Por isso, há uma segunda opção que é conversar com seu programador para que ele faça uma mágica onde o site carregue apenas o arquivo CSS relativo àquela página. Quando visitamos a página interna, não é necessário carregar o arquivo CSS da HOME, por exemplo. Essa mágica previniria isso.

Outras pessoas preferem separar todo o código CSS em dois arquivos. Um arquivo conterá apenas informações de cor e fonte. E no outro arquivo haverá apenas informações sobre a estrutura do site: largura, altura, tamanho, margin, padding, position, float, etc.
Essa maneira é ótima para caso você quiser dar ao usuário opções de cores. O programador pode fazer um javascript maneiro que permita o usuário clicar e mudar a cor. O designer prepara vários CSS com regras de cores diferentes. A estrutura pode continuar a mesma, mas a paleta de cores muda. A mesma coisa pode-se fazer com a estrutura. A cor continua, mas a estrutura pode ser alterada de acordo com a opção do usuário.

Essas seriam as formas mais comuns de organizar seu CSS. Perca um bocado de tempo planejando essa estratégia. Se o site é muito grande, esse tipo de planejamento prévio pode salvar o projeto. Vale a pena a equipe definir padrões desenvolvimento. O CSS é um dos fatores definitivos para manutenção, velocidade e compatibilidade do site. Um CSS fora de controle é um pesadelo que você não quer ter.

• Ah, o maravilhoso mundo real
• Implementar XHTML/CSS é grátis
• Não “otimize” seu código
• Tabelas semânticas
• Propriedade Float do CSS

O código era o grande problema. A quantidade de código interferia diretamente na performance do site. E isso fez com que os desenvolvedores encontrassem saídas não muito agradáveis.

Era comum fazer códigos como o de baixo:

1
2
3
4
5
6
7
8
9
10

<table>
 <tr>
   <th>Produto</th>
   <th>Preço</th>
 </tr>
 <tr>
   <td>Tênis</td>
   <td>R$230</td>
 </tr>
</table>

Se transformarem em verdadeiros monstros:

<table><tr><th>Produto</th><th>Preço</th></tr><tr><td>Tênis</td><td>R$230</td></tr></table>

Isso tudo para economizar alguns bytes, que dependendo do site, significavam teras e teras de banda por mês. Naquele tempo, fazer isso era totalmente justificável. Precisávamos de alguma forma diminuir esse código para que o site ficasse mais rápido para o usuário e as requisições não sobrecarregassem o servidor.

Hoje isso é totalmente dispensável.

Aprendemos a utilizar o CSS e sabemos escrever HTML semântico.
A utilização dos Padrões trazem uma série de vantagens, e uma grande parte dessas vantagens são por causa da diminuição do código. Com o desenvolvimento de camadas e principalmente por causa do uso do CSS, não precisamos mais “otimizar” o código.

Mas parece que os desenvolvedores gostam de coisas complicadas. Esse mal costume de otimização de código ainda existe, e hoje querem otimizar o CSS. Eu acho totalmente inútil. O CSS foi feito para controlar o visual do site inteiro. Ele tirou a responsabilidade de formatação que colocávamos no HTML. Seu trabalho é exclusivamente esse: controlar o visual e diagramação do site.
É normal ele ficar grande, enorme, bizarro! Sim, haverão alguns casos que o tamanho superará mais de 1000, 2000, 3000, 4000 linhas.
Dá para evitar? Claro que dá! Pense simples. Module os arquivos. Faça um planejamento. Mas NUNCA faça com que um CSS escrito assim:

1
2
3
4
5
6
7

div {
 padding: 10px;
 border: 1px solid #CCC;
 width: 485px;
 height: 37px;
 background: #EEE;
}

Fique assim:

1

div{padding:10px;border:1px solid #CCC;width:485px;height:37px;background:#EEE}

Tenha dó do seu próximo e tenha dó de você mesmo.

Se você escreve o código de acordo com os Padrões, já economizou código suficiente. Não prejudique a manutenção do site por conta dessa neura. Escreva código legível!

Há outro ponto que devemos levar em consideração: imagine que o site pese 40Kb. Estes 40Kb são compostos por 20Kb de CSS e 20Kb de HTML. O CSS tem uma característica interessante: ele é cacheado pelo browser quando visitante entra no site.
Na primeira visita do usuário ele baixará 40Kb de uma vez. Já na segunda visita ele baixará apenas 20Kb relativos ao HTML. Ele não precisará baixar os 20Kb de CSS porque o arquivo já está cacheado pelo browser.

Não “otimize” seu código CSS, nem seu código HTML. Faça apenas com Padrões Web e siga categoricamente a semântica. É a melhor otimização que você pode conseguir.

O Leonardo Caineli escreveu um artigo sobre isso. Claro, discordo da opinião dele.

[update]Depois do post o pessoal chamou a atenção para essa prática em empresas grandes. Notei que no post eu não falei nada sobre isso. Sim, concordo que essa prática, só nessa hipótese, é totalmente considerável.

Quando treinei a primeira equipe do Terra – da época do site laranjão, lembra-se? – a primeira coisa que eles fizeram foi converter a home, e eles ainda sim queriam colocar todo o CSS em apenas uma linha.

Realmente 1Kb multiplicado por milhões é coisa para caramba e não há banda que agüente. Por isso, é totalmente aceitável que sites com um porte muito grande, “otimizem” seu código. [/update]

• Ah, o maravilhoso mundo real
• O Caminho Suave para o Tableless
• Implementar XHTML/CSS é grátis
• Tabelas semânticas
• Informação e Formatação; As duas camadas de desenvolvimento web

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<table>
<tr>
<td>Produto</td>
<td>Descrição</td>
<td>Valor</td>
</tr>
<tr>
<td>Tênis</td>
<td>Tênis com amortecedor, tecido vermelho com cadarço preto.</td>
<td>R$350,00</td>
</tr>
<tr>
<td>Camiseta</td>
<td>Tamanho GG, cor preta e uma estampa nas costas.</td>
<td>R$55,00</td>
</tr>
<tr>
<td>Calça</td>
<td>Tecido Jeans, azul claro, com botão duplo.</td>
<td>R$105,00</td>
</tr>
</table>

Para nós que enxergamos bem e conseguimos fazer uma breve interpretação de texto, conseguimos entender na maioria das vezes qual o assunto das tabelas na página.

Mas e o Google? E o leitor de tela do cego?

Por isso, a tabela tem algumas tags que ajudam o desenvolvedor a dar mais informação sobre o conteúdo daquela tabela.

Há algumas tags que iremos acrescentar em nossa tabela para dar essa informação extra ao visitante, seja ele ser humano ou robô.

SUMMARY – Dizendo do que se trata a tabela

O atributo summary é colocado na tag TABLE. Ela serve para indicar do que se trata aquela tabela, dizendo sua utilidade e que tipo de informação está descrevendo.

1

<table summary="Lista de produtos em promoção">

TH – Table Header

Considerando o código que colocamos mais acima, há os títulos de células PRODUTO, DESCRIÇÃO e VALOR. Esses títulos, devem ser destacados como título, não apenas modificando seu visual pelo CSS, mas também destacando-os pelo código. Para fazermos isso, iremos utizar a tag TH.

Essa tag irá indicar que tais células são títulos. O nosso código ficará assim:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<table summary="Lista de produtos em promoção">
<tr>
<th>Produto</th>
<th>Descrição</th>
<th>Valor</th>
</tr>
<tr>
<td>Tênis</td>
<td>Tênis com amortecedor, tecido vermelho com cadarço preto.</td>
<td>R$350,00</td>
</tr>
<tr>
<td>Camiseta</td>
<td>Tamanho GG, cor preta e uma estampa nas costas.</td>
<td>R$55,00</td>
</tr>
<tr>
<td>Calça</td>
<td>Tecido Jeans, azul claro, com botão duplo.</td>
<td>R$105,00</td>
</tr>
</table>

THEAD – Cabeçalho da Tabela

Normalmente as tabelas tem sempre uma linha de títulos, como a nossa tabela acima. Precisamos informar então, que essa linha é um cabeçalho, que contém os títilos das colunas ou linhas. Para isso, envolveremos a TR que contém as THs com a tag THEAD. Nosso código ficará dessa forma:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<table summary="Lista de produtos em promoção">
<thead>
<tr>
<th>Produto</th>
<th>Descrição</th>
<th>Valor</th>
</tr>
</thead>
<tr>
<td>Tênis</td>
<td>Tênis com amortecedor, tecido vermelho com cadarço preto.</td>
<td>R$350,00</td>
</tr>
<tr>
<td>Camiseta</td>
<td>Tamanho GG, cor preta e uma estampa nas costas.</td>
<td>R$55,00</td>
</tr>
<tr>
<td>Calça</td>
<td>Tecido Jeans, azul claro, com botão duplo.</td>
<td>R$105,00</td>
</tr>
</table>

TFOOT – Indicando o rodapé da tabela

Logo após o THEAD, iremos indicar quais informações irão no rodapé do documento, utilizando a tag TFOOT. Aqui, iremos colocar as mesmas informações do THEAD, supondo que a tabela é muito grande e queremos que o usuário, ao chegar no rodape, não se perca com a identificação das colunas. Nosso código fica assim:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

<table summary="Lista de produtos em promoção">
<thead>
<tr>
<th>Produto</th>
<th>Descrição</th>
<th>Valor</th>
</tr>
</thead>
<tfoot>
<tr>
<th>Produto</th>
<th>Descrição</th>
<th>Valor</th>
</tr>
</tfoot>
<tr>
<td>Tênis</td>
<td>Tênis com amortecedor, tecido vermelho com cadarço preto.</td>
<td>R$350,00</td>
</tr>
<tr>
<td>Camiseta</td>
<td>Tamanho GG, cor preta e uma estampa nas costas.</td>
<td>R$55,00</td>
</tr>
<tr>
<td>Calça</td>
<td>Tecido Jeans, azul claro, com botão duplo.</td>
<td>R$105,00</td>
</tr>
</table>

TBODY – Indicando o corpo da tabela

Se há um cabeçalho e um rodapé na tabela, é mais do que normal haver um BODY, apresentando as informações que de fato interessam ao usuário.
O TBODY deve ir logo após a tag TFOOT. Sinceramente, não sei porque a tag TFOOT não vem após a TBODY, já que é o código de Rodapé. Se você souber, por favor, me diga!

Nosso código fica dessa forma:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

<table summary="Lista de produtos em promoção">
<thead>
<tr>
<th>Produto</th>
<th>Descrição</th>
<th>Valor</th>
</tr>
</thead>
<tfoot>
<tr>
<th>Produto</th>
<th>Descrição</th>
<th>Valor</th>
</tr>
</tfoot>
<tbody>
<tr>
<td>Tênis</td>
<td>Tênis com amortecedor, tecido vermelho com cadarço preto.</td>
<td>R$350,00</td>
</tr>
<tr>
<td>Camiseta</td>
<td>Tamanho GG, cor preta e uma estampa nas costas.</td>
<td>R$55,00</td>
</tr>
<tr>
<td>Calça</td>
<td>Tecido Jeans, azul claro, com botão duplo.</td>
<td>R$105,00</td>
</tr>
</tbody>
</table>

CAPTION – Título do Cabeçalho

A tag CAPTION define um título para o cabeçalho da tabela. Esse título vai apresentar a tabela para o usuário. Ele deve ser colocado logo antes da tag THEAD e logo após tag TABLE.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<table summary="Lista de produtos em promoção">
<caption>Produtos em Promoção</caption>
<thead>
<tr>
<th>Produto</th>
<th>Descrição</th>
<th>Valor</th>
</tr>
</thead>
<tfoot>
<tr>
<th>Produto</th>
<th>Descrição</th>
<th>Valor</th>
</tr>
</tfoot>
<tbody>
<tr>
<td>Tênis</td>
<td>Tênis com amortecedor, tecido vermelho com cadarço preto.</td>
<td>R$350,00</td>
</tr>
<tr>
<td>Camiseta</td>
<td>Tamanho GG, cor preta e uma estampa nas costas.</td>
<td>R$55,00</td>
</tr>
<tr>
<td>Calça</td>
<td>Tecido Jeans, azul claro, com botão duplo.</td>
<td>R$105,00</td>
</tr>
</tbody>
</table>

Já com essas tags diferenciadas, o trabalho que teríamos para formatar o cabeçalho, título e conteúdo da tabela ficou mais leve. Em vez de colocar class em tudo quanto é TR para diferenciar as partes da tabela, conseguimos formatar cada um desses grupos sem encostar no código HTML. Claro, que se você quiser fazer algo mais rebuscado, a modificação do código HTML será inevitável. Mas, com esse pouco código que escrevemos, já procrastinamos essa necessidade.

• Ah, o maravilhoso mundo real
• Não “otimize” seu código
• Implementar XHTML/CSS é grátis
• Modulando o CSS
• O Caminho Suave para o Tableless

Um pouco de História

Por volta de 1997, os computadores da Apple traziam por padrão o Netscape. Naquele tempo o mercado de browsers não era tão acirrado como hoje e os concorrentes eram poucos. O Internet Explorer estava em sua versão 2/3. Mesmo assim, o Internet Explorer para Mac era também distribuído com o MacOS durante os 5 anos de acordo entre Apple e Microsoft. A Microsoft laçou 3 versões principais do seu navegador para o Mac, parando na versão 5 em março de 2000.

Em 2003, a Apple anunciou que eles estavam desenvolvendo seu próprio browser baseado no motor de renderização KHTML. A versão 1.0 foi lançado como browser padrão do MacOS por volta de Junho de 2003. O Internet Explorer ainda era distribuido no sistema, mas agora como um navegador alternativo, até Abril de 2005.

Motor de Renderização WebKit

O Safari utiliza um motor de renderização chamado WebKit. O WebKit tem dois motores de renderização: o WebCore, que é o motor de renderização baseado no KTHML do Konqueror. E o JavaScriptCore, baseado no motor de javascript KDE chamado KJS. Esses motores estão sob Licensa GNU.

A Apple, ao fazer o Safari fez muitas atualizações e modificações no motor KHTML, deixando-o mais maduro e robusto. Essas modificações foram devolvidas para a comunidade e incorporadas no Konqueror.

MobileSafari e Safari para Desktop

A idéia é que o usuário tenha uma experiência muito próxima a experiência que ele tem no desktop. Por isso o Safari para iPhone (MobileSafari) foi feito sob o mesmo motor de renderização WebKit do Safari para Windows e Mac. Diferenças: 1) Se o site não foi feito para iPhone, ele renderiza a página da mesma forma como renderiza em um Safari para desktop, mas miniaturizada. 2) A interação do usuário.

Padrões Suportados

Para que a renderização do MobileSafari seja fiel ao Safari para desktop, ele tem grande suporte aos Padrões Web.

• HMTML 4.01
• HTML 5
• XHTML 1.0
• CSS 2.1
• Parte do CSS 3
• Javascript 1.4
• Ajax
• DOM

É interessante notar que temos uma certa liberdade de desenvolvimento web no iPhone. Há facilidades como cantos arredondados que não podemos contar no desenvolvimento focado para desktops. Isso tráz vantagens pra você, desenvolvedor, porque facilitará seu trabalho, e para o usuário porque ele terá uma experiência mais rica.

Limites dos recursos

Embora o iPhone suporte as tecnologias mais atuais de desenvolvimento web, não podemos esquecer de que ele é um dispositivo móvel, com capacidade de processamento muito menor que a de um desktop. Por isso, há algumas limitações de recursos que devemos nos atentar.

Para códigos:

• 10Mb para arquivos Javascripts e XML
• O tempo de execução de um Javascript é limitado a 10 segundos. Se passar de 10 segundos, o Safari pára a execução em algum lugar aleatório do seu código.
• Javascripts alocados limitados a 10Mb
• Máximo de 8 documentos abertos de uma vez

Para imagens:

• Limite máximo do tamanho de GIF, PNG e TIFF são 2 Megapixels
• A decodificação máxima dos tamanhos de JPGs são 32 Megapixels. Utilizando SubSampling
• O tamanho máximo de GIFs animados deve ser menor que 2MB. Para arquivos animados maiores, só é mostrado o primeiro frame.

Verifique sempre o tamanho final de sua página. Normalmente o sites com 30Mb para menos funcionam muito bem no iPhone.

• Sobre Internet Explorer para Mobile – Breve impressão
• Sites para Dispositivos Móveis – MediaType
• Navegação em mobiles
• Mobilidade na cabeça
• Breve introdução: XHTML Mobile Profile

Você precisa saber:

• Lógica de programação
• PHP básico
• Javascript básico
• Noções de Orientação a Objeto
• Noções de Padrões web

O que você vai aprender?

• Python
• Orientação a Objeto de verdade, na prática
• Testes Unitários
• Subversion
• jQuery

Se você se der bem aprendendo os itens acima, terá chance de se divertir muito mais. Veja o que mais você pode aprender:

• Desenvolvimento no Linux
• Padrões web
• MySQL
• Vim (se você estiver mesmo afim)

Além disso, você terá acesso aos cursos da Visie que acontecerem no período em que estiver trabalhando conosco.

A remuneração

É um estágio. Temos remuneração para esse estágio bem acima da média do mercado, mas não vá sonhando com altos salários agora. Preocupe-se mais com o que você pode aprender do que com o quanto você pode ganhar imediatamente. Há possiblidade de efetivação ao final do estágio (com salário de verdade.)

Como se inscrever?

Mande seu CV para trampo arroba visie.com.br. No e-mail, fale um pouco sobre você e sua experiência com desenvolvimento. Coloque no título do e-mail: ESTÁGIO VISIE.

Peguntas comuns

Posso trabalhar à distância?

Não. É um estágio. Não queremos apenas que você trabalhe. Queremos te ensinar um bocado de coisas. Não dá para fazer isso à distância.

Não é estranho pedir que o sujeito tenha “experiência”, ou conhecimentos em PHP e Javascript. Uma vez que ele está indo a um estágio para aprender?

Não. A web está aí. O estágio não é para que você aprenda o que poderia ter aprendido sozinho em sua casa. É para te ensinar o que você só vai aprender se vier até aqui. Estamos pedindo conhecimento básico.

Preciso estar na faculdade?

Não.

Posso indicar isso para um amigo?

Claro. Por favor.

• @font-face – Fonts externas na web
• Ah, o maravilhoso mundo real
• Implementar XHTML/CSS é grátis
• Modulando o CSS
• Não “otimize” seu código

get_header()

O <?php get_header(); ?>inclui em seu template o arquivo header.php, que é onde vai o cabeçalho do seu site. É lá onde vai o começo da estrutura básica do HTML – Doctype, html, head, title, metatags e body.

get_sidebar()

O <?php get_sidebar(); ?> é a função que incluirá em seu template a sua coluna lateral. Menu lateral, banners, informações e tudo o que normalmente vai em um sidebar.

get_footer()

O <?php get_footer(); ?> inclui em seu template o arquivo footer.php. É lá onde você normalmente termina seu . É neste arquivo que você terá o código do rodapé e de elementos que sempre seguirão o final da página.

Se o WordPress não encontrar, por exemplo o arquivo footer.php, ele irá incluir o arquivo relacionado do theme default: wp-content/themes/default/footer.php. O mesmo acontece para o sidebar.php, o header.php e o comments_template().

Incluindo qualquer arquivo

Claro que você vai querer incluir outros arquivos. Por exemplo, caso seu site tiver duas colunas, ou o seu cabeçalho for muito grande e você quiser inserir os elementos em arquivos separados. Nestes casos você pode utilizar esse código:

<?php include (TEMPLATEPATH . '/header2.php'); ?>

O WordPress vai inserir o arquivo pedido como um include PHP normal.

Quer saber mais sobre WordPress? Fique antenado aqui!

• WordPress – Uma pequena introdução
• Colocar Rodapé fixo no fim da página
• Convertido – Menu (Livraria Cultura)
• Ah, o maravilhoso mundo real
• Introdução ao CSS Animation

E você, nosso fiel leitor, pode ganhar um convite. Vamos publicar posts “relâmpago” aqui no Tableless dias antes dos eventos do Rio de Janeiro, Porto Alegre, Belo Horizonte e Curitiba. Cada post vem com uma pergunta sobre XHTML, CSS ou programação. A primeira pessoa que responder corretamente a pergunta ganha um convite. Vão ser dez perguntas e dez convites para cada cidade, fique ligado.

Já tenho uma mini-aplicação a desenvolver, mas ainda dá tempo de mudar de idéia, ou mesmo de incorporar a ela idéias criativas. Se você tiver alguma sugestão, por favor, deixe um comentário.

• Formulários definitivos e problema de lógica
• ELPI POA: ainda dá tempo!
• @font-face – Fonts externas na web
• Ah, o maravilhoso mundo real
• Digest 06/09: Javascript, JQuery