Há pequenas regras básicas que nós já conhecemos e que estão no HTML desde o início. Estas regras definem onde os elementos podem ou não estar. Se eles podem ser filhos ou pais de outros elementos e quais os seus comportamentos.

Dentre todas as categorias de modelos de conteúdo, existem dois tipos de elementos: elementos de linha e de bloco.
Os elementos de linha marcam, na sua maioria das vezes, texto. Alguns exemplos: a, strong, em, img, input, abbr, span.

Os elementos de blocos são como caixas, que dividem o conteúdo nas seções do layout.

Abaixo segue algumas premissas que você precisa relembrar e conhecer:

• Os elementos de linha podem conter outros elementos de linha, dependendo da categoria que ele se encontra. Por exemplo: o elemento a não pode conter o elemento label.
• Os elementos de linha nunca podem conter elementos de bloco.
• Elementos de bloco sempre podem conter elementos de linha.
• Elementos de bloco podem conter elementos de bloco, dependendo da categoria que ele se encontra. Por exemplo, um parágrafo não pode conter um DIV. Mas o contrário é possível.

Estes dois grandes grupos podem ser divididos em categorias. Estas categorias dizem qual modelo de conteúdo o elemento trabalha e como pode ser seu comportamento.

Categorias

Cada elemento no HTML pode ou não fazer parte de um grupo de elementos com características similares. As categorias estão a seguir. Manteremos os nomes das categorias em inglês para que haja um melhor entendimento:

• Metadata content
• Flow content
• Sectioning content
• Heading content
• Phrasing content
• Embedded content
• Interactive content

Abaixo segue como as categorias estão relacionadas de acordo com o WHATWG:

Metadata content

Os elementos que compõe a categoria Metadata são:

• base
• command
• link
• meta
• noscript
• script
• style
• title

Este conteúdo vem antes da apresentação, formando uma relação com o documento e seu conteúdo com outros documentos que distribuem informação por outros meios.

Flow content

A maioria dos elementos utilizados no body e aplicações são categorizados como Flow Content. São eles:

• a
• abbr
• address
• area (se for um decendente de um elemento de mapa)
• article
• aside
• audio
• b
• bdo
• blockquote
• br
• button
• canvas
• cite
• code
• command
• datalist
• del
• details
• dfn
• div
• dl
• em
• embed
• fieldset
• figure
• footer
• form
• h1
• h2
• h3
• h4
• h5
• h6
• header
• hgroup
• hr
• i
• iframe
• img
• input
• ins
• kbd
• keygen
• label
• link (Se o atributo itemprop for utilizado)
• map
• mark
• math
• menu
• meta (Se o atributo itemprop for utilizado)
• meter
• nav
• noscript
• object
• ol
• output
• p
• pre
• progress
• q
• ruby
• samp
• script
• section
• select
• small
• span
• strong
• style (Se o atributo scoped for utilizado)
• sub
• sup
• svg
• table
• textarea
• time
• ul
• var
• video
• wbr
• Text

Por via de regra, elementos que seu modelo de conteúdo permitem inserir qualquer elemento que se encaixa no Flow Content, devem ter pelo menos um descendente de texto ou um elemento descendente que faça parte da categoria embedded.

• HTML5 Diff
• Conteúdo, Flash e HTML
• Ah, o maravilhoso mundo real
• CSS3 – Novo mundo de possibilidades
• Apostila sobre HTML5

Essa apostila ficará em processo de constante atualização já que muitos pontos do HTML5 não foram ainda definidos e também porque diversas outras características estão sendo planejadas e rascunhadas ainda. Se você tiver qualquer sugestão, por favor, nos contacte.

Guia de Referência sobre HTML5

• Ah, o maravilhoso mundo real
• Conteúdo, Flash e HTML
• HTML5 Diff
• Porque é a web que comanda
• Aonde nos leva a morte do Internet Explorer 6?

O HTML5 ainda é um rascunho. Ele está sendo discutido entre o WHATWG e o W3C. Diversos pontos podem ser modificados ainda, por isso é interessante que você entenda e fique por dentro das discussões para que você atualize seu código quando necessário.

