Esta é minha lista de artigos com a tag "XHTML"

Tags de linguagens de marcação

Por: Henrique Costa PereiraWednesday 30 January 2008 às 22:30

Você saberia rapidamente encontrar as diferenças entre WML e XHTML-MP? Ou então saber quais tags são específicas do XHTML 2 ou do HTML 5? Eu criei a tabela “Tags de linguagens de marcação” com elementos presentes em algumas linguagens de marcação baseado no modelo de Jens Meirt e totalmente em português (tentei pelo menos, ainda falta algumas coisinhas), com o objetivo de servir de guia para iniciantes e de consulta para os desenvolvedores já experientes. Eu resolvi inserir linguagens de marcação específicas para mobile como WML 1.1, XHTML Basic 1.1 e XHTML-MP devido a sua proximidade com as outras linguagens e também porque servirá de guia de estudo da equipe onde eu trabalho.

Ajude a divulgar, critique e mande sugestões. Se encontrar algum erro neste documento entre em contato comigo para atualizarmos. E darei a você os devidos créditos. Sinta-se livre para me enviar outras sugestões. Meu tempo realmente está curto para responder e-mails de todos, mas na medida do possível eu atualizo.

Arquitetura dos padrões web

Por: Henrique Costa PereiraSaturday 27 October 2007 às 16:27

Depois de ter respirado arquitetura de informação um final de semana inteiro ao lado dos melhores arquitetos de informação do Brasil no EBAI , voltei a refletir um conceito antigo que eu já havia escrito a respeito, que é sobre semântica de (X)HTML e sua relação direta com o usuário. Para os não iniciados nos padrões web (web standards) e em semântica de (X)HTML, é através de meta informação que um web site de conteúdo não restrito consegue ser melhor ou pior relacionado com o restante do macro-sistema inteiro de informações que é a própria web. Complicado? Então vamos dividir as idéias em partes menores.

Mecanismos de buscas

A primeira coisa que você precisa saber é que a cada dia, mais os usuários iniciam suas navegações na web em um mecanismo de busca como ponto de partida. Se você não sabe nada sobre alimentação de cães por exemplo, se você nunca teve um cachorro na vida e precisa descobrir como alimentar o cachorrinho que a sua filha acabou de ganhar de presente da tia dela, mesmo sem o seu consentimento, o que você faria primeiro? A resposta mais óbvia seria ir até o Google e procurar por algo como “alimentação de cães”! Você faria isso porque você não freqüenta e não conhece nenhum site de alimentação de cães de cor. E no Google você vai encontrar.

É este o ponto onde eu queria chegar. O Google, o mecanismo de busca mais esperto que existe, tem lá suas próprias regras para avaliar a relevância dos sites que indexa, e essa relação de relevância pode ser melhor elaborada através do esforço de quem cria o site. E é aqui que entra os padrões web, as boas práticas de desenvolvimento que permite criar uma melhor relação entre a informação compartilhada e consumida por usuários e por máquinas (como os mecanismos de busca) com meta-informação, consumida principalmente por máquinas (robôs de buscas) mas que foram criadas para serem eficientes para pessoas!

Encontrabilidade em micro-sistemas e em macro-sistemas

O arquiteto de informação tem o papel de organizar a informação para o usuário no site de forma que ele fique fácil de usar e fácil de encontrar a informação que ele precisa. Em alguns casos o arquiteto de informação participa também da criação de tesauros e ontologias para relacionar a informação dentro de domínios específicos de significado e as relações entre estes. E isso tudo para melhorar a encontrabilidade (findability) da informação em um web site. Isso também é meta informação.

Um exemplo prático é a aplicação disso no Buscapé, o comparador de preços. Para mim e pra você, refrigerador e geladeira refere-se ao mesmo objeto. Para uma máquina elas são “strings” diferentes, são combinações de caracteres diferentes e sem um tesauro por trás de um sistema para tratar essas relações, um usuário que fizer uma busca por “refrigerador” poderia ficar sem ver nenhum resultado mesmo que o site tenha um monte de “geladeiras” a venda. Faça a busca no Buscapé por ambos os termos para ver o resultado.

Encontrabilidade em macro-sistemas

