Smashing Podcast Episodio 8 con Stephanie Stimac y Aaron Gustafson: ¿Qué hay de nuevo en Microsoft Edge?

En este episodio de Smashing Podcast, hablo con Aaron Gustafson y Stephanie Stimac de Microsoft para obtener más información sobre la nueva versión de Microsoft Edge y cómo está afectando a los desarrolladores web de todo el mundo, así como su impacto en la web.

Mostrar notas

• El sitio web Web We Want y Twitter
• Stephanie y Aarón en Twitter

Actualización semanal

• “El Mítico Hombre-Mes Mítico”,
  por John Foreman
• “Recreación del botón pulsador de Arduino usando SVG y <elemento iluminado>,”
  por Uri Shaked
• "Cómo pasar datos entre componentes en Vue.js"
  por Matt Maribojoc
• "Una guía completa para WordPress multisitio"
  por Manish Dudharejia
• "Cómo empoderar a los equipos de diseño midiendo el valor"
  por Dave Cunningham

Transcripción

Drew: Sabemos que ambos son de Microsoft, ambos están dedicados a mejorar la web para todos nosotros, pero ¿sabías que su reunión más reciente de Web We Want se llevó a cabo en un globo aerostático fuera de la atmósfera terrestre? antes de volver a saltar a la tierra al estilo de Felix Baumgartner.

Drew: Mis Smashing Friends, denle la bienvenida a Stephanie Stimac y Aaron Gustafson.

Drew: Hola Stephanie, hola Aaron, ¿cómo estás?

Aaron Gustafson: Estoy genial.

Stephanie Stimac: Yo también estoy sensacional.

Drew: Quería hablarles hoy sobre algunos desarrollos muy interesantes que han estado ocurriendo con el navegador Microsoft Edge. Supongo que la mayoría de nosotros sabrá que Edge es tradicionalmente el navegador de Windows 10 que reemplazó al muy querido Internet Explorer. Probablemente lo primero que debemos tener en cuenta es que Edge ya no es exclusivo de Windows 10, ¿verdad?

Aarón: Correcto.

Stephanie: Puedes encontrar Edge en Windows 10 y Mac OS. Y luego no estoy seguro de si está disponible en Windows Seven todavía.

Aaron: Sí, creo que ahora también está disponible en Windows Seven y Windows Eight. Y luego, por supuesto, también están los clientes móviles para iOS y Android.

Drew: Casi todas las plataformas modernas.

Estefanía: Sí.

Aaron: A excepción de Linux, con suerte llegará pronto.

Drew: Entonces, incluso los usuarios de escritorio de Linux pueden participar en la acción.

Aaron: Eventualmente, esa es la esperanza.

Drew: Fantástico. Por lo que yo entiendo, y corríjame si me equivoco aquí, pero Edge era técnicamente una continuación del código base de Internet Explorer, ¿es justo decirlo?

Aaron: Sí, cuando Edge comenzó por primera vez, era básicamente eliminar todas las cosas que nos dimos cuenta de que estaban un poco retrasadas, cosas que habían sido propietarias y cosas así. Todos los antiguos objetos de ayuda del navegador y cosas de ActiveX y cosas por el estilo. Así que fue destruido masivamente. Fue una especie de oportunidad para que el equipo realmente se deshiciera de gran parte del equipaje heredado y se concentrara en las cosas estándar. Y así fue una continuación del antiguo motor Triton, pero refactorizado y convertido en el motor Edge HTML.

Drew: Entonces fue como una renovación masiva de la casa dentro de la base del código.

Aaron: Sí, llévalo a los sementales.

Drew: Supongo que el cambio más grande del que quiero hablar con la versión más nueva de Edge es que se han eliminado y reemplazado aún más de ese tipo de agallas más antiguas. Y hay un nuevo motor de renderizado que se ha instalado. Ahora soy un poco consciente del uso de la jerga y las personas que quizás no estén tan familiarizadas con el funcionamiento de los navegadores pueden no estar completamente satisfechas con lo que queremos decir con un motor de renderizado. Creo que algunos de nosotros que llevamos mucho tiempo trabajando en la web habremos recogido esa información, incluso si no estamos trabajando directamente con las partes internas de los navegadores. Pero alguien que quizás sea más nuevo en el desarrollo web podría no entender qué queremos decir con un motor de renderizado. Entonces, ¿qué es un motor de renderizado dentro de un navegador? ¿Y qué bits no son un motor de renderizado?

