Smashing Podcast Episódio 8 com Stephanie Stimac e Aaron Gustafson: O que há de novo no Microsoft Edge?

Neste episódio do Smashing Podcast, estou conversando com Aaron Gustafson e Stephanie Stimac, da Microsoft, para saber mais sobre a nova versão do Microsoft Edge e como ela está afetando os desenvolvedores da Web em todo o mundo, bem como seu impacto na Web.

Mostrar notas

• O site Web que queremos e o Twitter
• Stephanie e Aaron no Twitter

Atualização semanal

• “O mítico homem-mês mítico”,
  por John Foreman
• “Recriando o botão Arduino usando SVG e <lit-element>,”
  por Uri Shaked
• “Como passar dados entre componentes no Vue.js,”
  por Matt Maribojoc
• “Um guia completo para WordPress Multisite,”
  por Manish Dudharejia
• “Como capacitar as equipes de design medindo o valor”,
  por Dave Cunningham

Transcrição

Drew: Então, sabemos que ambos são da Microsoft, ambos se dedicam a tornar a web melhor para todos nós, mas você sabia que o mais recente encontro deles na Web We Want foi hospedado em um balão de ar quente fora da atmosfera da Terra? antes de saltar de volta à terra no estilo de Felix Baumgartner.

Drew: Meus Smashing Friends, por favor, recebam Stephanie Stimac e Aaron Gustafson.

Drew: Olá Stephanie, olá Aaron, tudo bem?

Aaron Gustafson: Estou arrasando.

Stephanie Stimac: Eu também estou arrasando.

Drew: Eu queria falar com você hoje sobre alguns desenvolvimentos muito interessantes que estão acontecendo com o navegador Microsoft Edge. Acho que a maioria de nós saberá que o Edge é tradicionalmente o navegador do Windows 10 que substituiu o muito amado Internet Explorer. Provavelmente a primeira coisa que devemos notar é que o Edge não é mais exclusivo do Windows 10, não é?

Arão: Correto.

Stephanie: Você pode encontrar o Edge no Windows 10 e Mac OS. E não tenho certeza se ainda está disponível no Windows Seven.

Aaron: Sim, acredito que esteja disponível no Windows Seven e no Windows Eight agora também. E também há os clientes móveis para iOS e Android.

Drew: Praticamente todas as plataformas modernas.

Stephanie: Sim.

Aaron: Exceto para Linux, espero que em breve.

Drew: Assim, até mesmo os usuários de desktop Linux podem entrar em ação.

Aaron: Eventualmente, essa é a esperança.

Dre: Fantástico. Então, até onde eu entendo, e me corrija se eu estiver errado aqui, mas o Edge era tecnicamente uma continuação da base de código do Internet Explorer, isso é justo dizer?

Aaron: Sim, quando o Edge começou, era basicamente uma espécie de arrancar todas as coisas que percebemos que estavam meio atrasadas, coisas que eram proprietárias e coisas assim. Todos os antigos objetos auxiliares do navegador e coisas do ActiveX e coisas assim. Então foi massivamente destruído. Foi uma espécie de chance para a equipe realmente se livrar de muita bagagem do legado e se concentrar nas coisas padrão. E assim foi uma continuação do antigo mecanismo Triton, mas meio que refatorado e transformado no mecanismo Edge HTML.

Drew: Então foi como uma grande reforma de casa dentro da base de código.

Aaron: Sim, leve para os garanhões.

Drew: Então, acho que a maior mudança sobre a qual quero falar com a versão mais recente do Edge é que ainda mais desse tipo de entranhas antigas foram arrancadas e substituídas. E há um novo mecanismo de renderização que foi instalado. Agora estou um pouco consciente do uso de jargão e pessoas que talvez não estejam tão familiarizadas com o funcionamento dos navegadores podem não estar completamente satisfeitas com o que queremos dizer com um mecanismo de renderização. Acho que alguns de nós que já trabalhamos na web há muito tempo já pegaram essa informação, mesmo que não estejamos trabalhando diretamente com o interior dos navegadores. Mas alguém que talvez seja mais novo no desenvolvimento web pode não entender, o que queremos dizer com um mecanismo de renderização. Então, o que é um mecanismo de renderização dentro de um navegador? E quais bits não são um mecanismo de renderização?