Se um tesauro é meta-informação fundamental para um micro-sistema, ou seja, para encontrar informações dentro de um site limitado apenas a um domínio, é cada vez maior a competição para se encontrar algo em um ambiente macro, em mecanismos de busca. Neste ponto nós saímos da construção de tesauros e passamos para a meta-informação advinda da semântica de (X)HTML, responsável por classificar determinados trechos de informação, por dar significado, para que os mecanismos de busca possam relacionar melhor as informações compartilhadas em diferentes trechos.

Aqui é criada um outro tipo de relação com o usuário, em um contexto manipulado fora do seu domínio, mas seguindo regras que você pode conhecer e seguir. São os padrões web, as boas práticas de desenvolvimento com CSS, (X)HTML, XML, javascript não obstrutivo, acessibilidade, separação em camadas, etc.

Arquitetura da informação e os padrões web

A informação bem organizada e fácil de achar é fundamental para a qualidade de um site. Mas qual poderia ser a sua contribuição com a informação que um usuário procura se ele ainda nem está dentro do site que você cuidadosamente fez testes de usabilidade, criou tesauro junto com uma busca fantástica? Se você se esqueceu da acessibilidade você já perdeu uma parcela dos usuários. Se você colocou aquela intro feita em Flash também já perdeu mais usuários. E se seu site só pode ser visto para quem tem javascript habilitado e foi feito usando AJAX dos pés a cabeça, já perdeu mais um bocado de usuários e inclusive um usuário vip chamado Google, que se você não sabe, é cego, não enxerga seu design web 2.0, apenas a informação compartilhada. Sendo assim você precisa rever se o seu trabalho realmente tem haver com foco no usuário.

No contexto acima, temos um péssimo exemplo de como a preciosa informação contida no site que você fez, ficou inacessível e mal relacionada com um contexto macro. Ou seja, o contexto agora é um usuário que procura a informação que o seu site possui, mas que ele ainda nem sabe que seu site existe, muito menos que você tem a informação que será mais preciosa a ele. E é aqui que entra a arquitetura dos padrões web e em como você pode “classificar” o conteúdo compartilhado com as tags de (X)HTML mais adequadas em uma espécie de vocabulário semântico controlado. Ou seja, o (X)HTML e suas tags é uma meta-linguagem, meta-informação responsável por dar significado ao seu conteúdo, por dizer o que é um título, o que é um parágrafo, o que deve ou não ter ênfase e assim por diante.

Um site de conteúdo aberto, desenvolvido seguindo os padrões web, tem uma relevância maior em mecanismos de buscas simplesmente por causa do código de (X)HTML. Logo o seu site passa a ter uma relevância maior se comparado com sites que não são “adaptados” a este darwinismo tecnológico que os mecanismos de busca criaram nos últimos anos. Os sites mais relevantes e mais adaptados sobrevivem!

Aos arquitetos de informação

Não estou dizendo com este texto que os arquitetos da informação devem sabem criar relacionamentos em banco de dados, ser especialistas em linguagens de marcação, CSS, javascript etc. O que eu quis apontar são outros aspectos relacionados com o tratamento que a informação recebe e que também está intimamente relacionada com o usuário. Você não precisa ser especialista mas precisa pelo menos saber da existência desse tipo de tratamento da informação e ter uma boa noção para poder acompanhar a qualidade final dos projetos dos quais você faz parte. E se você publica ou é editor de conteúdo, há várias dicas que você deveria seguir para assegurar a qualidade de um site, mas isso já é outra história.

Language Tags

Por: Henrique Costa PereiraSunday 26 August 2007 às 16:26

Language tags (também conhecidas como language code) são atributos de XHTML, XML e HTML com o objetivo de indicar a linguagem (idioma) utilizada em um texto/documento ou até mesmo em um trecho de documento. Language tags é um assunto da W3C Internationalization (i18n) Activity, uma força tarefa da W3C específica para assegurar a implementação de tecnologias da web em diferentes linguagens. Existem várias dicas sobre isto entretanto este texto vai tratar especificamente sobre as language tags. Se você pretende trabalhar ou desenvolver aplicações e web sites multilíngua, em mais de um idioma ao mesmo tempo, este texto pode te ajudar.