Aaron: Bueno, hay un montón de partes diferentes en un navegador. El motor de renderizado es lo que normalmente pensamos cuando hablamos de lo que realmente se está pintando en la pantalla y una especie de capa interactiva de cosas. Y así, en el mundo de Chromium, ese es el motor de renderizado Blink.

Aaron: Y luego está el motor de renderizado WebKit, que es el que ejecuta Safari. Y eso se basó en el motor de renderizado KHTML, que ejecutaba Konquerer en los primeros días.

Aaron: El motor de renderizado Trident que mencioné antes era el de Internet Explorer para Windows. Tantek Celik había creado el motor de renderizado Tasman como parte del equipo que estaba trabajando en IE5 para Mac.

Aaron: Así que hay todos estos diferentes motores de renderizado por ahí. Y, de hecho, creo que había uno nuevo del que Peter Paul Cox estaba hablando llamado Flow. Eso es como un motor de renderizado de subprocesos múltiples que se basa en SVG o algo así. Y hay un próximo navegador para eso que fue diseñado para decodificadores, dispositivos de muy baja potencia.

Aaron: Pero sí, los motores de renderizado, tomando toda tu información y pintándola en la pantalla. Y luego tienes tu tipo de motores de JavaScript subyacentes también. Entonces v8 en el caso del tipo de pila Chromium. Y hay un montón de diferentes para eso también.

Drew: Entonces, cuando decimos que el antiguo motor de renderizado Trident, que vino de IE y ha estado en Edge, ha sido reemplazado. En realidad, estamos hablando de la parte que pinta cosas en la pantalla y también cosas asociadas como el motor de JavaScript. ¿Es eso justo?

Aaron: Sí, en el caso de la nueva versión de Edge, básicamente no hay ninguna de las bases del antiguo Edge. El proyecto Chromium es un proyecto de código abierto que ejecuta Chrome y Brave y muchos otros, Opera y demás. Y ese proyecto incluye el motor de renderizado, incluye el motor de JavaScript, incluye toda la interfaz de usuario. También incluye el proceso de compilación y todo ese tipo de cosas para crear el navegador.

Aaron: Y básicamente tenemos el proyecto Chromium, que se convirtió en la base para el nuevo Edge. Entonces, tuvimos que pasar por el proceso de hacer que se pareciera a Edge y agregar la funcionalidad que necesitábamos en términos de sincronización, usando cuentas de Microsoft, todo ese tipo de cosas.

Aaron: Entonces, el nuevo Edge no comparte ningún linaje en el sentido tradicional con el antiguo Edge, que era Edge HTML, que heredó de Trident y así sucesivamente. Y puede seguir yendo hasta Mosaic para la mayoría de estos.

Aaron: Pero sí, ahora el nuevo Edge es Chromium, que se basa en WebKit antes que él, que se basa en KHTML y así sucesivamente. Entonces es un linaje completamente diferente al anterior.

Drew: Entonces, quiero decir, eso es un gran cambio, ¿no?, que Microsoft ya no tenga un navegador que se origine en su propio código. Pero en realidad está tomando un proyecto de código abierto y creando su propio navegador a partir de eso. Lo cual supongo que es similar a lo que Apple hizo en su día con WebKit. ¿Qué, fue KHTML ellos...?

Aaron: Sí, Konqueror fue el... con una K.

Drew: Sí, Konquerer, así que tomaron ese proyecto de código abierto y se convirtió en Safari. Entonces, ¿Microsoft está haciendo algo similar con el proyecto Chromium y ha convertido a Edge en eso?

Aarón: Correcto.

