Virar o bico ao prego

No meio das confusões criadas pela evolução soluçante dos browsers (principalmente o IE) na sua relação com os standards é, de facto, desesperante ver a frequência com que os sites deixam de funcionar correctamente. A malha complexa de acertos, contra-acertos, desvios e hacks que se vão fazendo e desfazendo para adaptar o código dos sites aos humores de versões sucessivas que ora se aproximam ora se afastam da definição dos standards, fez-nos chegar a um ponto em que qualquer movimento obriga a intensos exercícios de reescrita.

A pensar nisso, aparentemente, apresenta-se agora uma nova abordagem à evolução de standards e browsers que é pouco mais do que virar o bico ao prego: a partir do IE8, propõe-se que abandonemos a estratégia do browser sniffing, em que o programador escreve variantes do código para diferentes browsers, versões e plataformas, servidas em função da sua (difícil e, por vezes, ineficaz) detecção, para deixarmos que sejam os novos browsers a detectarem a(s) versão(ões) testada(s) na fase de desenvolvimento para adaptarem o render da página de acordo com a intenção primária do programador.

A mudança sugerida é radical e difícil de digerir. Acompanhei com gosto a reflexão do Eric Meyer a esse respeito e dou por mim a pensar que o maior risco que se corre quando se vira o bico ao prego é não saber exactamente quem é que está a segurar o martelo.

Essa é uma questão que é abordada ao de leve nesta última edição da A List Apart, mas não fica muito clara nos artigos quer do Aaron Gustafson, quer do Eric Meyer, mas usando as palavras deste último:

For one thing, “browser sniffing” at present means “writing code to check what browser is being used and make adjustments to the markup/CSS/JS/server response/whatever accordingly.” Version targeting reverses that completely, making it “the browser checking the page to see when it was developed and making adjustments to its behavior accordingly.” In other words, version targeting frees web developers from sniffing and places the onus on browser developers instead.
[isto é virar o bico ao prego]

That’s not a change to be lightly dismissed. Browser implementors, for all they frustrate us with (often justified) pleas of limited resources, still command far more resources and expertise in regression testing than any of us can muster. Furthermore, browser developers have a far more vested interest in making sure the version targeting works as promised and doesn’t break old sites than site authors do in updating their old sites to work in new browsers. [isto é reconhecer que quem segura o martelo é o outro e ter fé que ao outro não lhe interessa acertar-nos nos dedos]

(…)
Besides which, we’ve written enough scripts and hacks to make our pages adjust to browsers. Isn’t it about time browsers started adjusting to our pages? [isto é reconhecer que se está cansado]

(…)
The biggest concern is fidelity. Will the backwards-compatible code for IE8 always act exactly like IE8 did, or will there be subtle changes that still break old sites? Might there even be, dare we mention it, new bugs that affect the backwards compatibility of future browsers? After all, the door swings both ways: vendors might get lax about their backward-looking code just as developers might get lax about their forward-looking code. Talk about irony. [isto é reconhecer que pode continuar a correr muito mal]

4 pensamentos em “Virar o bico ao prego

  1. Exactamente. É por isto que está a gerar tanta confusão.

    Já viste o artigo do Jeremy Keith sobre isto? Caso o IE8 se depare com um site que não escolha o motor de render, este, carrega a página como se do IE7 se tratasse!!! Ou seja, para beneficiar das inovações do IE8 (generated content, table-display, etc) é preciso que o developer faça exactamente isso, browser sniffing.

    E querem eles que os outros browsers façam o mesmo… tecnicamente é algo bem complexo. Leva inevitavelmente à questão… e se mais tarde se se descobrir uma falha de segurança (XSS, etc) no motor do IE7? Não será corrigido no que vai com o IE8? E será que as alterações não quebram alguns sites? Enfim… é criar confusão onde não a deve existir. É passar um atestado de estupidez à W3C quando o papel dos browsers é tentar seguir a uniformização.

    É, no fundo, como tu dizes e eu o disse nos meus €0.02, baixar os braços e facilitar o trabalho aos molengões.

    Adorava que isto não fosse mais que uma publicity stunt para por o pessoal a falar dos standards e das dificuldades inerentes à construção dos browsers. Mas não é. :(

  2. Não li o artigo do Jeremy Keith, mas li a “resposta” do Jeffrey Zeldman.
    Pessoalmente, para lá dos detalhes que me escapam, estou ainda bastante confuso, mas por muito que me preocupe a ideia de passar esta responsabilidade para os browsers (começando pelo da Microsoft) e confiar neles, dada a situação em que estamos, percebo a visão “pragmática” do Jeffrey Zeldman e do Eric Meyer.
    No fundo, estamos num estranho ponto de “viragem”, em que alguns browsers deram saltos substanciais para se aproximarem dos standards, em que mesmo os programadores que nada sabem de standards(nem querem saber) têm definições de DOCTYPE no topo dos documentos porque os copiam doutro sítio ou porque os editores WYSIWYG pôem lá o código sem perguntar nada a ninguém e, apesar de toda esta “aparente” aproximação aos standards, está tudo “segurado por arames” dada a quantidade de estratégias rocambolescas e remendos que usamos para garantir a compatibilidade para o passado.
    Como diz o Eric Meyer, daqui para a frente, a solução teria mesmo que ser outra e, como diz o Jeffrey Zeldman, qualquer que ela fosse tinha que ser negociada com a Microsoft porque, por muito que nos custe, o IE continua a ser omnipresente.
    Sinceramente não me parece ser um “publicity stunt”, como dizes. É apenas mais uma afirmação de pragmatismo: apoiar os standards, agora, passa por continuar a investir no seu desenvolvimento e na sua propagação, ao mesmo tempo que se gere o impacto que a sua evolução e as sucessivas aproximações dos browsers causam na web “real”, que se está nas tintas para os standards e que só não quer que o IE8 não rebente com a web, como o IE7.
    Para quem conhece e usa os standards, a vida segue, sem sobressaltos de maior. Para a vasta maioria de programadores web que se estão nas tintas e que até culpam a malta dos standards quando a nova versão do browser que usam deixa de apresentar o código martelado deles em condições, há uma nova segurança.

    De certa forma, a “luta” era (e deve continuar a ser) com quem produz browsers ou aplicações que fazem output ou interpretação destes códigos. Não podemos, agora que essa “luta” está quase ganha e que se preparam tréguas, iniciar uma “luta intestina” para obrigar todos os web designers, programadores web e outros “curiosos” a produzirem código standard. Esses “molengões” não vão mudar nem desaparecer… é o que a minha experiência me diz.

    O que mais me preocupa nestes sistemas, ainda assim, é a questão do funcionamento cross-browser. Com “version detecting” a ssério, deveria ser possível ao programador definir que o seu target é FF3 e o IE35 teria que emular o render engine do FF3. Mas isso não vai acontecer pois não?

  3. O problema disto é exactamente o que foi dito no comentário anterior:

    Caso o IE8 se depare com um site que não escolha o motor de render, este, carrega a página como se do IE7 se tratasse

    Um web developer deve escrever “correctamente”, segundo os standards, e não uma página para ser bem vista no IE7. Browser sniffing nunca deverá ser “o método”… apenas um “work around” para situações muito específicas.

Deixar uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

Pode usar estas etiquetas HTML e atributos: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>