Um dos grandes objetivos do HTML5 é que ele seja retrocompatível. Isso evita o retrabalho de código e faz com que a web retome o rumo da semântica e do código enxuto. Vamos às mudanças:

O elemento B passa a ter o mesmo nível semântico que um SPAN, mas ainda mantém o estilo de negrito no texto. Contudo, ele não dá nenhuma importância para o text marcado com ele.

O elemento I também passa a ser um SPAN. O texto continua sendo itálico e para usuários de leitores de tela, a voz utilizada é modificada para indicar ênfase. Isso pode ser útil para marcar frases em outros idiomas, termos técnicos e etc.

O interessante é que nestes dois casos houve apenas uma mudança semântica. Provavelmente você não precisará modificar códigos onde estes dois elementos são utilizados.

Voce utilizará o SMALL para fazer literalmente os “letras miúdas” de um documento legal, comentários gerais ou até mesmo aqueles pequenos comentários e dicas que colocamos em campos de formulários e etc.

O HR virou um parágrafo de quebra. Ou seja, ele passa a ter a mesma importância do parágrafo, mas em um nível temático para quebra de linha.

Os elementos abaixo foram descontinuados por que seus efeitos são apenas visuais:

• basefont
• big
• center
• font
• s
• strike
• tt
• u

Como já era conhecido por alguns, os inputs ganharam novos valores no atributo TYPE. Estes novos valores permitem que browsers e outros user-agents melhorem a experiência do usuário, mostrando calendários e permitindo integração com agenda de contatos e etc. Permite também que os dados possam ser submetidos para o servidor com um formato específico. Valores como TEL, URL e EMAIL já tem efeitos em smartphones como iPhone:

• tel
• search
• url
• email
• datetime
• date
• month
• week
• time
• datetime-local
• number
• range
• color

Os elementos abaixo não foram incluídos na especificação porque não tiveram uso entre os desenvolvedores ou porque sua função foi substituída por outro elemento:

• acronym não foi incluído porque criou um bocado de confusão entre os desenvolvedores que preferiram utilizar a tag abbr.
• applet ficou obsoleto em favor da tag object.
• isindex foi substituído pelo uso de form controls.
• dir ficou obsoleto em favor da tag ul.

Este atributos foram descontinuados porque modificam a formatação do elemento e suas funções são melhores controladas pelo CSS:

• align como atributo da tag caption,
  iframe, img, input,
  object, legend, table,
  hr, div, h1, h2,
  h3, h4, h5, h6,
  p, col, colgroup,
  tbody, td, tfoot, th,
  thead e tr.

• alink, link, text e
  vlink como atributos da tag body.

• background como atributo da tag body.
• bgcolor como atributo da tag table, tr,
  td, th e body.

• border como atributo da tag table e
  object.

• cellpadding e cellspacing como atributos da tag
  table.

• char e charoff como atributos da tag
  col, colgroup, tbody,
  td, tfoot, th, thead

  e tr.

• clear como atributo da tag br.
• compact como atributo da tag dl, menu,
  ol e ul.

• frame como atributo da tag table.
• frameborder como atributo da tag iframe.
• height como atributo da tag td e th.
• hspace e vspace como atributos da tag
  img e object.

• marginheight e marginwidth como atributos da tag
  iframe.

• noshade como atributo da tag hr.
• nowrap como atributo da tag td e th.
• rules como atributo da tag table.
• scrolling como atributo da tag iframe.
• size como atributo da tag hr.
• type como atributo da tag li, ol e
  ul.

• valign como atributo da tag col,
  colgroup, tbody, td,
  tfoot, th, thead e
  tr.

• width como atributo da tag hr, table,
  td, th, col, colgroup

  e pre.

Alguns atributos do HTML4 não são mais permitidos no HTML5. Se eles tiverem algum impacto negativo na compatibilidade de algum user-agent eles serão discutidos.

• rev e charset como atributos da tag
  link e a.

• shape e coords como atributos da tag
  a.

• longdesc como atributo da tag img and
  iframe.

• target como atributo da tag link.
• nohref como atributo da tag area.
• profile como atributo da tag head.
• version como atributo da tag html.
• name como atributo da tag img (use id

  instead).

• scheme como atributo da tag meta.
• archive, classid, codebase,
  codetype, declare e standby

  como atributos da tag object.

