O que desejávamos

Acho que estamos a caminho de problemas, embora não possa dizer com certeza. Problemas - problemas eu sei . A rampa de acesso para isso, no entanto; Só ouvi falar disso. Eu só faço isso há dez anos. Perdi toda a preparação da última vez. O que posso dizer com certeza - o que sei por experiência - é que nunca tive um desejo feito com raiva sem me arrepender.

Dez anos (não me importo de dizer) é muito tempo. Quando eu me esforcei para entrar em um estágio de web design, o bom e velho Internet Explorer já era motivo de chacota.

“Se você perceber que uma parte do seu conteúdo aparece e desaparece, e as seções da página ficam apenas meio desenhadas, são boas indicações de que um elemento requer um layout. [...] Uma correção de hasLayout envolve nada mais do que declarar uma propriedade CSS que faz com que um elemento ganhe um layout, quando normalmente não teria um layout por padrão.”

— A propriedade hasLayout do Internet Explorer

Eu odiava IE. Eu sinto que posso lidar com isso agora. Eu tentei não; Eu realmente, sinceramente. Eu diria às pessoas que era divertido apoiar, se você pode acreditar.

Como todos os outros navegadores ficaram cada vez mais fáceis de lidar, tentei me convencer de que pelo menos ainda havia um desafio para o antigo IE peculiar. Isso até se tornou um motivo de orgulho: eu tinha ficado tão bom em consertar problemas obscuros do IE que aprendi a evitá-los durante o curso do meu desenvolvimento diário, não deixando nada (bem, menos) a temer quando o grande “aberto”. no IE e veja o que quebrou”.

É divertido, de certa forma. Divertido . Essa foi a mentira que eu disse a mim mesma.

 /* Fixes #2588: When Windows Phone 7.5 (Mango) tries to calculate a numeric opacity for a select (including “inherit”) without explicitly specifying an opacity on the parent to give it context, a bug appears where clicking elsewhere on the page after opening the select will open the select again. */

— fonte jQuery Mobile

Eu odiei isso. Eu odiava o IE, em cada uma de suas encarnações. Eu odiava tanto quanto todo mundo odiava.

“O Internet Explorer 6 tem um bug intrigante envolvendo vários elementos flutuantes; caracteres de texto do último dos elementos flutuantes às vezes são duplicados abaixo do último flutuante. ... A causa direta nada mais é do que comentários HTML comuns, como <!-- end left column --> , intercalados entre floats que vêm em sequência.”

— Bug de caracteres duplicados do Explorer 6

Um desperdício do meu maldito tempo é o que era. Todas aquelas horas que passei debruçado sobre uma máquina virtual ruim - recarregar, esperar, lançar uma correção sem sentido em um bug sem sentido, recarregar, travar , abrir o IE novamente, esperar, verificar novamente se o cache não era um fator, recarregar, esperar, e repita. Eu poderia ter feito muito mais com meu tempo – eu poderia ter aprendido muito mais.

Eu tinha certeza de que isso não apenas impedia meu trabalho, e não apenas impedia a web, mas também a mim , como desenvolvedor. Nesse segundo ponto, acho que não estava totalmente errado - todo o conhecimento obscuro de bugs do navegador IE 6-7 que acumulei é inútil agora. Tudo o que tenho para mostrar é uma hesitação involuntária com a palavra “filtro”, uma preferência inescrutável por padding sobre margin e um medo profundo, mas amplamente infundado, de z-index .Em

“… espaço em branco extra faz com que os estilos errados sejam escolhidos se o nome da classe real for uma substring (ou superstring) de algum outro nome de classe.”

— Erro de análise de espaço em branco do IE5/Mac

Eu queria que isso fosse embora. Desinstalado por um vírus inteligente e difundido, banido por lei, a Microsoft finalmente decidiu cortar as perdas de seu mecanismo de renderização de má qualidade e mudar para o mecanismo de renderização do Firefox, Gecko – tanto faz – apenas fazê-lo desaparecer . Mas não. A web continuou evoluindo e nós, desenvolvedores, avançamos, barcos contra a corrente, trazidos incessantemente de volta ao passado.