Language tags, bem como feeds e microformats, enfrentou e/ou enfrentam a mesma situação que nos remete a questão do ovo e da galinha. Quem deve vir primeiro, a implementação por parte dos desenvolvedores ou os dispositivos específicos, implementações, adaptações etc, fabricados pela indústria? Não estou dizendo que language tags seja algo novo, mas é um recurso que ainda não foi explorado em todas as suas possibilidades mesmo que já exista algumas aplicações muito úteis.

Language tags é útil como meta-informação utilizada por mecanismos de buscas ou qualquer outro tipo de usar agent, sistemas de classificação, spelling checkers (corretores ortográficos) sistemas multi-língua, acessibilidade etc. Leitores de tela para deficientes visuais como o Jaws já tem implementado nativamente uma detecção automática de language tags que escolhe um sintetizador de voz adequado para a leitura de um documento.

Não confunda

Antes de mais detalhes é importante ressaltar que language tags não está relacionado com codificação de caracteres (character encodings) que eu já escrevi a respeito aqui em uma série de 5 artigos. Por mais que character encodings também seja um assunto do i18n, encodings trata-se da representação de caracteres usada em um documento e language tags trata-se da meta-informação sobre a linguagem humana (idioma) utilizada em um documento.

Abordagem

Há algumas abordagens diferente para se declarar language tags, entretanto a W3C recomenda uma abordagem simples e fácil de ser implementada. Nada mais é do que declarar atributos específicos na tag HTML (que serve para o documento como um todo) e em trechos específicos quando você compartilha trechos em um idioma diferente.

Boas práticas

Abaixo segue algumas boas práticas simples de serem implementadas e fáceis de serem seguidas. Existem outras além dessas, por isso eu aconselho a leitura deste documento.

Utilize o atributo lang e/ou xml:lang na tag HTML

Trata-se de uma forma simples de declarar qual é o idioma do seu site.

Em HTML:

<html  lang="pt-br">

Em XHTML sendo enviado como text/html:

<html  xml:lang="pt-br" lang="pt-br">

Em XML e XHTML enviado como application/xhtml+xml:

<html xml:lang="pt-br" >

Informe alterações de idiomas em trechos específicos com o atributo lang.

O atributo lang pode ser usado em todos os elementos de HTML com exceção dos elementos applet, base, basefont, br, frame, frameset, iframe, param e script. Se não encontrar um elemento mais apropriado para usar este atributo, você pode utilizar a tag <span>. O objetivo é usá-lo onde você for citar trechos em idioma diferente daquele presente no restante do documento.

Os valores destes atributos, ou seja, as language tags, podem ser consultadas no IANA Language Subtag Registry.

Utilize hreflang com CSS

Trata-se de indicar ao usuário e ao user agent qual o idioma do link que você está referenciando. Como pode ver neste texto, os links que páginas onde o conteúdo é em inglês possui um [en] logo a frente. Veja abaixo como fazer:

<p>There is also a page describing <a href="swedish-doc.html" hreflang="sv">
why a DOCTYPE is useful</a>.</p>

a[hreflang]:after { content: " [" attr(hreflang) "] "; }

Algumas questões em torno do desenvolvimento de sites para dispositivos móveis

Por: Henrique Costa PereiraSunday 20 May 2007 às 21:20

Provavelmente este texto é mais um início de uma série de reflexões naturais que virão com o tempo sobre desenvolvimento de web sites para dispositivos móveis. Ultimamente tenho lido e estudado mais sobre os diferentes caminhos que podem ser tomados para construir sites acessíveis e bem adaptados para celulares e PDA’s. E o mais importante de tudo é como fazer e tomar essas decisões no contexto de HOJE e não amanhã. Este texto então vai colocar mais minhoca na sua cabeça do que te ensinar algo. Mas já é um começo se você ainda não parou para pensar sobre desenvolvimento para dispositivos móveis.

Este assunto acaba desenterrando outro sobre a guerra em prol dos web standards. Se você acredita que a guerra acabou, devo dizer que você está enganado. Se você está se perguntando o que web standards tem a ver com desenvolvimento de sites com versão mobile, você verá a seguir. Mas o fato é que desenvolvimento para dispositivos móveis está crescendo exponencialmente (como a maioria das novidades em desenvolvimento) e as reflexões giram em torno de duas vertentes basicamente:

1º – De um lado temos as idéias relacionadas com o IDEAL do desenvolvimento da web e como as coisas DEVERIAM ser.

2º – De outro temos a realidade de COMO AS COISAS SÃO HOJE e quais as melhores soluções para o presente.

Por mais que as duas vertentes sejam tratadas como antagônicas o objetivo do texto não é fazer você escolher uma delas e sim levantar uma discussão sobre prós e contras. Dividi este texto em 4 principais campos de problemas. Dentro do desenvolvimento para dispositivos móveis nós temos problemas que envolvem a linguagem de marcação a ser utilizada, sobre a melhor solução de design, arquitetura da informação, versões,TLD’s etc.

XHTML-MP, XHTML ou HTML?

A era do WML se foi. Sem comentários sobre isto. A linguagem de marcação proposta para dispositivos móveis atualmente é o XHTML-MP (Extensible Hypertext Markup Language – Mobile Profile), um subset do XHTML inspirado no XHTML Basic 1.0 desenvolvido pela OMA (Open Mobile Alliance) e ouvi dizer que tem a beção da W3C Mobile Web Initiative. Veja aqui uma quadro comparativo entre XHTML-MP e XHTML Basic 1.0. E considerando o fato de ambas serem muito parecidas, elas estão caminhando para serem uma única especificação.

Há “n” lacunas nessa história toda que nos permite conspirar um pouco. E não estou interessado em fazer isso agora. Nos últimos tempos encontramos por aí várias discussões sobre o futuro das linguagens de marcação nas vertentes de XHTML 2 ou HTML 5. As coisas ainda não estão claras sobre o futuro delas e aminha opinião nem importa sobre isso. A indústria (OMA e dotMobi) estão caminhando em direção ao XHTML Basic 1.0 = XHTML-MP que são derivações do XHTML 1.0. Hoje os dispositivos móveis aceitam o HTML 4 e é possível fazer muita coisa legal desde que o HTML seja bem estruturado (ou seja, sem table layouts). Mas a industria parece caminhar em direção ao XHTML e eles não estão se importando muito com retro-compatibilidade. A maioria dos browsers modernos dos celulares e PDA’s já ignoram o WML. Então até que as coisas estejam sólidas essa filosofia de não a retro-compatibilidade vai permanecer.

Segundo as iniciativas do XHTML-MP, o MIME Type deverá ser o application/xhtml+xml com Character Encoding em UTF-8, código bem estruturado sem utilização de tabelas, documentos well-formed, erros de XML parser caso exista erros de sintaxe (se não acredita em mim leia isso tudo neste manual) etc. Se considerarmos as boas práticas da inciativa da W3C e da OMA, o futuro das linguagens de marcação para dispositivos móveis está enraizado no XHTML.

O design

Web designers vão ter um choque quando iniciarem o desenvolvimento para dispositivos móveis. Desenvolver sites para desktop te permite explorar espaços maiores, imagens mais elaboradas, cores, tamanhos, tipologias, formatos, animações, etc. Agora quando você tem um espaço que varia de 120px a 320px, as soluções de design que você tem que encontrar são muito mais limitadas do que aquela que você está acostumado. Veja a imagem abaixo:

Algumas boas práticas incluem tamanhos de fontes que possam ser lidos em uma tela pequena, conteúdo adaptado, etc. AdSense, banners, animações em flash, imagens grandes, etc só atrapalham a experiência do usuário. Até o conjunto de cores para uma versão assim deve ser bem escolhido. Não importa se você vai adaptar o seu site já existente para dispositivos móveis ou se você vai construir uma versão específica, a solução para o seu design deverá ser consciente em relação ao usuário.

A arquitetura da informação

A arquitetura da informação também terá um papel muito importante no desenvolvimento para dispositivos móveis. O trio usuário, contexto e conteúdo tem um desafio completamente diferente de organizar ambientes de informação feitos para celulares e PDA’s. Isso vai incluir escolher entre features, fluxos de navegação simplificados, escolher por relevância entre qual conteúdo é importante e qual deve ser descartado em relação a versão desktop etc. Veja abaixo a diferença entre um ambiente comum de um site para versão desktop e do lado direito uma estrurua ideal para sites construídos especificamente para dispositivos móveis.

