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.

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

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!
• Ah, o maravilhoso mundo real
• Digest 06/09: Javascript, JQuery
• Digest 05/09: Javascript, JQuery

É um caminho muito duro o que separa o desenvolvedor acostumado a editores visuais do desenvolvimento de código coerente. E é muito comum que o designer desista após uma primeira tentativa frustrada de desenvolver um website tableless, com layout CSS e XHTML validado.

Por isso gostaria de propor um caminho gradual, mais suave, para aqueles que querem se aventurar pela primeira vez pelos padrões web. O princípio desse método é da recompensa. Você pode obter um grande benefício aproximando seu código dos padrões web, mesmo que não faça tudo de uma vez. Quero mostrar como você pode começar, e obter benefícios imediatos.

Limpe seu HTML

A minha primeira recomendação é que você estude CSS. Comece pela formatação básica de fonte, cor e tamanho. Isso vai te garantir código menor e produtividade maior com pouquíssimo esforço.

Assim, ao criar um item de menu, você vai evitar códigos como este:

<a href="parceiros.asp"><font
face="Arial, Helvetica, Sans-serif" size="2"
color="#FF3300"><b>Parceiros</b></font></a>

Colocando no lugar:

<a href="parceiros.asp" class="menu">Parceiros</a>

Tendo no CSS:

.menu{
font-family: Arial, Helvetica, Sans-serif;
font-size: 80%;
font-weight: bold;
color:#FF3300;
}

Como você pode ver, o CSS é extremamente simples. Aprender esses quatro atributos, mais o “font-style” (para fazer itálico), é a primeira coisa que eu recomendo. É claro, isso apenas faz cócegas nas possibilidades do CSS, ainda há muito o que aprender, mas recomendo começar por aí porque é algo que você pode aprender em alguns minutos e vai te salvar muito, muito tempo. E você vai começar a ter o controle da formatação, tendo todas as definições de fonte em um único arquivo, podendo alterar, por exemplo, a qualquer momento, a fonte de todo o conteúdo ou de todos os menus do site.

O passo seguinte para limpar seu HTML é se livrar do spacer.gif, aquele gif transparente de 1 pixel que se usa para dar espaços em tabelas, e das dezenas de tabelas aninhadas. Para isso vamos começar a estudar o “box-model”.

O pulo-do-gato aqui é um atributo CSS chamado padding. O padding é a distância entre as bordas de um elemento e o texto dentro dele. Assim, se é preciso que o conteúdo de uma célula esteja a 10 pixels da borda esquerda, ao invés de inserir uma célula extra como espaçador, ou inserir mais uma tabela, basta definir uma classe para essa célula. Uma vez que você já está colocando a formatação no CSS, provavelmente esta célula já tem uma classe. Então basta:

.conteudo{
padding-left:10px;
}

Isso vai fazer com que o texto esteja a 10 pixels da borda esquerda do documento. Ah, claro, o CSS também pode livrar você de definir no HTML as bordas e o background das células de sua tabela. Lembre-se, quanto mais layout e formatação você colocar no CSS, mais controle terá sobre seu site, principalmente em mudanças de layout durante o processo de produção e em futuras manutenções. O site também será mais leve para carregar.

Concluímos então que, após aprender os atributos de formatação de fonte, o passo seguinte é aprender os atributos background, border e padding. Indo até aqui você com certeza será um desenvolvedor muito mais feliz! Depois de limpar seu HTML, ganhar controle sobre a formatação de seu site e se tornar muito mais produtivo, você está pronto para passar à segunda etapa, correndo atrás da semântica.

Começando o Trabalho de Gente Grande

Muito bem, agora você já pode limpar seu código. Vamos estudar um exemplo prático. No começo de cada uma de suas páginas você tem um título, cujo código hoje é assim:

<font face="Arial, Helvetica, Sans-serif" size="4"
color="#FFFF00"><b>Novidades</b></font>

Ao limpar esse código, você vai substituir esse monte de tags por uma só. Que tag você vai usar? Como o CSS te permite formatar qualquer elemento, muita gente que começa a estudar o assunto acha que é indiferente que tag usar, e coloca algo como:

<p class="titulo">Novidades</p>

Agora, veja bem, outro desenvolvedor poderia resolver o mesmo problema com:

<div class="titulo">Novidades</div>

E o resultado visual poderia ser o mesmo. Acontece que há algo na natureza do HTML que nos diz que tag usar. Chamamos esse algo de “semântica”: as tags do HTML tem significado. A tag P é para parágrafos, a tag DIV para divisões no conteúdo, e há uma série de tags para título, h1, h2, h3, h4, h5 e h6. Assim, se você pode usar qualquer tag, pode fazer assim:

<h1>Novidades</h1>