O Chrome surgiu, o Firefox continuou melhorando, novos recursos continuaram sendo lançados, as possibilidades emocionantes e infinitas apresentadas pelo advento do web design responsivo se espalharam antes de nós e também (rápido de lado) lembre-se de que você terá apenas alguns dias para fazer tudo funcionar mais ou menos no IE antigo, então não se empolgue demais .Em

“SE você estiver usando o IE8, E estiver usando a abordagem de numeração de lista ordenada CSS descrita acima, E o HTML que tem as classes que usam os atributos CSS counter-reset counter-increment está OCULTO quando a página é carregada, ENTÃO sempre que estiver oculto HTML é exibido, TODOS os números automáticos serão ZERO, MAS SOMENTE SE O CSS :hover PSEUDO-CLASS FOR USADO NESSA PÁGINA!”

— O Bug do IE8 “hover”: O Bug do IE mais incrível de todos os tempos?

É difícil imaginar esse tipo de frustração hoje em dia, pelo menos para nós, relativamente mais velhos. Para não dizer que não há uma quantidade incrível de trabalho envolvido em ajustar as coisas entre navegadores hoje em dia também – eu sei muito bem que existe. Mas é difícil não sentir a pontada ocasional de "na minha época, tudo o que tínhamos eram floats, e deixe-me falar sobre o bug de margem dupla do IE ", quando você ouve sobre uma pequena diferença em como o CSS Grid funciona em um navegador para outro.

Eu estava errado; Eu quero ser claro nesse ponto. Não é errado estar frustrado. Eu não acho que ninguém deve ser culpado por estar frustrado com esses bugs antigos do navegador, assim como eu não acho que ninguém deve ser culpado por sua frustração com qualquer aspecto do desenvolvimento web agora . Não, eu estava errado na conclusão que a raiva me trouxe: o desejo de ver Trident queimado no chão e a terra onde uma vez estava salgada.

Suspeito que apenas uma coisa dramaticamente irônica surge dessa terra salgada: essas mesmas frustrações, nascidas de novo, para uma nova geração de desenvolvedores web. Quando comecei minha carreira, poucos anos após a guerra dos navegadores, essas sementes já tinham se enraizado. Porque, por um tempo - um tempo antes do meu - nós, desenvolvedores da web, amaldiçoamos a Netscape da mesma maneira. O navegador mais fraco, com bugs e indiscutivelmente pior . Mas o Internet Explorer - os desenvolvedores adoraram esse navegador. E eles desejavam que esses outros navegadores - os navegadores ruins - simplesmente desaparecessem : desinstalados por um vírus inteligente e difundido, banido por lei, a Netscape finalmente decidiu cortar as perdas de seu mecanismo de renderização de má qualidade e mudar para o mecanismo de renderização do IE, Trident - tanto faz - apenas fazê-lo ir embora . Esses bugs inescrutáveis ​​do Internet Explorer não aconteceram por coincidência ou negligência. Eles surgiram porque o Internet Explorer havia vencido e nós adoramos a vitória.

Veja, nossa frustração e nossa raiva mentiram para nós, como costumam fazer. Eles nos disseram que dar suporte a esses outros navegadores piores não apenas restringiu nosso trabalho, e não apenas reteve a web, mas nos reteve, como desenvolvedores. Foi um desperdício do nosso maldito tempo. Então, dissemos a nós mesmos que não era apenas para o nosso próprio bem, mas para o bem de toda a web .

Nós pesamos o IE um pouco mais. Demos um pouco mais de voz em nossas decisões. E assim, segurando tantas fichas, a Microsoft jogou suas cartas de acordo – quem poderia culpá-los? Todos construíram sites para eles primeiro, e os outros depois. A palavra deles não era lei , mas certamente era mais do que sugestão . Claro, eles se desviaram dos padrões da web aqui e ali (só um pouco), mas afinal, algo implementado pelo The Biggest Browser não era uma espécie de padrão de fato ? Além disso, suportar o navegador melhor, mais rápido e mais fácil estava prestando um serviço à própria web! Junto com a Microsoft, estávamos impulsionando a web! Todos ganham.