Drew: Si me siento frente a Edge como desarrollador web, lo que veo es exclusivo de Edge, ¿qué vería que no vería si me sentara frente a Chrome para ¿ejemplo?

Stephanie: Muchas de las funciones en este momento en esta primera versión estable están enfocadas en el consumidor. Entonces, hay colecciones que están saliendo, que es una forma genial de extraer cosas de la web en colecciones individuales, de ahí el nombre. Y puede tomar esos datos y ponerlos en un panel lateral y luego exportarlos a Word y Excel, creo. Lo he estado usando para proyectos de diseño y otras cosas. Es genial para reunir recursos.

Stephanie: Y luego, una de las otras características para los clientes empresariales, y solo está disponible en Windows, es el modo IE. Eso realmente mostrará Internet Explorer dentro de una pestaña en Edge para las personas que todavía necesitan esas páginas que dependen de la tecnología antigua. Así que eso es genial.

Stephanie: Y luego, en términos de herramientas para desarrolladores, todo en este momento es igual. Sé que tenemos algunas cosas próximas que se transferirán a Chromium, pero hay un visor DOM 3D genial que está en proceso y el equipo ha estado iterando. Y hay algunas otras herramientas que aún no existen en Chrome que están por venir. Eso es emocionante.

Drew: Eso es un gran problema para los desarrolladores web, ¿no? Porque creo que, por lo general, las personas se acostumbran a usar un conjunto de herramientas de desarrollo en el navegador que eligen y, francamente, en estos días, Chrome es para muchos desarrolladores web. Entonces, poder ir a Edge y encontrar un conjunto muy similar de herramientas de desarrollo tiene que ser un gran atractivo, ¿crees?

aarón: sí, creo que sí. Quiero decir que es el tipo de cosas en las que vas a tener exactamente el mismo conjunto de herramientas. Estamos construidos sobre Chromium, incluidas todas las herramientas de desarrollo. Hemos estado haciendo muchas inversiones, como decía Stephanie, con el visor 3D DOM. Hemos estado haciendo muchas inversiones en términos de mejorar la accesibilidad general de las herramientas de desarrollo, agregando nuevas herramientas, trabajando en la internacionalización de las herramientas de desarrollo.

Aaron: Y como mencionó Stephanie, la gran mayoría del trabajo que estamos haciendo, básicamente cualquier cosa que no sea una interfaz de usuario específica para Edge o que involucre nuestra plataforma de sincronización o cosas así, todo eso se transmite a Chromium. Entonces, las correcciones que hacemos, las mejoras que hacemos para la accesibilidad van a hacer que Chrome sea mejor, Brave mejor, Opera mejor. Incluso van a mejorar a Electron.

Aaron: Entonces, es genial ser parte de ese ecosistema más grande. Y poder tener impacto más allá de nuestro propio navegador. Y entonces, las herramientas de desarrollo han sido un área en la que hemos estado invirtiendo mucho. También hemos trabajado mucho con socios del equipo de Chrome en aplicaciones web progresivas. Y tratando de descubrir qué hacen las aplicaciones web progresivas, o cómo deberían verse en entornos de escritorio, porque gran parte del enfoque se ha centrado en los dispositivos móviles.

Aaron: Y también ha habido mucho trabajo entre el equipo de herramientas de desarrollo y la gente que trabaja en VS Code para hacer que esas herramientas funcionen mejor juntas. Básicamente, puede acceder a las herramientas de desarrollo desde el navegador desde el código VS mientras depura sus páginas. Y todo está conectado, como poder hacer clic en una regla de estilo en las herramientas de desarrollo de Edge, en realidad lo llevará a esa línea en el código VS en su hoja de estilo. Lo cual es alucinante, es algo realmente genial.

Drew: Eso suena muy emocionante. Sé que VS Code es algo que parece estar ganando mucha tracción en la comunidad de desarrollo web. Creo que en realidad ha hecho que muchas personas regresen a las Herramientas de Microsoft que podrían haberse alejado a lo largo de los años. Ciertamente se siente como una era diferente de Microsoft, al igual que este tipo de aceptación del código abierto y la nueva versión de Edge. Todo parece bastante emocionante y refrescante desde el punto de vista del desarrollo web.