Aaron: Bem, há um monte de partes diferentes em um navegador. O mecanismo de renderização é o que normalmente pensamos quando falamos sobre o que está sendo realmente pintado na tela e a camada interativa das coisas. E assim, no mundo Chromium, esse é o mecanismo de renderização Blink.

Aaron: E depois há o mecanismo de renderização WebKit, que é o que executa o Safari. E isso foi baseado no mecanismo de renderização KHTML, que rodava o Konquerer nos primeiros dias.

Aaron: O mecanismo de renderização Trident que mencionei antes era o do Internet Explorer para Windows. Tantek Celik fez o mecanismo de renderização Tasman como parte da equipe que estava trabalhando no IE5 para Mac.

Aaron: Então, existem todos esses mecanismos de renderização diferentes por aí. E, na verdade, acho que havia um novo sobre o qual Peter Paul Cox estava falando chamado Flow. Isso é como um mecanismo de renderização multi-thread baseado em SVG ou algo assim. E há um futuro navegador para isso que foi projetado para decodificadores, dispositivos realmente de baixa potência.

Aaron: Mas sim, os motores de renderização, pegando todas as suas informações e pintando na tela. E então você também tem seu tipo de mecanismo JavaScript subjacente. Então v8 no caso do tipo de pilha Chromium. E há um monte de diferentes para isso também.

Drew: Então, quando dizemos que o antigo mecanismo de renderização Trident, que veio do IE e estava no Edge, foi substituído. Na verdade, estamos falando sobre a parte que pinta coisas na tela e também coisas associadas, como o mecanismo JavaScript. Isto é Justo?

Aaron: Sim, no caso da nova versão do Edge, basicamente nenhum dos fundamentos do antigo Edge está lá. O projeto Chromium é um projeto de código aberto que executa o Chrome e o Brave e muitos outros, Opera e outros. E esse projeto inclui o mecanismo de renderização, inclui o mecanismo JavaScript, inclui toda a interface do usuário. Também inclui o processo de construção e todo esse tipo de coisa para realmente criar o navegador.

Aaron: E então basicamente temos o projeto Chromium, que se tornou a base para o novo Edge. E então tivemos que passar pelo processo de torná-lo parecido com o Edge e adicionar a funcionalidade que precisávamos em termos de sincronização, usando contas da Microsoft, todo esse tipo de coisa.

Aaron: Então o novo Edge não compartilha nenhuma linhagem no sentido tradicional com o antigo Edge, que era o Edge HTML, que herdou do Trident e assim por diante. E você pode continuar indo até o Mosaic para a maioria deles.

Aaron: Mas sim, então agora o novo Edge é o Chromium, que é baseado no WebKit anterior, que é baseado em KHTML e assim por diante. Portanto, é uma linhagem completamente diferente da anterior.

Drew: Então, quero dizer, é uma grande mudança, não é, para a Microsoft não ter mais um navegador originado em seu próprio código. Mas na verdade está pegando um projeto de código aberto e criando seu próprio navegador a partir disso. O que eu acho que é semelhante ao que a Apple fez no passado com o WebKit. O que, foi KHTML eles...?

Aaron: Sim, o Konqueror era o... com um K.

Drew: Sim, Konquerer, então eles pegaram aquele projeto de código aberto e isso se tornou o Safari. E então a Microsoft está fazendo algo semelhante com o projeto Chromium e fez o Edge dele?

Arão: Correto.

Drew: Se eu estiver sentado na frente do Edge como desenvolvedor web, o que estou vendo é exclusivo do Edge, o que eu estaria vendo que não veria se estivesse sentado na frente do Chrome por exemplo?

Stephanie: Muitos dos recursos agora nesta primeira versão estável são focados no consumidor. Então, há o Collections que está sendo lançado, que é uma maneira muito legal de puxar coisas da web para coleções individuais, daí o nome. E você pode pegar esses dados e colocá-los em um painel lateral e exportá-los para Word e Excel, acredito. Eu tenho usado para projetos de design e outras coisas. É apenas legal para reunir recursos.

Stephanie: E um dos outros recursos para clientes Enterprise, e está disponível apenas no Windows, é o modo IE. Então, isso realmente renderizará o Internet Explorer em uma guia no Edge para pessoas que ainda precisam dessas páginas que dependem de tecnologia antiga. Então isso é muito legal.