• valuetype e type como atributos da tag
  param.

• axis e abbr como atributos da tag td

  e th.

• scope como atributo da tag td.

Há outras mudanças mais profundas, por isso sugiro que você leia esse documento inteiro: W3C HTML5 Diff.

Estes artigos também podem ajudar:

• Conteúdo, Flash e HTML
• Processos de Adoção e Padrões
• HTML5 – Mudanças na estrutura e Semântica
• Ah! O maravilhoso mundo real

• Ah, o maravilhoso mundo real
• O que são Media Types do CSS?
• Produtividade: editores e snippets
• Formulário Básico em 8 minutos – Tableless form
• O que é Tableless?

A guerra entre os Padrões Web e tecnologias como o Flash começou de verdade.
Desde o momento que as possibilidades do HTML5 e CSS3 foram publicadas, um pequeno burburinho entre os desenvolvedores sobre uma possível concorrência entre os Padrões e tecnologias como o Flash começou a rolar. Alguns desenvolvedores descrentes começaram a acreditar no poder das novas tecnologias para desenvolvimento web e novamente o HTML e o CSS tiveram a grande atenção de empresas e desenvolvedores.

Mesmo assim existem pontos que precisam ser esclarecidos. Muitos estão fazendo uma confusão com significados, objetivos e as reais soluções que essas novas tecnologias proporcionam:

1. O HTML5 sozinho não faz nada além de dar significado à informação. Com ele, o CSS 3 e o Javascript completam o pacote para que todas essas mudanças que andamos lendo faça sentido de verdade. Mesmo com a midia fazendo um alarde muito grande em cima do HTML 5, uma boa parte das mágicas deve-se ao poder do CSS 3.
   Contudo o HTML5 está sendo totalmente reformulado para que haja mais integração entre o trio HTML, CSS e Javascript.
2. Os browsers são independentes, mas trabalham todos juntos em pról dos Padrões Web. Embora cada um deles tenham interesses financeiros óbvios, todos eles sabem que a única maneira de estar à frente do concorrente é andar lado à lado com os Padrões. O que basicamente diferencia um browser do outro são os serviços agregados, velocidade e facilidade de uso. Dificilmente um browser ganhará mercado se ele for super ultra compatível com os padrões. A não ser que a massa de usuários saiba o que isso signifiqueo ou que haja uma campanha muito forte, partindos dos desenvolvedores e empresas interessadas para evangelizar e educar os usuários finais.
3. Se você não começar a forçar o desenvolvimento da sua empresa para que os projetos sejam desenvolvidos focando browsers atuais, pra ficar para obsoleto. Daqui pra frente o mercado vai ficar cada vez mais dinâmico. Conforme os browsers vão se atualizando e o W3C libera novos padrões, você, seu cliente e seu projeto podem ficar para atrás. Por isso é interessante haver principios de Graceful Degradation nos projetos para que usuários de browsers mais atuais se beneficiem de um visual mais bem acabado, velocidade de carregamento da página e tecnologia atual. Entenda que eu não estou dizendo para criar projetos para um browser específico, mas limitar características visuais e funcionais de browsers mais antigos.

O HTML foi criado por uma necessidade de compartilhar, interligar e portar informação. Logo, o HTML precisa ser uma linguagem que possa ser lida pr qualquer meio de acesso.

O HTML 5 modifica a forma com que damos significado para a informação na web. Você está acostumado a escrever código para criar elementos que são renderizados pelo browser e lidos por diversos meios de acesso. Estes elementos tem seus respectivos significados. Para manipular estes elementos, você utiliza Javascript para controlar o CSS que formata as características deste objeto. Por mais que bibliotecas como JQuery sejam ótimas, a maneira que manipulamos o comportamento dos elementos não é a melhor. Existem diversas necessidades que não são resolvidas de uma maneira fácil ou que simplesmente não há solução. Além do HTML 5 renovar a forma com que atribuímos significado, ele nos dá ferramentas para facilitar a manipulação dos elementos.