Drew: También desde ese punto de vista, parece que esto es realmente una gran conveniencia para los desarrolladores web porque si algunos de los principales navegadores, Chrome y Edge en particular, y mencionaste Brave y Opera, ¿qué tienes? Todos usan la misma representación. motor, presumiblemente eso reduce una gran cantidad de problemas de compatibilidad y navegadores que no necesitan ser probados en muchos lugares diferentes. Todo debería funcionar igual, ¿es justo?

Estefanía: Sí.

Drew: Impresionante.

Aaron: Ese es el sueño, ¿verdad?

Drew: Ese es siempre el sueño. Plantea un poco de preocupación, aunque no lo hace en la reducción de una especie de sana competencia en el mercado. Mientras que Microsoft impulsaba su navegador hacia adelante, Google impulsaba su navegador hacia adelante. Con suerte, Apple impulsará idealmente su navegador, Opera y todos los demás jugadores. Y eso crea una atmósfera de sana competencia en la que todos intentan mantenerse al día e intentar mejorar. Si muchos de los grandes jugadores utilizan el mismo motor de renderizado, ¿se resiente esa sana competencia?

Aaron: Esto es algo que definitivamente tengo, después de haber sido una persona de estándares web durante mucho tiempo, algo con lo que luché un poco, no creo... Entiendo totalmente la justificación comercial para ello. Desde el punto de vista de Microsoft, tenía mucho sentido. Y desde la perspectiva de un desarrollador front-end, es bueno no tener que atender a un montón de motores diferentes.

Aaron: Quiero decir, en general, aquellos de nosotros que hemos estado trabajando en la web durante mucho tiempo, ciertamente hemos visto mucha convergencia en términos de representación. No tenemos tantos problemas como decíamos en los días de Netscape 4.7 en los que teníamos, ya sabes, conocía empresas que estaban creando hojas de estilo únicas para cada navegador diferente, lo cual era simplemente insostenible.

Aaron: Pero creo que lo que es un poco diferente ahora es que en las guerras de navegadores originales tenías todos estos motores patentados y todos estaban como en un juego de superioridad en términos de tratar de enviar nuevas funciones de plataforma y nuevas funciones de JavaScript. . O en el caso de JavaScript de ingeniería inversa de Microsoft para crear J Script y tratar de averiguar cómo encajar todo.

Aaron: Pero ahora tenemos la capacidad de trabajar juntos en proyectos de código abierto y aún tener el diálogo y aún, no sé, pelear no es la palabra correcta, pero tener discusiones serias sobre el impacto de diferentes enfoques. Y estar en desacuerdo unos con otros. Y realmente trabajar para hacer que las especificaciones sean realmente buenas. Y también tener enfoques competitivos para el código subyacente dentro del contexto de, por ejemplo, un proyecto de Chromium o WebKit o algo de esa naturaleza o Mozilla en el espacio de Firefox.

Aaron: Así que sí, por un lado perdimos otro motor de renderizado. Y sentí ese mismo dolor cuando Opera decidió ir a Chromium. Pero me siento un poco alentado por estar dentro de Microsoft y ver cuán comprometidos estamos para participar en el proyecto Chromium de una manera significativa. Y no solo sentarse y aceptar todo lo que viene de Chromium, sino también investigar lo que está pasando en la plataforma y participar en eso.

Aaron: Eso me alienta un poco y siento que no estamos allí solo para tomar de ese proyecto y aceptar lo que sea que transmitan todas las diferentes personas que tienen un interés en ese proyecto. Pero para estar colaborando allí también.

Aaron: Creo que todavía tenemos que averiguar qué significa esto para los organismos de normalización en términos de implementaciones interoperables. Porque básicamente, si tienes algunos navegadores que deciden que no quieren implementar algo, pueden evitar que algo se convierta en un estándar. Incluso si todos los desarrolladores del mundo lo quisieran.