Stephanie: E em termos de ferramentas para desenvolvedores, tudo agora é o mesmo. Eu sei que temos algumas coisas por vir que serão portadas para o Chromium, mas há um visualizador 3D DOM legal que está em andamento e a equipe está iterando. E há algumas outras ferramentas que ainda não existem no Chrome que estão chegando. Então isso é emocionante.

Drew: Então isso é um grande negócio para os desenvolvedores web, não é? Porque acho que normalmente as pessoas se acostumam a usar um conjunto de ferramentas de desenvolvedor em seu navegador de escolha e, muitas vezes, francamente, é o Chrome hoje em dia para muitos desenvolvedores da web. Então, ser capaz de acessar o Edge e encontrar um conjunto muito semelhante de ferramentas de desenvolvedor deve ser um grande atrativo, você acha?

Aaron: Sim, acho que sim. Quero dizer, é o tipo de coisa em que você terá exatamente o mesmo conjunto de ferramentas. Estamos construídos em cima do Chromium, incluindo todas as ferramentas de desenvolvimento. Temos feito muitos investimentos, como Stephanie estava falando, com o visualizador 3D DOM. Temos feito muitos investimentos em termos de melhoria da acessibilidade geral das ferramentas de desenvolvimento, adicionando novas ferramentas, trabalhando na internacionalização das ferramentas de desenvolvimento.

Aaron: E como Stephanie mencionou, a grande maioria do trabalho que estamos fazendo, basicamente qualquer coisa que não seja específica da interface do usuário do Edge ou que envolva nossa plataforma de sincronização ou coisas assim, tudo isso está sendo transmitido para o Chromium. Portanto, as correções que fazemos, as melhorias que fazemos para acessibilidade tornarão o Chrome melhor, o Brave melhor, o Opera melhor. Eles vão até tornar o Electron melhor.

Aaron: Então, é muito legal fazer parte desse ecossistema maior. E poder ter impacto além do nosso próprio navegador. E, portanto, as ferramentas de desenvolvimento têm sido uma área em que temos feito muito investimento. Também trabalhamos muito com parceiros da equipe do Chrome em aplicativos da Web progressivos. E tentando descobrir o que os aplicativos da web progressivos, ou como eles devem ser em ambientes de desktop, porque muito do foco está no celular.

Aaron: E também houve muito trabalho entre o Dev Tools Team e o pessoal que trabalha no VS Code para fazer essas ferramentas funcionarem melhor juntas. Para que você possa acessar basicamente as ferramentas de desenvolvimento do navegador a partir do código VS enquanto depura suas páginas. E tudo está meio conectado, como poder clicar em uma regra de estilo nas ferramentas de desenvolvimento do Edge, na verdade, isso o levará a essa linha no código VS em sua folha de estilo. O que é alucinante, é uma coisa muito legal.

Drew: Isso soa muito emocionante. Eu sei que o VS Code é algo que parece estar ganhando muita força na comunidade de desenvolvimento web. Acho que na verdade trouxe muitas pessoas de volta ao Microsoft Tools que podem ter se afastado ao longo dos anos. Certamente parece uma era diferente da Microsoft, assim como esse tipo de adoção de código aberto e a nova versão do Edge. Tudo parece bastante excitante e bastante refrescante do ponto de vista do desenvolvimento web.

Drew: Também desse ponto de vista, parece que isso é realmente uma grande conveniência para os desenvolvedores da web, porque se alguns dos principais navegadores, Chrome e Edge em particular, e você mencionou Brave e Opera, o que você tem, estão todos usando a mesma renderização engine, presumivelmente que reduz muitos problemas de compatibilidade e navegadores que não precisam ser testados em muitos lugares diferentes. Tudo deve funcionar da mesma forma, isso é justo?

Stephanie: Sim.

Drew: Incrível.

Aaron: Esse é o sonho, certo?

Drew: Esse é sempre o sonho. Isso levanta um pouco de preocupação, mas não na redução de uma espécie de concorrência saudável no mercado. Enquanto tínhamos a Microsoft empurrando seu navegador para frente, o Google empurrando seu navegador para frente. A Apple espera que o ideal seja empurrar seu navegador para frente, Opera e todos os outros jogadores. E isso meio que cria essa atmosfera de competição saudável, onde todos tentam acompanhar uns aos outros e tentar fazer melhorias. Se muitos grandes jogadores estão usando o mesmo mecanismo de renderização, essa competição saudável sofre?