Alguns desenvolvedores não entenderam as verdadeiras mudanças do HTML 5 e suas reais implicações sobre o desenvolvimento client-side. Saiba que o HTML 5 veio para estreitar as ligações entre o HTML, o CSS e o Javascript. Todos eles trabalharão mais integrados a partir de agora. Se acostume para ver pencas de código Javascript por aí. Isso é por conta das famosas APIs que o HTML 5 está trazendo.

• Apostila sobre HTML5
• HTML5 Diff
• Conteúdo, Flash e HTML
• Google Apps não suportará mais IE6
• Porque é a web que comanda

A Web foi criada para facilitar o compartilhamento de informação. Este objetivo é muito claro quando estudamos sua história. Você pode enviar um email, um tweet ou uma mensagem no gTalk e a pessoa do outro lado ter essa informação na hora. É muito melhor do que esperar dias para receber uma folha de papel. A ideia da web é compartilhar e oferecer informação de fácil acesso. Não importa se isso seja uma mensagem de 140 caractéres ou se um portal de notícias completo.

Essa informação, por sua vez, precisa estar disponível a qualquer hora para ser consumida e reutilizada. Um exemplo clássico disso são os blogs. Os posts são acessíveis se você visitar a página ou por meio de RSS. Você pode acessar essa informação também pelo Google ou qualquer outro sistema de busca que exista. Se quiser, você pode usar seu dispositivo móvel para acessar essa informação aonde quer que esteja. Se você instalar em seu mobile uma App que baixa o conteúdo, melhor ainda, porque você poderá consumir essa informação offline.
O HTML foi criado para que isso tudo funcione perfeitamente. O HTML foi criado para construir uma web interoperável. Uma web que seja acessível em qualquer parte do planeta com qualquer tipo de dispositivo ou meio de acesso.

Não quero tirar o peso dos erros do W3C em demorar para reformular a linguagem. A W3C precisou de um empurrãozinho de vários desenvolvedores insatisfeitos pela falta de atitude e demora do W3C para reformular o HTML. Estes desenvolvedores por sua vez querem uma web mais pública, mais integrável, mais aberta. Estes objetivos estão sendo seguidos à risca agora com o desenvolvimento do HTML5 e do CSS3. Sugiro que leia o texto do W3C explicando qual é o objetivo real do HTML. A brief history of HTML.

Quando falamos sobre a importância de separar o desenvolvimento web em camadas, queremos que o desenvolvedor web entenda que há um motivo por trás de toda essa metodologia. Aquela ideia de que “Conteúdo é Rei” precisa ser levada ao pé da letra. O HTML é o coadjuvante de toda essa história. O conteúdo é o protagonista. Você trabalha com web porque existe conteúdo, caso contrário, qual seria o motivo para se ter internet?

Concordo com o tio Steve quando ele não aceita suportar Flash em seus aparelhos. O Flash corre para o caminho contrário de todos os objetivos do W3C, da Apple e de todo mundo que luta por uma web mais interoperável. Entenda que também não sou contra Flash. O Flash teve o seu papel. Ajudou muito a web durante um tempo. Felizmente esse tempo já passou.

Já passou o tempo dos sites mais “interativos” (odeio essa palavra quando quero me referir ao Flash), mais animados e etc . O HTML5 juntamente com o CSS3 leva o desenvolvimento para web para um novo patamar. Um patamar onde a informação está lá esperando para ser utilizada quantas vezes for necessária, onde for necessária e por qualquer meio de acesso. Seja esse meio acesso um simples sistema de leitura de tela ou um dispositivo ultrarevolucionário.

Toda aquela história de semântica, código simples e com significado, é regra e precisa ser seguida. HTML mal escrito, com tags indicando significados errôneos para o conteúdo é tão ruim quanto o Flash. Talvez seja até pior. Ter cuidado é necessário, é muito trabalhoso também, sem dúvida, mas é uma das partes mais importantes da produção.

A web só existe por causa do conteúdo. Se a informação desaparece ou se torna difícil de ser acessada, a web perde o sentido. Se você é desenvolvedor web e não trabalha para que essa informação fique cada mais semântica, acessível, abundante, você não é um profissional de internet, vocé qualquer coisa, menos isso.

• Ah, o maravilhoso mundo real
• Apostila sobre HTML5
• Google Apps não suportará mais IE6
• Aonde nos leva a morte do Internet Explorer 6?
• Modelos de conteúdo no HTML5