Veja agora na imagem abaixo um mapa de site comum e presente em muitos sites institucionais hoje.

Navegar em uma estrutura assim em um celular pode ser muito frustante e dispendioso. Agora veja uma solução criada especificamente para dispositivos móveis do mesmo site:

O principal conselho é: mantenha as coisas simples, com escolhas limitadas e objetivos para se alcançar a informação desejada mais simplificados.

Uma única versão para diferentes dispositivos ou versões separadas?

Esta escolha também reflete as diferenças entre as duas vertentes do desenvolvimento para dispositivos móveis. A primeira vertente diz que temos que ter um único site que se adapte aos diferentes dispositivos. Do outro lado temos os defensores das versões de sites construídos especificamente para dispositivos móveis e que estão adotando a TLD .mobi. Para tomar essas duas decisões hoje, cada uma delas tem o seu custo e o seu contexto.

Essas escolhas vão depender de “n” fatores que estão muito além do escopo deste texto. Se a escolha for manter um único site que se adapte as duas realidades (desktop e dipositivos móveis) a solução pode incluir handheld style sheets e talvez um pouco de content negotiation. Por que isso? Bom, se você prestou atenção nos textos sobre os problemas de design e arquitetura da informação, você sabe que não faz sentido deixar o usuário fazer o download de tudo o que uma versão desktop possui, como por exemplo banners em flash, publicidades etc. Será que os textos que estão presentes não precisariam ser resumidos? E o fluxo de navegação do usuário é adequado para a versão mobile? Qual o tamanho de cada página que será baixada em um celular? Todas essas considerações devem ser levadas em consideração. Existe ainda uma opção de entregar um site sem nenhuma folha de estilos como se tivesse no CSS Naked Day como neste exemplo. Mas ainda assim o conteúdo e o código seria excessivo ignorando o princípio do usuário, conteúdo e contexto! Veja mais reflexões sobre isso nos textos do Cameron Moll.

Do outro lado nós temos as soluções que optaram por desenvolver versões específicas para celulares e PDA’s. Como o Newsvine, CNN, Google, CNet News, Microsoft, Yahoo dentre vários outros. As coisas parecem caminhar em direção as versões de sites criadas exclusivamente para as versões mobile. Pelo menos HOJE. Se isso será salutar ou não para o desenvolvimento para web como um todo, isso já é outra história. Mas se considerarmos os problemas de design, AI e linguagem de marcação, construir versões separadas parece ser o melhor caminho.

TLD .mobi, sim ou não?

A indústria de celulares investe pesado todo ano em tecnologia e ela tem seus próprios interesses é claro. Várias empresas estão organizadas em torno do grupo dotMobi corresponde a TLD (Top Level Domains) .mobi, criada para indicar especificamente os sites compliance com dispositivos móveis. E esta iniciativa tem história e muita grana por trás. O grupo tem como investidos a Nokia, Google, Microsoft, Sansung, TIM, T-Mobile, Visa dentre outros.

Por trás da iniciativa da TLD .mobi é que vemos bem claro as duas vertentes de desenvolvimento para dispositivos móveis. De um lado aqueles que acreditam que os sites não devem ter TLDs diferentes simplesmente por que o dispositivo que o acessa é diferente. Ou seja, o domínio www.exemplo.com não deve ser www.exemplo.mobi só para indicar que ele é adaptado para dispositivos móveis. Dentre os que se opoem a isso está a própria W3C.

Por outro lado temos as mesmas empresas que fazem parte da W3C e fazem também parte do dotMobi e injetaram uma grana boa no grupo. Principalmente as empresas de celulares. Eles tem a própria defesa da necessidade dessa TLD. O fato é que quando muita publicidade e alguns milhões de dólares estão em jogo, vence o cara que fez o cheque com maior número de zeros!

Todas as imagens deste texto foram retiradas do dotMobi Mobile Web Developers Guide.

S5: apresentação em XHTML e CSS

Por: Henrique Costa PereiraWednesday 27 December 2006 às 17:27