Aaron: Isso é algo que eu definitivamente tenho, tendo sido uma pessoa de padrões web há muito tempo, meio que luto um pouco, eu não acho... eu entendo totalmente a justificativa de negócios para isso. Do ponto de vista da Microsoft, fazia muito sentido. E do ponto de vista do desenvolvedor de front-end, é bom não ter que atender a um monte de motores diferentes.

Aaron: Quero dizer, no geral, aqueles de nós que trabalham na web há muito tempo certamente viram muita convergência em termos de renderização. Não temos tantos problemas como tínhamos dito nos dias do Netscape 4.7, onde tínhamos tipo, você sabe, eu conhecia empresas que estavam criando folhas de estilo exclusivas para cada navegador diferente, o que era simplesmente insustentável.

Aaron: Mas acho que o que é diferente agora é que nas guerras dos navegadores originais você tinha todos esses mecanismos proprietários e todo mundo estava meio que em um jogo de superioridade em termos de tentar lançar novos recursos de plataforma e novos recursos de JavaScript . Ou no caso do JavaScript de engenharia reversa da Microsoft para criar J Script e tentar descobrir como encaixar tudo isso.

Aaron: Mas agora temos a capacidade de realmente trabalhar juntos em projetos de código aberto e ainda ter o diálogo e ainda, não sei, brigar não é a palavra certa, mas ter discussões sérias sobre o impacto de diferentes abordagens. E discordar um do outro. E para realmente trabalhar em fazer especificações realmente boas. E também ter abordagens concorrentes para o código subjacente dentro do contexto de, digamos, um projeto Chromium ou WebKit ou algo dessa natureza ou Mozilla no espaço do Firefox.

Aaron: Então sim, por um lado perdemos outro motor de renderização. E senti a mesma dor quando o Opera decidiu ir para o Chromium. Mas me sinto um pouco animado por estar dentro da Microsoft e ver o quanto estamos comprometidos em realmente participar do projeto Chromium de maneira significativa. E não apenas ficar sentado e aceitar tudo o que vem do Chromium, mas na verdade meio que vetando o que está entrando na plataforma e participando disso.

Aaron: Então, estou um pouco animado com isso e sinto que não estamos lá apenas para tirar esse projeto e apenas aceitar o que for passado por todas as pessoas diferentes que têm interesse nesse projeto. Mas para realmente estar colaborando lá também.

Aaron: Acho que ainda precisamos descobrir o que isso significa para os órgãos de padronização em termos de implementações interoperáveis. Porque basicamente se você tem alguns navegadores que decidem que não querem implementar algo, eles podem impedir totalmente que algo se torne um padrão. Mesmo que todos os desenvolvedores do mundo quisessem.

Aaron: E pode não ser nada como eles não concordam com isso. Eles simplesmente podem não ter a largura de banda para construir o recurso. Todo mundo está pressionado por funcionários e tal.

Drew: Eu acho que realmente a colaboração na web como uma plataforma acabou de mudar os locais de todos concordando em implementar as mesmas coisas em suas bases de código individuais para alguns jogadores principais trabalhando juntos na mesma base de código essencialmente.

Drew: Quer dizer, você mencionou brevemente divergências e obviamente isso é algo que pode ser uma preocupação, eu acho, em qualquer projeto de código aberto. Mas sabemos como isso funcionará, se os desenvolvedores do Google, por exemplo, quiserem implementar um recurso e os desenvolvedores da Microsoft realmente não quiserem ver isso implementado. Eles apenas brigam por problemas do GitHub?

Aaron: Quero dizer, muitas dessas coisas acontecem abertamente, seja em problemas do GitHub ou no Crbug, que é o rastreador de bugs do Chromium. Eu não sou um engenheiro de navegadores, então não conheço todos os detalhes internos, mas acredito que há muitas coisas que basicamente podemos desligar se não as quisermos.

Aaron: E eu sei que o Google está trabalhando em uma espécie de limpeza ou arrumação dentro do projeto Chromium para extrair mais serviços relacionados ao Google e até a camada de conversão do Chromium para o Chrome.