@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

Pensando nisso, projetamos um evento chamado Codeshow. O Codeshow é um evento num formato novo, em que não há palestras. Você vai assistir à construção de uma aplicação em um dia, a partir do zero, usando ferramentas como Git, HTML5, CSS3, web2py e MongoDB. Iremos separar Programadores e Designers diferentes. Cada sala tratará de assuntos específicos para cada área, mas ambas estarão trabalhando em um mesmo projeto.

Para quem não sabe, essa é a segunda edição do Codeshow. Desta vez iremos reformatar totalmente o Campus Online da Visie. Iremos criar layout para mobiles, utilizar HTML 5 para exibir vídeos e CSS 3 para facilitar a vida. Iremos utilizar Web2Py para levantar o sistema e Git como controle de versão. No final do dia, iremos juntar as salas finalizar o projeto integrando as partes do projeto que Designers e Programadores fizeram.

Será no dia 27 de Maio de 2010, no Espaço Apas na Rua Pio XI, n° 1200, Alto da Lapa – São Paulo – SP, CEP 05060-001.
Custa apenas R$30 e você pode ver mais informações e fazer sua inscrição aqui.

Hoje, temos os seguintes browsers e motores de renderização para se preocupar:

Webkit

Devices com Android instalado ou iPhones e iPod Touch (com Mobile Safari).

Opera Mobile e Opera Mini

O Opera é um dos browsers mais “perfeitos” que existem para mobiles. Ele tem um bom suporte aos Padrões e é quase tão atualizado como Mobile Safari.

Blackberry

O browser utilizado nos Blackberrys são muito bons. Bem melhores que o Internet Explorer, mas piores que o Opera ou Mobile Safari. Digo que eles estão no meio do caminho. Falta ainda suporte a metatags inteligentes, mas já conhecem um bocado de CSS.

Browsers S60 da Nokia

São baseados em Webkit também, como o browser do iPhone e do Android, mas geralmente a versão do webkit é antiga, o que atrapalha um pouco se você quiser fazer algumas coisas mais elaboradas, por exemplo, utilizar media queries ou metatags que nos ajudam a controlar o visual nos aparelhos, como a de Metatag de Viewport.

Internet Explorer Mobile

Esse sim é uma dor de cabeça. Ele não tem bom suporte a CSS e tem bus quando usamos media types. Sem contar que é bastante lerdo e não tem uma séries features que os outros browsers tem, como o Opera. Mesmo assim, há um grupo enorme de aparelhos que vem com Windows Mobile e consequentemente, os usuários mais desavisados utilizam o Internet Explorer Mobile como browser. Felizmente, há uma parte desse grupo que conhece o Opera.
Contudo, com o lançamento do Windows Phone 7 isso tende a mudar um pouco. O Windows Phone 7 utiliza um browser com características e suporte aos padrões referentes a alguma versão do Internet Explorer 7 e 8.

Para facilitar o desenvolvimento para mobiles, eu nivelo a produção desta forma. Por ordem de prioridade:

• Webkit
• Opera Mobile e Opera Mini
• Outros browsers comò do Blackberry, S60 e etc.

De longe o Webkit é hoje o melhor engine para browsers mobiles. Ele é rápido e suporta grande parte das especificações de HTML, CSS e Javascript. Além de estar presente em dispositivos como iPhone, Android e alguns smartphones da Nokia.

Mesmo assim, é preciso testar os sistemas nestes browsers. Você faz isso de duas formas: compra uma dezena de celulares diferentes uns dos outros e testa o produto em cada um deles. Ou por meio de emuladores. O problema de testar com emuladores é que nem todos tem versões para vários sistemas operacionais. O simulador de iPhone só tem para Mac. O de Android tem para Mac e para Windows. O de Blackberry e os da Nokia só tem para Windows. Dificulta bastante a produtividade, mesmo assim, é melhor que ter todos os aparelhos.

Para obter os simuladores, veja abaixo:

iPhone/iPod Touch

O mais fiel de todos os emuladores de mobiles que já vi. Tudo o que você vê na tela, é exatamente o que verá no aparelho. O problema é que só funciona no Mac. Os emuladores alternativos para windows ou outros sistemas não são fiéis. iPhone SDK.