Essa é velha, mas depois que me escreveram perguntando como eu faço minhas apresentações quando eu preciso, resolvi escrever a respeito. Não sei o quanto de vocês que aparecem por aqui todo dia sabem, mas o Eric Meyer anos atrás criou o S5, A Simple Standards-Based Slide Show System (sistema de slide show baseado nos padrões). Trata-se de uma união entre entre CSS, XHTML e JavaScript para em um único documento (e não várias páginas de HTML) você consegue ilustrar vários slides diferentes formando uma única apresentação.

As vantagens de utilizar o S5 é que se seu conteúdo for disponibilizado na web, o Google vai indexá-lo como uma página web normal e seu conteúdo não fica obstruído por estar dentro de um power pointer ou outro programa qualquer. Por ser uma apresentação em HTML e CSS, foi feita para ser utilizada em um browser, seja online ou offline. Você pode baixar o que precisa para fazer sua apresentação aqui. É de graça. Enjoy!

Reinventando o HTML: o futuro da linguagem de hypertexto

Por: Henrique Costa PereiraSunday 5 November 2006 às 22:5

Esta semana Tim Berners-Lee deu uma resposta a certos aspectos das recentes discussões sobre os rumos da W3C com o texto Reinventing HTML. Não só colocou panos quentes na discussão como falou sobre os planos futuros da W3C quanto ao HTML. No texto ele mostrou-se como um pacificador e visionário por um lado e um pouco conservador de outro. Enquanto Eric Meyer chamou os avanços de iniciativas como Microformats e WHATWG de “progresso”, Tim nem cita ou considera microformats como parte da “reinvenção do HTML” e apenas referiu-se ao WHATWG como “não tendo um processo ou responsabilidade final específica que mensure a si mesmo” (Trecho original: did not have a process or specific accountability measures itself). Um pouco conservador não?

Este tipo de iniciativas privadas não são uma aberração.

Para quem não sabe o WHATWG (Web Hypertext Application Technology Working Group) é uma iniciativa de Ian Hickson ex-membro da W3C que foca na especificação chamada de Web Applications 1.0 e as vezes referenciado como “HTML 5“. Segundo Hickson, parte dessa especificação já foi submetida a W3C e é de interesse dele e de outros colaborados que os avanços com o HTML 5 trabalhe mais perto com a W3C e não à parte. Ou seja, não se preocupe com iniciativas proprietárias no futuro, eles são os “good guys” da história.

É preciso lembrar que iniciativas como a o do WHATWG e de Microformats são pessoais/privadas mas “politicamente corretas”. Elas surgiram sim do esforço pessoal (em oposição ao esforço institucional como a W3C), mas o objetivo delas não é ser “proprietária” e sim amplamente difundidas bem como as iniciativas da própria W3C. Ou seja, nenhum browser no futuro vai ter que pagar royalties por implementar parsers especificos de microformats, XHTML 2 ou do HTML 5. Estas iniciativas nasceram de pessoas que fizeram parte da W3C, conhecem os processos formais de especificação e possuem interesses em desenvolver um trabalho em conjunto e não particular/privado/proprietário. O que eles não querem é que tecnologias relacionadas as linguagens de marcação não fiquem estagnadas e que avanços sejam feitos, como hoje podemos ver o mar de informações que já são compartilhadas nos micro-formatos.

W3C para o alto e avante?

Recentemente os rumos da W3C esteve em pauta de debate em dezenas de blogs espalhados pelo mundo, inclusive com a participação de membros ativos e antigos como Zeldman, Molly, Meyer, Hickson, Veen, Hoehrmann, Malarkey dentre outros. A principal crítica é a falta de iniciativa da W3C e o avanço de outras iniciativas particulares como WHATWG e Microformats. Até mesmo a Molly Holzschlag que pareceu ser a mais conservadora na discussão reconhece : “One thing everyone agrees on, including me, is that the W3C is becoming very limited in terms of real-world contributions and other groups such as WHAT-WG and microformats.org are truly advancing the web, not the W3C.” (Tradução: Em uma coisa todos concordam, incluindo eu, é que a W3C está se tornando bastante limitada em termos de contribuição ao mundo real e outros grupos como o WHATWG e microformats.org estão progredindo a web, e não a W3C).