Aaron: E então temos um processo semelhante pegando o Chromium e transformando-o em Edge. E, obviamente, não gostaríamos de verificar o design da interface do usuário do Edge, por exemplo. Ou a coisa das Coleções, que é mais uma coisa de foco no usuário da interface do usuário que Stephanie estava mencionando, não estamos transmitindo isso para o Chromium. Esses existem no tipo da parte da interface do usuário.

Aaron: Então, até onde eu entendo, à medida que os recursos saem do Chromium, temos a capacidade de desligar certas coisas que podemos ou não gostar. E eu sei que o Brave faz o mesmo porque eles têm uma abordagem de privacidade muito diferente do que o Google diz. E podemos ter uma visão ligeiramente diferente de qualquer um deles ou o que você tem.

Aaron: Então eu acho que algumas coisas acontecerão em diferentes pontos. Alguns dos quais serão meio que onde o projeto é convertido no navegador do projeto de código aberto. Alguns deles estarão dentro das organizações de normalização ou grupos de interesse dentro das organizações de normalização e assim por diante.

Drew: E acho que funciona de outra forma também, não é? Você mencionou que um navegador não tem engenheiros suficientes disponíveis para desenvolver um recurso específico, tradicionalmente a maneira como as coisas funcionam dentro dos órgãos de padrões é que precisamos de várias implementações diferentes antes que algo seja aceito como parte do padrão. Obviamente, isso precisa ser descoberto se não houver muitas implementações disponíveis para realmente testar.

Drew: Mas, por exemplo, se a Microsoft quisesse implementar um recurso e o Google decidisse que simplesmente não tinha os recursos para implementar esse recurso, não era alto o suficiente em sua lista de prioridades, bem, potencialmente eles vão obtê-lo gratuitamente de qualquer maneira, porque ele é transmitido para o projeto de código aberto. E então eles podem acessá-lo e todos os seus usuários se beneficiam sem que nenhum de seus engenheiros precise gastar um tempo significativo desenvolvendo isso.

Drew: Quer dizer, se a Mozilla decidisse fazer o mesmo com o Firefox e apenas adotar o projeto Chromium, você acha que isso seria um problema para a web?

Stephanie: Quer dizer, eu diria que sim, porque então estamos nessa monocultura de navegadores e, honestamente, eu amo o Firefox. O Firefox tem algumas ótimas ferramentas que o Chromium não possui. Isso seria, eu acho, realmente terrível perder. E é bom ter um navegador independente por aí ainda lutando pela web aberta. Quer dizer, estamos lutando pela web aberta também, mas acho que o que o Firefox está fazendo ainda é importante.

Aaron: Quero dizer, eu meio que me pergunto o que aconteceria se, digamos, fosse Chromium ou WebKit ou algum fork de um projeto de código aberto existente, e se um corpo de padrões controlasse o mecanismo de renderização e o mecanismo JavaScript. E todos os fabricantes de navegadores estavam contribuindo para o desenvolvimento e a criação contínua disso. Isso seria necessariamente uma coisa ruim ou seria uma coisa boa? Não sei. Eu não sei qual é a resposta para isso, mas é uma perspectiva interessante que se... Os navegadores não são baratos e inconseqüentes para construir, e especialmente os mecanismos de renderização. Provavelmente será relativamente improvável que veremos muitos novos mecanismos de renderização e grandes investimentos nessa área. Porque muitas empresas mudaram para se concentrar em seus serviços.

Aaron: Com a Apple, com todo o seu iCloud e todo o seu ecossistema. E a Mozilla tem feito algumas coisas semelhantes com a aquisição do Pocket e tal. E certamente há o conjunto de produtos do Google, o conjunto de produtos da Microsoft etc. E o Brave está focado em privacidade e no token de atenção básico e esse tipo de coisa. Todo mundo meio que tem seu pequeno ecossistema de coisas.

Aaron: Então, não sei se haverá muito interesse em construir um novo mecanismo de renderização e um novo mecanismo JavaScript para desafiar os que estão lá. Então, é meio que uma questão de se continuará havendo uma espécie de consolidação. E se mais pessoas estiverem ativamente interessadas no desenvolvimento em andamento, e meio que tendo essas conversas difíceis sobre para onde o mecanismo está indo e para onde a plataforma da web está indo, isso pode ser uma coisa boa, eu não sei. É uma espécie de experimento de pensamento interessante, no entanto.