O mecanismo de renderização que alimenta o navegador Edge da Microsoft hoje – EdgeHTML – é uma bifurcação do antigo Trident. É um garfo de Trident despojado e amplamente aprimorado, com certeza, mas não é, digamos, universalmente julgado por seu próprio mérito. A equipe do EdgeHTML sempre trabalhou com algumas desvantagens: a primeira era técnica, pois levava muito tempo e esforço para acompanhar o Safari, Firefox e Chrome. A segunda foi emocional. Éramos nós – você e eu – cansados ​​de anos de Internet Explorer, olhando para um alegre “e” azul minúsculo com desdém frio.

Algumas semanas atrás, a equipe do Edge anunciou que em breve abandonaria o EdgeHTML em favor do Blink, o mecanismo de renderização que alimenta o Chrome. Com essa mudança, as últimas brasas restantes do Trident serão apagadas para sempre. O desejo que eu compartilhei com tantos finalmente será concedido. Ironicamente cronometrado - como se vê - o EdgeHTML estava se tornando um mecanismo de renderização bastante sólido.

Blink é um projeto de código aberto liderado e governado pelo Google. Ele alimenta o Chrome e o Opera, o último dos quais abandonou seu mecanismo de renderização caseiro há alguns anos.

Por uma margem esmagadora, o Blink é (e será cada vez mais) a forma como a web é experimentada em todo o mundo. O Blink é rápido, estável, repleto de recursos modernos e — em comparação com o desenvolvimento do EdgeHTML ainda em evolução — indolor .

Pode ter acontecido tarde demais para nos salvar desses antigos bugs do IE, mas nosso trabalho será mais fácil agora que há um mecanismo de renderização a menos para suportar. Você e eu perderemos um pouco mais de nossa carga coletiva de “mas funciona entre navegadores”. Nossos projetos serão mais tranquilos e a web perderá um pouco mais do que antes a impedia.

Como administradores do mecanismo que alimenta grande parte da web, bem, a palavra do Google não será lei , mas certamente mais do que sugestão . E talvez ao longo dos próximos anos, eles se desviem dos padrões da web aqui e ali (intencionalmente ou acidentalmente) das maneiras mais ínfimas. Mas afinal, algo implementado pelo The Biggest Browser não é uma espécie de padrão de fato? Além disso, como você poderia argumentar? Afinal, favorecer o navegador melhor, mais rápido e mais poderoso é prestar um serviço à própria web. Junto com o Google, vamos impulsionar a web. Todos vão ganhar.

Isto é, desde que pequenos desvios de padrões e pequenos bugs irritantes não aumentem com o tempo – graças às forças gêmeas da entropia e da complacência. A menos que as decisões que tomamos para o bem da web (de mãos dadas com uma empresa de publicidade notoriamente hostil à privacidade) comecem a parecer um pouco mais sombrias e um novo bicho-papão comece a tomar forma em nossas mentes - a menos que encontremos que nossos velhos medos e frustrações aumentaram novamente (como uma fênix que renderiza algumas centenas de pixels de onde deveria e pisca de uma maneira estranha quando você rola).

Não é preciso muita imaginação para ver mecanismos de renderização mais novos e empolgantes aparecendo nos próximos anos. É preciso pouca imaginação para vê-los falhando devido à falta de suporte, pois favorecemos “o navegador que todo mundo usa” – primeiro por escolha e depois talvez em serviço relutante de “resultado”.

Novamente, porém, eu não sei. Eu nunca vi isso acontecer com um mecanismo de renderização. Acabei de ouvir toda a história, e só sei em primeira mão como termina. Conheço o final da dor de velhas cicatrizes psíquicas; de um recuo involuntário em alguns pedaços de código e memória muscular que me compele a evitar outros. Eu sei disso pelas piadas nos discursos da conferência que sempre pareciam um pouco cansadas, mas ainda ressoavam do mesmo jeito de uma maneira que eu não me permitia admitir e ainda falavam de um desejo secreto que eu guardava no fundo do meu coração. Um desejo amargo e odioso.

Mas ei, ouça. Não mais. Agora, quero dizer - eu nunca faria. Eu realmente amo um bom bug do motor de renderização, agora. Eu faço.

“Transformações CSS 3D com perspective() são renderizadas de dentro para fora.”

— bugs.chromium.org

Quero dizer, isso é realmente um bug divertido, certo? Tipo, divertido de certa forma . Sabe?

É divertido.

Vai ser divertido .