Aaron: Y puede que no sea nada parecido a lo que no están de acuerdo. Es posible que simplemente no tengan el ancho de banda para crear la función. Todo el mundo está presionado por el personal y tal.

Drew: Supongo que realmente la colaboración en la web como plataforma acaba de mover ubicaciones de todos los que acordaron implementar las cosas de la misma manera en sus bases de código individuales a algunos jugadores importantes que trabajan juntos en la misma base de código esencialmente.

Drew: Quiero decir, mencionaste brevemente desacuerdos y obviamente eso es algo que podría ser una preocupación, supongo, en cualquier proyecto de código abierto. Pero, ¿sabemos cómo funcionará eso, si los desarrolladores de Google, por ejemplo, quieren implementar una función y los desarrolladores de Microsoft realmente no quieren verla implementada? ¿Simplemente pelean por problemas de GitHub?

Aaron: Quiero decir, muchas de estas cosas suceden abiertamente, ya sea en problemas de GitHub o en Crbug, que es el rastreador de errores para Chromium. No soy ingeniero de navegadores, así que no conozco todos los detalles internos, pero creo que hay muchas cosas que básicamente podemos desactivar si no las queremos.

Aaron: Y sé que Google ha estado trabajando en una especie de limpieza o limpieza dentro del proyecto Chromium para extraer más servicios relacionados con Google y hasta la capa de convertirlo de Chromium a Chrome.

Aaron: Tenemos un proceso similar tomando Chromium y convirtiéndolo en Edge. Y, obviamente, no nos gustaría comprobar el diseño de la interfaz de usuario de Edge, por ejemplo. O el tema de las colecciones, que es más un tema de enfoque del usuario de la interfaz de usuario que mencionaba Stephanie, no estamos transmitiéndolos a Chromium. Esos existen en especie de la parte de la interfaz de usuario.

Aaron: Por lo que yo entiendo, a medida que las características salen de Chromium, tenemos la capacidad de desactivar ciertas cosas que nos pueden gustar o no. Y sé que Brave hace el mismo tipo de cosas porque tienen un enfoque de privacidad muy diferente al que dice Google. Y es posible que tengamos una opinión ligeramente diferente a cualquiera de ellos o lo que sea.

Aaron: Así que creo que habrá cosas que sucedan en diferentes puntos. Algunos de los cuales serán una especie de donde el proyecto se convierte en el navegador desde el proyecto de código abierto. Una parte estará dentro de las organizaciones de normalización o grupos de interés dentro de las organizaciones de normalización y así sucesivamente.

Drew: Y supongo que también funciona al revés, ¿no? Mencionó que un navegador no tiene suficientes ingenieros disponibles para desarrollar una función en particular, tradicionalmente, la forma en que han funcionado las cosas dentro de los organismos de estándares es que necesitamos múltiples implementaciones diferentes antes de que algo se acepte como parte del estándar. Obviamente, eso debe resolverse si no hay tantas implementaciones disponibles para probar.

Drew: Pero, por ejemplo, si Microsoft quisiera implementar una función y Google decidiera que simplemente no tenía los recursos para implementar esa función, no estaba lo suficientemente alto en su lista de prioridades, bueno, potencialmente van a obténgalo gratis de todos modos porque simplemente se transmite al proyecto de código abierto. Y luego pueden acceder a él y todos sus usuarios se benefician sin que ninguno de sus ingenieros necesite dedicar mucho tiempo a desarrollarlo.

Drew: Quiero decir, si Mozilla decidiera que iban a hacer lo mismo con Firefox y adoptar el proyecto Chromium, ¿crees que sería un problema para la web?

Stephanie: Quiero decir, diría que sí, porque entonces estamos en esta monocultura de navegadores y, sinceramente, me encanta Firefox. Firefox tiene algunas herramientas excelentes que Chromium no tiene. Eso sería, creo, realmente terrible de perder. Y es bueno tener una especie de navegador independiente que sigue luchando por la web abierta. Quiero decir, también estamos luchando por la web abierta, pero creo que lo que está haciendo Firefox sigue siendo importante.