Opera Mobile e Opera Mini

Fizeram uma atualização geral estes últimos tempos. A vantagem é que ele funciona on-line. Nada de fazer download. Emulador Opera.

Blackberry

Só funciona em Windows. A vantagem é que dá para escolher versões anteriores. Mesmo assim, sugiro que sempre nivele pela última versão. Emulador de Blackberry.

Browsers da Nokia

Também só para Windows. Mas costumam ser fiéis com o que vemos nos aparelhos. Nokia Browser Emulator.

Android

Funciona em Macs e Windows. Mas são complicados de usar. Nada que alguns minutos lendo tutoriais e artigos pela internet não resolvam. A grande vantagem é que você consegue customizar o aparelho onde você vai testar o website. Emulador Android.

Se você tem um aparelho com Android, Windows Mobile ou NokiaS60, aconselho também baixar o Skyfire. Um browser muito bom que apareceu para tentar dominar parte do mercado de browsers para mobiles. Ele ataca o mesmo mercado que o Opera está atuando. Tem um bom suporte a Padrões. Vale a pena conferir.

A grande graça de fazer sites para mobiles, é que a grande maioria dos dispositivos realmente confortáveis para acessar a web, e que são os dispositivos que a maioria dos usuários compram porque querem navegar, tem um bom suporte a Padrões Web. Ter conforto para navegar nestes aparelhos é ponto crucial, por isso os fabricantes de sistemas e browsers tentam sempre manter os browsers atualizados com os Padrões.

• HTML5 Diff
• Produtividade: editores e snippets
• Simuladores de Browsers Mobiles
• Quem precisa de versão mobile?
• @font-face – Fonts externas na web

Para termos uma visão melhor, você precisa entender como o W3C funciona.

Padrões e Recomendações

O W3C é um órgão que regulamenta, cria e desenvolve linguagens para publicação de conteúdo na internet. Há uma diferença muito grande entre padrão e recomendação. O W3C não faz padrões, ele recomenda métodos e linguagens. Uma recomendação se torna padrão porque há a aderência da comunidade. Normalmente uma recomendação do W3C vira padrão, porque o W3C está lá para isso, eles trabalham para que seja assim. Entretanto, você pode criar uma linguagem como o HTML, e submeter para a aprovação do W3C ou fazer o “marketing” dela sozinho e torcer para que a comunidade de desenvolvedores e fabricantes de browsers o apóiem. Isso é difícil de fazer, mas não impossível. Aconteceu com o pessoal do WHATWG com o HTML 5. Um grupo de desenvolvedores estavam descontentes com o caminho que o W3C estava tomando em relação ao XHTML 2 e ao HTML. Então resolveram criar um grupo para escrever um novo padrão da linguagem HTML. O W3C se convenceu e adotou o padrão do HTML 5 que eles estavam escrevendo.
Claro que esse grupo foi inspirado por desenvolvedores da Apple, Mozilla e Opera, mas isso foi só um detalhe.

Processo de adoção

O W3C recomenda métodos e linguagens, o mercado acata e vira um padrão. Uma idéia do W3C, assim que nasce, não é já indicada para uso. Para que isso aconteça há um processo de aprovação e testes. Esse processo é dividido por passos:

1. Working Draft
2. Last Call
3. Candidate Recommendation (CR)
4. Proposed Recommendation (PR)
5. W3C Recommendation (REC)

No Working Draft o W3C publica um documento para a comunidade e grupos de membros do W3C. Trate isso como uma ideia rascunhada no papel, onde eles estão perguntando para todos os interessados se é interessante e vale a pena continuar.

No Last Call, o W3C publica os deadlines do projeto, e pede para que todos os grupos de trabalho que de alguma forma estão envolvidos naquele projeto, enviem seus reviews. Há uma fase dentro do Last Call onde o W3C pede para o público, que somos nós, enviar reviews e idéias sobre o assunto.

No Cadidate Recommendation, o W3C já acredita na tecnologia proposta. Ela foi largamente revista por técnicos de dentro e fora do W3C e por todos os grupos de trabalho envolvidos no processo. Nesse ponto, há o começo da experiência de implementação dessa nova tecnologia. Normalmente alguns browsers já implementam essa ideia para que possa ser utilizada por desenvolvedores mundo afora.