Drew: É mesmo. O novo Edge parece realmente empolgante. Eu tenho brincado um pouco com os betas e gostando disso. Quanto tempo você acha que levará para que esta nova versão seja lançada no mundo? Porque é, quero dizer, só foi lançado este mês, não é, estamos em janeiro de 2020.

Aaron: Sim, 15 de janeiro, basicamente foi para o público geral. Então, tivemos as versões dev e beta do Canary. Puxa, quando começamos a lançar isso, Stephanie, você se lembra?

Stephanie: Eu vou dizer seis meses atrás, mas honestamente, estou apenas jogando isso lá fora. Sinto que estou usando o Canary como meu motorista diário há meses.

Aaron: Sim, acho que estamos meio distorcidos porque começamos a usá-lo internamente um pouco antes de começarmos a abri-lo ao público. Mas sim, acho que quero dizer que começamos a compartilhá-lo na Build no ano passado, que teria sido em maio, acho que foi quando o Canary, e talvez a rota de desvio, não me lembro se o beta foi lançado na época. Mas sim, a versão totalmente estável saiu no dia 15.

Drew: Então, vocês dois estão envolvidos em um projeto chamado The Web We Want , que é uma espécie de iniciativa entre vários fabricantes de navegadores diferentes, certo?

Stephanie: Sim, então The Web We Want , acho que Aaron começou em junho passado e começamos a falar sobre isso. E sim, The Web We Want é basicamente uma iniciativa e Aaron e eu fomos os principais a executá-la, mas tivemos o interesse de outros fornecedores de navegadores e pessoas que trabalham nessas equipes.

Stephanie: E é basicamente apenas uma maneira de coletar feedback dos desenvolvedores sobre problemas que eles estão tendo na web. Porque nós, como pessoas que construímos o navegador, podemos focar naquelas coisas novas e brilhantes que queremos implementar. Mas os desenvolvedores, como vimos através desta iniciativa, há muitas coisas que eles ainda estão lutando para construir que não são nativas no navegador. Isso provavelmente já deveria ter sido resolvido, mas não foi.

Stephanie: E é assim que a iniciativa está em toda parte, descobrir quais são essas áreas problemáticas e depois levá-las de volta aos navegadores e órgãos de padronização se for esse tipo de problema.

Drew: Então, que tipo de forma isso tem? É algo que você faz pessoalmente ou é tudo online?

Stephanie: Então, temos dois componentes. Assim, você pode acessar webwewant.fyi e preencher um formulário com seu problema e seu caso de uso que encontrou na web. E então Aaron e eu fomos, acho que fomos, bem, acho que organizamos seis ou sete eventos em uma conferência ou um encontro.

Stephanie: Então, a forma que isso toma é que geralmente temos uma sessão de 45 minutos a uma hora em uma conferência com a qual estamos fazendo parceria. E damos às pessoas que enviaram seus problemas encontrados na web a chance de apresentá-los a um painel de juízes que geralmente são especialistas do setor.

Stephanie: E no meio geralmente temos quatro ou cinco desses problemas apresentados durante uma sessão. E entre cada um deles, nosso painel de jurados meio que fala sobre o espaço do problema que está sendo apresentado. E se é ou não um espaço de problema interessante. Ou se eles acham que seria útil para os fornecedores de navegadores trabalharem nisso.

Stephanie: E então, no final daquela sessão, nossos juízes escolhem o que eles acham que é o problema mais urgente a ser resolvido. E também temos um componente de audiência, então o público da sessão também pode votar no que eles acham que é a coisa mais urgente que os fornecedores de navegadores deveriam corrigir.

Stephanie: E então levamos esses dados de volta para nossas equipes. E estamos atualmente no processo de descobrir como distribuir isso entre as diferentes equipes de navegadores.

Drew: Há algum tipo de destaque, sugestões que você se lembra que tenham ficado particularmente com você?

Stephanie: Então, houve alguns, o que continua se destacando para mim é que os controles HTML continuam surgindo. E isso está se destacando para mim porque estou trabalhando em uma palestra agora que envolve controles HTML e como não ser capaz de estilizá-los ou estendê-los é um problema. E é legal ver esse feedback reiterado ainda mais.