Aaron: Quiero decir, me pregunto qué pasaría si, digamos, ya sea Chromium o WebKit o alguna bifurcación de un proyecto de código abierto existente, ¿qué pasaría si un organismo de estándares controlara el motor de renderizado y el motor de JavaScript? Y todos los fabricantes de navegadores contribuyeron al desarrollo y la creación continua de eso. ¿Sería eso necesariamente algo malo o sería algo bueno? No sé. No sé cuál es la respuesta a eso, pero es una perspectiva interesante que si... Los navegadores no son baratos ni intrascendentes de construir, y especialmente los motores de renderizado. Probablemente será relativamente poco probable que veamos una gran cantidad de nuevos motores de renderizado y grandes inversiones en esa área. Porque muchas empresas han pasado a centrarse en sus servicios.

Aaron: Con Apple, con todo su iCloud y todo su ecosistema. Y Mozilla ha estado haciendo cosas similares con la adquisición de Pocket y demás. Y luego, ciertamente, está el conjunto de productos de Google, el conjunto de productos de Microsoft, etc. Y Brave se centra en la privacidad y el token de atención básica y ese tipo de cosas. Todo el mundo tiene su pequeño ecosistema de cosas.

Aaron: Entonces, no sé si va a haber mucho interés en desarrollar un nuevo motor de renderizado y un nuevo motor de JavaScript para desafiar a los que ya existen. Entonces, es una especie de cuestión de si seguirá habiendo una especie de consolidación. Y si más personas están activamente interesadas en el desarrollo en curso, y tienen esas conversaciones difíciles sobre hacia dónde se dirige el motor y hacia dónde se dirige la plataforma web, ¿podría ser algo bueno? No lo sé. Sin embargo, es una especie de experimento mental interesante.

Drew: Realmente lo es. El nuevo Edge suena realmente emocionante. He estado jugando un poco con las betas y disfrutándolo. ¿Cuánto tiempo crees que tardará esta nueva versión en lanzarse al mundo? Porque, quiero decir, acaba de ser lanzado este mes, ¿no es así? Estamos en enero de 2020.

Aaron: Sí, el 15 de enero, fue básicamente para la audiencia general. Entonces, hemos tenido las versiones Canary dev y beta. Caramba, ¿cuándo empezamos a implementar esto, Stephanie, te acuerdas?

Stephanie: Voy a decir hace seis meses, pero honestamente, solo estoy descartando eso. Siento que he estado usando a Canary como mi conductor diario durante meses.

Aaron: Sí, creo que estamos un poco sesgados porque comenzamos a usarlo internamente por un tiempo antes de comenzar a abrirlo al público. Pero sí, creo que quiero decir que comenzamos a compartirlo en Build el año pasado, que habría sido en mayo, creo que es cuando Canary, y tal vez la ruta de desvío, no recuerdo si la versión beta estaba disponible en ese momento. Pero sí, la versión completamente estable salió el día 15.

Drew: Entonces, ambos están involucrados en un proyecto llamado The Web We Want , que es una especie de iniciativa entre muchos fabricantes de navegadores diferentes, ¿no es así?

Stephanie: Sí, así que The Web We Want , creo que Aaron comenzó en junio pasado y comenzamos a hablar sobre eso. Y sí, The Web We Want es básicamente una iniciativa y Aaron y yo hemos sido los principales en ejecutarla, pero hemos tenido interés de otros proveedores de navegadores y personas que trabajan en esos equipos.

Stephanie: Y básicamente es solo una forma de recopilar comentarios de los desarrolladores sobre los problemas que tienen en la web. Porque nosotros, como personas que construyen el navegador, podemos centrarnos en esas cosas nuevas y brillantes que queremos implementar. Pero los desarrolladores, como hemos llegado a ver a través de esta iniciativa, hay muchas cosas que todavía están luchando por construir que no son nativas en el navegador. Eso probablemente ya debería haberse resuelto, pero no lo ha hecho.

Stephanie: Y de eso se trata la iniciativa, descubrir cuáles son esas áreas problemáticas y luego llevarlas de vuelta a los navegadores y organismos de estándares si es ese tipo de problema.