O que você ganha com essa preocupação? Os buscadores inteligentes podem ler semanticamente o conteúdo de um documento, entendendo que trecho de código é um título, por exemplo. Assim, escrever HTML semanticamente correto pode melhorar muito sua visibilidade em buscadores. O segundo bom motivo é que você vai saber para que serve cada tag se tiver que mexer nesse mesmo documento daqui a alguns meses. E vai ser mais fácil também se outra pessoa tiver que dar manutenção no seu código.

Logo, use as tags do HTML para aquilo para o que foram criadas:

• dd, dl e dt para listas de definições (um glossário, por exemplo)
• h1 a h6 para títulos
• p para parágrafos
• abbr para abreviaturas e acronym para acrônimos
• blockquote e q para citações longas e curtas
• address para endereços (sabe aquele rodapé onde vai o endereço e o telefone da empresa?)
• ul e ol para listas e li para os itens da lista

Você pode obter uma lista mais abrangente em:
http://www.w3schools.com/xhtml/xhtml_reference.asp

E formate tudo ao seu gosto com CSS.

Finalmente, Livrando-se das Tabelas

Não há bons motivos para você eliminar a qualquer custo todas as tabelas de seu primeiro trabalho. Conheço alguns excelentes profissionais, muito talentosos, que fizeram um ótimo trabalho em sua primeira tentativa de tableless. Mas a maioria dos que eu vi tentarem demoraram muito para conseguir da primeira vez, e alguns não obtiveram os resultados que esperavam. Isso tudo serve para que você possa produzir mais rápido e melhor, não o contrário. Então vá com calma. Faça alguns estudos em tableless, comece eliminando parte das tabelas em seus primeiros trabalhos. Por exemplo, remover as células de tabela que formam o menu, trocando por uma lista (com as tags ul e li), é um ótimo desafio para o primeiro projeto.

Ah, e não se esqueça que para dados como uma tabela periódica ou um calendário a solução semanticamente correta é a tabela mesmo. Ou seja, tableless não é ausência de tabelas, é o seu uso apenas onde é semanticamente justificável.

Não vou entrar em detalhes aqui, porque já escrevi bastante sobre como construir um layout no Tutorial Tableless Básico, mas o conselho é ir com calma, sem estresse. Você logo vai estar produzindo tableless mais fácil do que produz sites com tabelas.

XHTML

Há uma coisa que muita gente que está começando me pergunta: o que é e para que serve esse tal de XHTML? É muito mais simples do que parece. Um arquivo XHTML é um arquivo HTML, que pode ser lido por qualquer browser. Não estamos falando de um novo HTML, com novas tags ou coisa assim. Pelo contrário, o XHTML 1 foi feito para funcionar mesmo em navegadores antigos. Mas, ao mesmo tempo, Um arquivo XHTML é também um arquivo XML válido, que pode ser lido por qualquer interpretador de XML.

Meu primeiro conselho, nesse caso, é que você, se não trabalha com XML, deixe preocupação com o XHTML para depois de dominar bem o código semântico e o layout tableless. Não porque seja complicado, pelo contrário, transformar bom HTML em XHTML é bem simples, mas simplesmente porque você pode obter benefícios muito significativos, e muito mais rapidamente, aprendendo CSS do que XHTML.

O segundo conselho é que você comece a estudar o assunto. Depois de dominar bem layouts CSS, mergulhe no XML. A maioria dos bancos de dados hoje permite extrair dados diretamente em XML e todas as plataformas de aplicações web trabalham bem com XML. E com a poderosa linguagem XSLT você pode muito facilmente oferecer seus os dados em XHTML para o navegador.

Voando Alto

Estamos falando de muito mais do que criar sites estilosos. Há duas semanas esteve aqui um amigo com um Palm novo, um Zire 71, e um celular com acesso à internet. Isso está se tornando cada vez mais barato e comum. Conheço também uma porção de empresas e instituições, entre elas uma série significativa de TeleCentros e órgãos públicos, que estão adotando Linux como sistema operacional para desktops. O Google hoje é responsável por 90% do tráfego que meu site consegue de buscadores. É o primeiro colocado absoluto entre os buscadores. E conseguiu isso indexando semanticamente o conteúdo real dos sites. Praticamente todas as plataformas web estão oferendo suporte a XML e apostando na idéia de webservices.

Quem segue os padrões web não precisa ter medo do futuro. Não importa que browser vai ser o mais usado daqui a dois anos, que tecnologia vai estar na moda ou de onde as pessoas vão estar usando a internet. Seu site estará lá, leve, acessível, atual e útil.

• Ah, o maravilhoso mundo real
• Sobre Internet Explorer para Mobile – Breve impressão
• Sites para Dispositivos Móveis – MediaType
• O que é Tableless?
• Não “otimize” seu código