Stephanie: Houve alguns realmente interessantes, havia um para um visualizador de ordem de exibição de origem ou visualizador de ordem de origem nas ferramentas de desenvolvimento que tinham a ver com, acredito, capturar conteúdo e visualização da grade, porque você pode mover as coisas fora de ordem, e ter esse tipo de identificação de como as coisas fluem pelos DOMs. Então, acho que seria muito legal implementar nas ferramentas de desenvolvimento.

Aaron: Sim, tem havido muitos envios relacionados à acessibilidade, o que tem sido muito legal. Outro que foi relacionado a ferramentas de desenvolvimento e acessibilidade foi, na verdade, em vez de relegar o teste de acessibilidade para sua própria parte, era a guia de auditorias, acho que é onde está atualmente, como o lighthouse faz alguns testes de acessibilidade, ou você pode usar dicas da web ou insights de acessibilidade e tal.

Aaron: A ideia disso é realmente começar a capturar alguns dos frutos mais fáceis em termos de erros de acessibilidade e borbulhar isso no console, por exemplo. Então, se ele vir que você tem algumas imagens que estão faltando texto alternativo ou algumas fontes muito pequenas ou não há contraste suficiente, ele pode realmente jogá-las como erros no console. E isso tende a ser onde muitos desenvolvedores estão verificando se suas coisas estão funcionando corretamente. Isso tornaria um pouco mais óbvio para as pessoas que elas têm problemas de acessibilidade que precisam resolver.

Aaron: E você pode ver algumas maneiras semelhantes de incorporar isso no visualizador do Dom ou nas ferramentas do inspetor de CSS, onde pode sinalizar algo como contraste muito baixo ou destacar um elemento como tendo algum problema de acessibilidade conhecido. Esse tipo de coisa seria bem interessante.

Stephanie: Sim, eu quero pegar carona nisso. Na verdade, houve um muito interessante apresentado no View Source em Amsterdã no ano passado. Foi em torno do navegador corrigindo automaticamente certos tipos de problemas de acessibilidade para você. E apenas com cor e contraste ou talvez certas fontes ilegíveis. E a proposta e o estudo de caso apresentados foram muito, muito bem pensados. Mas também coloca essa questão interessante de se o navegador começar a consertar as coisas para você como desenvolvedor, você vai escrever código ruim porque não precisa se preocupar com isso.

Stephanie: Então foi interessante porque as ideias que ele apresentou e meio que demos foram muito legais. Mas isso é o que isso significa para os desenvolvedores, então, eles vão ficar preguiçosos. Então, eu vi algumas coisas legais saindo dele.

Drew: Então eu acho que ainda é muito cedo, não é, para a iniciativa. Então, acho que não vimos nada chegar ao ponto de atingir os estágios iniciais de desenvolvimento com nenhum navegador. Você sabe como será esse processo, você disse que ainda estava tentando descobrir, certo?

Aaron: Sim, todos nós ainda estamos tentando descobrir, mas temos as pessoas certas envolvidas. Temos gente da Mozilla e do Google e da Igalia também, foram eles que fizeram grande parte do trabalho da grade e estão muito familiarizados com o funcionamento de todas essas coisas padrão. Na verdade, acho que eles estão fazendo Metanol agora, fazendo a implementação do WebKit.

Aaron: Então, sim, nós temos um monte de pessoas a bordo que estão ansiosas para trabalhar nisso e ansiosas para ver o sucesso. E o W3C está prestando atenção nisso também, o que é legal.

Stephanie: Então, para nós agora, nós pegamos, acho que temos 12 melhores, pegamos os vencedores de cada evento no ano passado, e eu meio que os dividi em suas categorias específicas. Então, alguns são focados em ferramentas de desenvolvimento, alguns são HTML, focados em plataforma web. E então eu não consigo lembrar qual era a terceira categoria, era meio que geral.

Stephanie: E então, no lado do Edge, estamos começando a pelo menos analisar, vou ter algumas pesquisas no Twitter, espero que em breve, para ajudar a reunir mais feedback para validar que esses são espaços problemáticos nos quais devemos investir tempo E então espero que possamos partir daí. Então, espero que em algum momento deste ano comecemos a ver algum tipo de progresso. Mas no momento está um pouco lento.