Drew: Entonces, ¿qué tipo de forma toma eso? ¿Es algo que haces en persona o es todo en línea?

Stephanie: Entonces, tenemos dos componentes. Entonces puede ir a webwewant.fyi y puede completar un formulario con su problema y su caso de uso que ha encontrado en la web. Y luego Aaron y yo estuvimos, creo que fuimos, bueno, creo que organizamos seis o siete eventos dentro de una conferencia o una reunión.

Stephanie: Y entonces, la forma que toma es que generalmente tenemos una sesión de 45 minutos a una hora de duración en una conferencia con la que nos asociamos. Y damos a las personas que han enviado sus problemas que han encontrado en la web la oportunidad de presentarlos a un panel de jueces que generalmente son expertos de la industria.

Stephanie: Y en el medio generalmente tenemos cuatro o cinco de esos problemas presentados durante una sesión. Y entre cada uno de ellos tenemos nuestro panel de jueces que hablan sobre el espacio problemático que se está presentando. Y si es o no un espacio problemático interesante. O si creen que sería útil que los proveedores de navegadores trabajaran en eso.

Stephanie: Y luego, al final de esa sesión, nuestros jueces eligen lo que creen que es el problema más apremiante para solucionarlo. Y también tenemos un componente de audiencia, por lo que la audiencia de la sesión también puede votar sobre lo que creen que es lo más urgente que los proveedores de navegadores deberían solucionar.

Stephanie: Y luego llevamos esos datos a nuestros equipos. Y actualmente estamos en el proceso de descubrir cómo distribuir eso entre los diferentes equipos de navegadores.

Drew: ¿Hay algún tipo de destacado, sugerencias que recuerdes que te hayan quedado particularmente grabadas?

Stephanie: Entonces, ha habido un par, el que me sigue llamando la atención es el Control HTML que sigue apareciendo. Y eso me llama la atención porque estoy trabajando en una charla en este momento que involucra controles HTML y cómo simplemente no poder aplicarles estilo o extenderlos es un problema. Y es genial ver que los comentarios se reiteran aún más.

Stephanie: Ha habido algunos realmente interesantes, había uno para un orden de vista de fuente o un visor de orden de fuente en las herramientas de desarrollo que tenía que ver con, creo, aprovechar el contenido de la cuadrícula y ver, porque puedes mover las cosas fuera de orden, y tener ese tipo de identificación de cómo fluyen las cosas a través de los DOM. Entonces, creo que sería genial implementarlo en las herramientas de desarrollo.

Aaron: Sí, ha habido muchas presentaciones relacionadas con la accesibilidad que han sido muy buenas. Otro que estaba relacionado con las herramientas de desarrollo y la accesibilidad era en realidad, en lugar de relegar las pruebas de accesibilidad a su propia parte, era la pestaña de auditorías, creo que es donde está actualmente, como Lighthouse hace algunas pruebas de accesibilidad, o podría usar sugerencia web o información de accesibilidad y tal.

Aaron: La idea de esto es realmente comenzar a capturar algunas de las frutas más fáciles en términos de errores de accesibilidad y burbujear eso en la consola, por ejemplo. Por lo tanto, si ve que tiene algunas imágenes a las que les falta el texto alternativo o algunas fuentes realmente pequeñas o no tienen suficiente contraste, en realidad podría mostrarlas como errores en la consola. Y eso tiende a ser donde muchos desarrolladores verifican si sus cosas funcionan correctamente. Eso haría un poco más obvio para las personas que tienen problemas de accesibilidad que deben abordar.

Aaron: Y podría ver algunas formas similares de incorporar eso en el visor de Dom o en las herramientas de inspección de CSS donde podría marcar algo como un contraste demasiado bajo o resaltar un elemento que tiene algún problema de accesibilidad conocido. Ese tipo de cosas sería bastante interesante.