Depois dessa fase, entramos na Proposed Recommendation. Nessa fase a recomendação é enviada para o W3C Advisory Committee para que eles aprovem a adoção final que será um novo padrão no mercado. Entenda que nesse meio tempo, há um processo de testes, implementação e desenvolvimento muito criterioso. É o mundo inteiro testando e sugerindo revisões para que a tecnologia seja realmente interessante e inteligente o suficiente para suprir as expectativas.

Quando essa especificação é aprovada, chegamos ao último estágio, onde a idéia inicial vira uma Recomendação. Aí sim os fabricantes de browsers e desenvolvedores poderão utilizar em seus projetos.

Para ficar mais fácil imaginar, tente pensar em um calhamaço de papel. Nesse calhamaço contém um manual de instruções de uso, implementação e detalhes técnicos de como os browsers devem renderizar as instruções, instruções de como os desenvolvedores devem aplicar e escrever o código.
Engraçado que tudo isso gira em torno de ideias escritas, revisadas e reescritas. Claro que eles fazem testes reais em browsers reais durante todo o processo. Por isso há integrantes de todos os browsers nas equipes para representar cada um dos browsers do mercado. É um trabalho conjunto.

Mas e aí, podemos ou não usar?

Durante muito tempo o CSS foi lançado em versões. Hoje temos 2 versões completas (CSS 1 e 2) e uma revisão (CSS 2.1). O time de desenvolvimento do W3C lançavam atualizações fechadas, ou seja, para haver um lançamento oficial, a especificação do CSS teria de ser totalmente desenvolvida, testada e aprovada. O CSS e o HTML passavam inteiros por todos os processos acima. Por isso, os lançamentos de atualizações no HTML e no CSS eram tão demorados.
Hoje, a aprovação do CSS3 está sendo feito por módulos, assim como o HTML5. Há uma equipe para cada uma das principais propriedades do CSS. Por exemplo, há uma equipe que trabalha exclusivamente para o desenvolvimento do background no CSS3. Quando essa equipe acha que já fez um bom avanço, a propriedade de background, separada do resto da linguagem, passa por todo aquele processo que conhecemos no começo do artigo. Isso facilita a adoção dos browsers e dos desenvolvedores.

Por isso que hoje, mais do que nunca, é necessário que os desenvolvedores pratiquem o Graceful Degradation e do Progressive Enhancement. Pode ser que um browser não suporte uma determinada propriedade porque deu foco para outra propriedade. Isso faz com que a taxa de incompatibilidade de browsers aumente. Se levarmos em conta que os browsers estão mais espertos e suas atualizações estão sendo mais breves, isso não será grande problema. Nosso problema atual é exatamente browsers antigos que não recebem mais atualização. O IE6 está deixando de ser esse caso. A taxa de utilização do IE6 já está bem abaixo do IE7. Claro que em alguns casos isso não é motivador porque trata-se de público específico ou cliente interno. Mas a grande maioria do mercado já está sem essa sombra.

Querendo ou não, essa nova forma de o W3C lançar atualizações em módulos, mexe com a dinâmica do mercado. Não apenas os browsers precisam de atualizações rápidas, mas o desenvolvedor também. Cada uma das atualizações lançadas, minimizam o tempo de trabalho, melhoram o processo de desenvolvimento e priorizam a qualidade de código. Outro passo importante para o desenvolvedor é entender que o site que ele escreve, é portável para qualquer tipo de dispositivo. O desenvolvedor é uma espécie de mensageiro. O conteúdo precisa entregue em diversos meios, e é o desenvolvedor que possibilita isso.

Alguns links para que você conheça mais sobre o processo estão abaixo. Isso tudo pode ser encontrado no site do W3C. Basta ler.

• About W3C
• Níveis de aprovação
• Current Work do CSS

• Porque é a web que comanda
• Ah, o maravilhoso mundo real
• Sobre Internet Explorer para Mobile – Breve impressão
• Prepare-se para a Revolução
• Lançado Firefox 3.5