Drew: É ótimo porque a web é uma plataforma muito colaborativa. E eu acho que como um desenvolvedor web apenas construindo sites no dia-a-dia, você esquece que na verdade existem maneiras de retroalimentar o processo e maneiras de fazer sua voz ser ouvida. E eu acho que isso soa como uma ótima maneira fácil de fazer sua voz ser ouvida.

Drew: Se algum de nossos ouvintes quiser participar de uma sessão do Web We Want , haverá algum?

Stephanie: Há alguns, então deixe-me abrir minha lista aqui. Então, bem, Open Source Festival em Lagos, Nigéria. Aaron e eu não estaremos lá, mas eles estão realizando esse evento de forma independente.

Stephanie: E então estarei no SF HTML5 em San Francisco no final de março. Eu acredito que é grátis, mas não me cite sobre isso. Tenho que verificar. Então, se você estiver na área de São Francisco, estamos executando lá.

Stephanie: E então SmashingConf San Francisco em abril. Estaremos executando lá.

Stephanie: E esperançosamente TBD, ainda olhando para SmashingConf Austin.

Stephanie: E eu acredito que isso é tudo que temos no calendário agora. Mas, fazendo um pequeno plug aqui, se você organizar uma conferência ou um encontro e gostaria que esta sessão focada na comunidade fosse realizada lá, entre em contato porque é muito legal.

Drew: Claro, os SmashingConfs são os melhores para ir, pensamos aqui.

Stephanie: Sim, sim, eles são.

Drew: Então, para mim, isso soa muito, muito emocionante. And I'm heartened to see all the big browser makers actually coming together and backing that sort of initiative to get out and to talk to web developers, talk to the people who are actually solving these sort of everyday problems, building websites and apps for their clients and for their companies.

Drew: I think it's really important to actually listen to the people who are at the coalface doing the work.

Drew: I normally ask at the sort of end of these episodes, what have you been learning lately? Because we're all about learning stuff here at Smashing, but really with Web We Want , I think you must be learning all these things all the time by speaking to web developers. So I really think we've covered masses there.

Drew: Is there anything else that you wanted to mention about Web We Want or about the new version of Edge that we hadn't talked about?

Aaron: I just think if folks have ideas, even just the germ of an idea, some cow path that you think should be paved for the web, reach out to us, let us know. We're happy to also work with you on kind of refining the submission. So, in a lot of cases we'll get a submission that's kind of a germ of an idea. It's not perfectly articulated or anything like that. And we work with those authors to make sure that we kind of capture what it is that they're looking to put out there. So, don't worry about your grammar or your spelling or anything like that. It's not like we just post it up as soon as you send it, we'll look at it, review it.

Aaron: And in some cases people have suggested things that actually exist, in which case we tell them, hey, you can actually do that and here's a way to do that. So we can, it's a little bit of stack overflow as well. Because he can tell you if there's something that you can do that already with standards.

Aaron: But yeah, I mean, we want any and all ideas on how we can improve the web. Hopefully they're actionable ideas. In some cases we get like, the web is too hard. And it's like, you know, I feel you, but, you know, not something browser vendors can really solve.

Aaron: But yeah, I mean, we want to know what is it that you're doing, where you're running into problems. We have the kind of saying, if you could wave a magic wand and fix something on the web, what would it be?

Aaron: And yeah, so you can can hit us up via the forum. Stephanie mentioned webwewant.fyi. Or we're webwewantfyi on Twitter. Yeah, please reach out.

Stephanie: I will also pile on just to talk something about Edge that also, the team is super hungry and eager to get feedback from all of our users. So if you're in Edge and there's something you don't like or there's something you love, there's a little feedback icon you can click. All of the teams see that feedback and are looking at it. And if you have a problem are very proactive and engaging. And you can always ping MS Edge Dev on Twitter if you have a problem and it hasn't been addressed yet. So trying to be super proactive and really build a browser that not only developers want to use, but the world.

Drew: If you, dear listener, would like to hear more from Aaron or Stephanie, you can follow them on Twitter where he's @AaronGustafson and she's @seaotta. You can find The Web We Want at webwewant.fyi.

Drew: Thank you for joining us today Aaron and Stephanie, do you have any parting words?

Stephanie: Thanks.

Aaron: Adios.