Stephanie: Sí, quiero aprovechar eso. De hecho, hubo uno realmente interesante presentado en View Source en Amsterdam el año pasado. Se trataba de que el navegador corrigiera automáticamente ciertos tipos de problemas de accesibilidad para usted. Y solo con color y contraste o tal vez ciertas fuentes son ilegibles. Y la propuesta y el estudio de caso presentado estuvo muy, muy bien pensado. Pero también plantea esta pregunta interesante de si el navegador comienza a arreglar las cosas para usted como desarrollador, ¿va a escribir código incorrecto porque no tiene que preocuparse por eso?

Stephanie: Así que fue interesante porque las ideas que presentó y demostró fueron realmente geniales. Pero eso es lo que significa eso para los desarrolladores, así que, ¿se van a volver perezosos? Entonces, he visto algunas cosas geniales salir de eso.

Drew: Así que supongo que aún es muy pronto para la iniciativa, ¿no? Así que supongo que no hemos visto nada tan lejos como para llegar a las primeras etapas de desarrollo con cualquier navegador. ¿Sabes cómo será ese proceso? Dijiste que todavía estabas tratando de resolverlo, ¿no es así?

Aaron: Sí, todavía estamos tratando de resolverlo, pero contamos con las personas adecuadas involucradas. Tenemos gente de Mozilla y de Google y de Igalia también, ellos fueron los que hicieron gran parte del trabajo de cuadrícula y están muy familiarizados con el funcionamiento de todo este material estándar. De hecho, creo que están haciendo Metanol en este momento, haciendo la implementación de WebKit.

Aaron: Así que sí, tenemos un grupo de personas a bordo que están ansiosas por trabajar en esto y ansiosas por ver que tenga éxito. Y el W3C también le está prestando atención, lo cual es genial.

Stephanie: Entonces, para nosotros en este momento, hemos tomado, creo que tenemos 12 mejores, tomamos los ganadores de cada evento el año pasado, y los he clasificado en sus categorías específicas. Entonces, algunos están enfocados en herramientas de desarrollo, otros están enfocados en HTML, plataforma web. Y luego no puedo recordar cuál era la tercera categoría, era algo general.

Stephanie: Y entonces, en el lado de Edge, estamos comenzando al menos a investigar, tendré un par de encuestas de Twitter que se publicarán en algún momento pronto para ayudar a recopilar más comentarios para validar que estos son espacios problemáticos en los que debemos invertir tiempo. adentro. Y luego, con suerte, partiremos de ahí. Así que espero que en algún momento de este año comencemos a ver algún tipo de progreso. Pero es un poco lento en este momento.

Drew: Es genial porque la web en realidad es una plataforma muy colaborativa. Y creo que, como desarrollador web que solo crea sitios en el día a día, olvida que en realidad hay formas de retroalimentar el proceso y formas de hacer que se escuche su voz. Y creo que esto suena como una manera realmente genial y fácil de hacer que su voz se escuche.

Drew: Si alguno de nuestros oyentes quisiera venir a una sesión de Web We Want , ¿hay alguna próximamente?

Stephanie: Hay un par, así que permítanme sacar mi lista aquí. Entonces, bueno, Open Source Festival en Lagos, Nigeria. Aaron y yo no estaremos allí, pero en realidad están organizando ese evento de forma independiente.

Stephanie: Y luego estaré en SF HTML5 en San Francisco a fines de marzo. Creo que es gratis, pero no me cites al respecto. Necesito verificar. Entonces, si está en el área de San Francisco, lo estamos administrando allí.

Stephanie: Y luego SmashingConf San Francisco en abril. Lo estaremos ejecutando allí.

Stephanie: Y con suerte TBD, todavía mirando SmashingConf Austin.

Stephanie: Y creo que eso es todo lo que tenemos en el calendario en este momento. Pero, vamos a hacer un pequeño comentario aquí, si organiza una conferencia o una reunión y desea que esta sesión enfocada en la comunidad se realice allí, comuníquese porque es realmente genial.

Drew: Por supuesto, los SmashingConfs son los mejores para ir, creemos aquí.

Stephanie: Sí, sí lo son.

Drew: Entonces, para mí eso suena muy, muy 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.