Quando eu utilizava Windows, experimentei dezenas de editores. Foram muitos mesmo. Comecei pelo Notepad, passei pelo Homesite e CoffeeCup. Antes de migrar para Mac, eu estava utilizando EditPlus, mas estava tendo uma quedinha pelo NotePad++. Os dois são muito bons, embora faça um pouco de tempo que o EditPlus não tenha uma atualização.
Quando migrei para Mac, comecei utilizando o BlueFish. Gostei, mas não fui com a cara. A mesma coisa aconteceu com o BBEdit. Foi aí que encontrei o Textmate e depois o Coda. Gostei dos dois. Utilizei durante muito tempo o Coda por conta do seu FTP. Embora o Coda seja completíssimo, o TextMate me ganhou.

Toda essa migração de editores não foi da noite para o dia. Quando eu realmente gostava de um editor, eu o utilizava por muito tempo. Alguns desenvolvedores trocam de editor como trocam de roupa. Não é saudável. Você acaba não conhecendo suas especialidades e limitações. Você não tem tempo para se acostumar com a interface. E isso tudo prejudica sua produtividade. Eu recomendo que você tenha um editor predileto e fique apenas com ele.

Snippets

Eu gostava do Editplus por que ele era um dos únicos editores para Windows que tinham um configurador de Snippets decente (e olha que nem era muito bom). O Textmate tem um gerenciador de snippets invejável e foi por isso que fiquei com ele e não com o Coda.

Na maioria dos editores, os snippets te ajudam com código repetitivo. Eles autocompletam e inserem códigos que são repetitivos para que você não perca tempo redigindo. Mas pára por aí. Você sempre tem que digitar um bocado de código mesmo quando o snippet te ajuda no trabalho pesado. Claro que você tem a possibilidade de configurar e personalizar os seus snippets. Mas muitos dos desenvolvedores não querem parar para criar uma biblioteca de snippets que os ajudem realmente no trabalho pesado do código. É aí que entra o Zen Coding, uma biblioteca completa que lhe permite escrever pouco código e obter o máximo de resultado.

A sintaxe do Zen Coding é baseado em CSS. Você escreve “seletores” de CSS para obter código HTML.
O Zen Coding foi feito pelo Sergey Chikuyonok (em russo). Veja abaixo um vídeo demo de como funciona:

Pra quem não quiser ver o vídeo: a idéia é que uma linha como essa:

div#header > h1.logo > a {logo do site} < ul.menu > li.item-$*5 > a

Retorne este código:

<div id="header">
<h1 class="logo">
        <a></a></h1>
<ul class="menu">
	<li class="item-1">
            <a></a></li>
	<li class="item-2">
            <a></a></li>
	<li class="item-3">
            <a></a></li>
	<li class="item-4">
            <a></a></li>
	<li class="item-5">
            <a></a></li>
</ul>
</div>

Os programadores da Visie me mostraram estes dias um outro projeto criado pelo Rico Sta. Cruz chamado SparkUp. O Sparkup foi inspirado no Zen Coding. Mas tem uma coisa ou outra diferente. Abaixo veja um vídeo introdutório:

Se você é iniciante, entenda que você precisa aprender HTML primeiro. É interessante que você saiba o que cada tag faz, qual sua função e suas características. Aconselho o uso destes snippets apenas para desenvolvedores que já são fluentes em HTML. Não adianta você escrever em Sparkup, mas não saber do que se trata cada tag que foi jogada ali. Isso pode te transformar em um desenvolvedor analfabeto.

O Sparkup tem apenas suporte para Textmate e VIM, por enquanto. Já o Zen Coding tem suporte completo para Aptana, Coda, Espresso, Textmate, editArea, Visual Studio, Komodo Edit/IDE. Sem contar com suporte parcial para os editores TopStyle, Sublime Text, GEdit, Dreamweaver CS4, UltraEdit, BBEdit e Emacs.

Para baixar o Sparkup visite seu projeto no GitHug.
Para baixar o Zen Coding, visite seu projeto no Google Code.

• O que são Media Types do CSS?
• HTML5 Diff
• Ah, o maravilhoso mundo real
• Video tutorial – Implementando HTML
• Formulário Básico em 8 minutos – Tableless form