O primeiro aspecto que eu achei muito interessante no texto de Berners-Lee foi o fato que mesmo que a tentativa de fazer o mundo mudar para o XML como linguagem de marcação padrão ter falhado, as iniciativas de incrementar o HTML e levá-lo a um mundo bem formado (well-formed) não foram abandonadas. Isso sim é animador. A segunda coisa que me impressionou foi o fato de Tim Berners-lee ter afirmado que haverá avanços tanto no HTML quanto no XHTML e no XHTML2 que não terá nenhum tipo de dependência dos outros working groups. Não me perguntem o porque de tantas frentes de batalha, perguntem ao Tim.

O outro lado do futuro das linguagens de marcação que Berners-Lee sequer citou, é o futuro dos microformats como um dialeto de XHTML, como tem sido chamado. Se considerarmos o presente, a W3C já considera Microformats como um dialeto de XHTML e já o incluiu em sua agenda oficial de GRDDL (proncuncia-se “griddle” ou gruidou) e automaticamente já está associado com Web Semântica (com letras maiúsculas mesmo). Estava demorando. Desde a primeira vez que eu escrevi sobre Microformats aqui a quase um ano atrás e me lembro que não encontrei nada em português, eu arrepiei com as potencialidades. Acredito que Tim Berners-Lee poderia ter sido mais benevolente em seu texto.

Como diz Drewn Maclellan, o seu site pode ser uma API apenas utilizando markup semântica e microformats. A lista de ferramentas e utilizadores de microformats só tem aumentado e seu crescimento se deve a possibilidade real de aplicação no mundo real de hoje. Não é necessário esperar os avanços das linguagens de marcação como Berners-Lee falou para sua utilização. Microformats já é uma realidade de aplicação no atual universo do (X)HTML com plena vista para o futuro. Apenas aprenda a parsear e divirta-se.

Mas e o futuro?

Bom, segundo Tim Berners-Lee, a W3C vai investir tanto no HTML quanto no atual XHTML e ainda no XHTML 2. O WHATWG com toda certeza não vai desaparecer e Microformats já é tão realidade que seu desenvolvimento é irreversível, acredite ( Faça uma busca neste link pela palavra “microformats”). Dá para apostar em uma única linguagem? Com certeza não. Com tantas frentes de batalha referenciadas (e algumas até ignoradas) por Berners-Lee, a única coisa que podemos fazer é esperar e nos divertir.

Esqueça o atributo style. Estilos inline em doctype strict são resquícios do câncer de um passado sem padrões.

Por: Henrique Costa PereiraMonday 28 August 2006 às 13:28

Nesta altura do campeonato você deverá ser um expert para concordar facilmente comigo sem se sentir ofendido. Não se ofenda, não é pessoal, mas utilizar estilos inline é tão racional quanto utilizar a tag <font>. Este é um hábito tão duvidoso quanto substituir <table> por <div>. Este texto é uma reflexão conceitual do significado do atributo style e não um tratado de condenação.

Para entender o que eu quero dizer você deve ter que percorrer determinado caminho se ainda não o fez. Você precisa entender o âmago dos padrões web e saber muito bem o que é desenvolvimento em camadas, onde conteúdo, apresentação e comportamento ficam separados um do outro. Um doctype strict diz sobre uma página de que a sintaxe que ali se encontra deve ser 100% estrita (strict) da própria linguagem. É o que um doctype strict diz. E isso supõe também nas entrelinhas de que todo o conteúdo deve ser separado da apresentação. Certo?

Atributo style em doctype Strict é pérola em focinho de porco

Você precisa saber as diferenças conceituais entre um doctype strict e um transitional. O doctype transitional foi feito para ser "flexível" a aceitação de markup obsoleta e o strict não. Na história dos padrões, uma sintaxe estrita deve utilizar um doctype strict e deve separar completamente o conteúdo da apresentação. Um doctype transitional nem tanto, ele é mais libertino. Com um doctype transitional você está dizendo para qualquer user agent que você não utiliza uma markup estrita e que algumas regras poderão ser quebradas quando você achar necessário. Saber quando fazer essas diferenças na prática é o básico do desenvolvimento seguindo os padrões. Este é o ideal dos padrões, é como as coisas "devem ser" e não necessariamente como são.

A existência do atributo style na especificação do XHTML Modularization mesmo que indicado como deprecated é tão contraditória quanto a permissão de tags com propósitos apresentacionais. Não fazem nenhum sentido.

Vale lembrar que um elemento ou atributo indicado como “deprecated” (desaprovado) é diferente de um elemento “obsolete” (obsoleto), ou seja, um elemento deprecated ainda faz parte da linguagem mas provavelmente não terá nenhum suporte em versões futuras da linguagem, onde se tornará obsoleto. O que a especificação da W3C diz sobre o atributo style no XHTML, mesmo com doctype strict, é que ele ainda faz parte da sintaxe estrita da linguagem.

Como eu já escrevi antes, um doctype transitional só deve ser utilizado quando for necessário dar suporte a elementos e atributos com propósitos apresentacionais. A W3C diz isso:

This is HTML 4.01 Strict DTD, which excludes the presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

Mas meu conselho é: Não use o atributo style em um doctype strict mesmo que a documentação permita isso como parte da linguagem estrita. Bom, então talvez você esteja se perguntando o seguinte: "Você está se opondo a utilização do atributo style em elementos de uma página que possui um doctype de XHTML strict mesmo que a documentação da W3C diz que ele é sim permitido?" A resposta é "sim", eu estou me opondo a isso.

Retro-compatibilidade?

Para ser sincero eu não sei a razão exata do porque isso foi permitido nesta versão do XHTML mas eu tenho uma suposição. Chama-se retro-compatibilidade com versões passadas das linguagens de marcação. Lembre-se que neste ponto estou dando a minha opinião e o que eu suponho ser. Talvez o pessoal da W3C acredita que a web não estivesse preparada (o XHTML é datado por volta do ano 2000) o suficiente para separar a apresentação do conteúdo de forma completa, e para minimizar a utilização de markup com propósitos apresentacionais, eles pelo menos permitem que você utilize atributos com estes propósitos em um doctype que supõe ser strict. Bem controverso isso não?

Retro-compatibilidade tem lá suas facetas. Só quem nunca trabalhou em migração de grandes sistemas com linguagem obsoleta e antiga para uma mais moderna não sabe o quanto é difícil e penoso, e que algumas decisões podem até comprometer um projeto. De qualquer modo não quero lançar meus julgamentos pessoais sobre as razões que a W3C encontrou para manter o atributo style como parte da sintaxe estrita do XHTML. A única coisa que sei é que o atributo style tem objetivos apresentacionais e não deve ser utilizado em uma linguagem estrita.

Qual a diferença?

Seguindo o exemplo de Emil Stenström qual a diferença entre os dois exemplos abaixo na sua opinião?

<body bgcolor="#1B486F">
<center>

<body style="background:#1B486F">
<div style="text-align: center">

Se sua resposta for “nenhuma, não há nenhum diferença entre os exemplos acima”, você está certo. Ambos os exemplos não prezam pela separação entre conteúdo e apresentação.

Desenvolvimento em camadas é separação

Seguir os padrões web é separar conteúdo da apresentação. Os dois exemplos acima não diferem em exatamente nada conceitualmente, somente em sintaxe, ao deixar style inline na markup. Mesmo que seja dentro de um include processado no servidor e que basta você alterar em um único lugar que esta alteração irá valer para o site inteiro. Não interessa, estilos inline trata-se de apresentação e não de conteúdo.

Lembre-se que estou tratando neste texto do ideal do que deve ser seguir os padrões web à risca. Você faz suas escolhas diariamente ao desenvolver para web baseado em cada contexto, por isso a avaliação de que você segue ou não é sua. Você escolhe se quer ou não seguir os padrões e o quanto deles você quer seguir. O próprio Roger Johansson admite utilizar estilos inline em determinado contexto ao mesmo tempo em que ele concorda que não se deve utilizá-lo. Leia você o texto dele sobre este mesmo assunto tratado aqui.

Se você precisa utilizar estilos inline (não estou te julgando, você sabe o que é melhor), utilize um doctype transitional. Enquanto a palavra “padrão” significar “padrão”, isso é o que eu acredito ser o certo e o que deve ser feito. Mesmo que o validador não acuse o erro. Se não tem certeza de que a sintaxe será sempre estrita, não utilize um doctype strict. Estas são as regras do jogo.