Por qué Safari 27 lanza 525 correcciones: notas desde el laboratorio de WebKit
Lo más revelador que dijo el equipo de Safari en la WWDC 2026 no tuvo que ver con una función. A lo largo de una hora en el laboratorio del grupo de Safari y Tecnologías Web, los ingenieros de WebKit volvían una y otra vez sobre la misma pregunta: ¿cómo decide un equipo de navegadores qué construir, y por qué tantas veces parece lento desde afuera? La respuesta a la que regresaban, parafraseada del laboratorio, era que de verdad les importa, y lo respaldan con un número que puedes comprobar. Safari 27 lanza 58 funciones nuevas y 525 correcciones, lo que WebKit llama “el mayor montón de correcciones en cualquier versión reciente de Safari”.1 Este artículo trata sobre el razonamiento que hay debajo de ese número, extraído del laboratorio y sustentado en las propias notas de versión de WebKit.
El Safari & Web Technologies Group Lab de la WWDC 2026.
En resumen
- Safari 27 lanza 58 funciones nuevas y 525 correcciones, la mayor cantidad de correcciones en cualquier versión de Safari.1 El laboratorio enmarcó este año como una campaña contra los pequeños fastidios: perseguir los bugs de corrección menores que hacen que la plataforma sea confiable, no solo las funciones de titular.
- El ejemplo más claro es una reescritura del cargador de módulos de JavaScript. Las notas de WebKit describen la corrección de “múltiples bugs de corrección de top-level await mediante una reescritura del ES module loader para cumplir con los estándares”, reemplazando una implementación basada en una propuesta abandonada de 2016 que es anterior a la existencia misma de top-level await.1
- El laboratorio usó el selector
:has()como caso de estudio sobre cómo se destraban los estándares en la práctica: una función que los ingenieros consideraron imposible durante años, hasta que la ingeniería de Igalia la hizo lo bastante rápida, y ahora se lanza en todos los motores principales.23 - La historia de los controles de formulario maduró:
appearance: base-selectelimina el estilo nativo de<select>para que partas de cero, mientras que la dirección más amplia de “dar estilo a cada control de formulario” sigue siendo una especificación sin resolver sobre la que el panel discrepó abiertamente.12 - WebKit y JavaScriptCore se ejecutan en todos los sistemas operativos de Apple, incluido watchOS, y SwiftUI ahora tiene un
WebViewde primera clase, así que “el motor web” se parece más a un servicio del sistema que a una sola app.24
El número y lo que significa
La forma en que WebKit enmarca Safari 27 es inusualmente cuantitativa. Más allá de las funciones nuevas, la versión trae 525 correcciones, “el mayor montón de correcciones en cualquier versión de Safari”.1 En el laboratorio, el equipo conectó ese número con una postura más que con un hito: el sentimiento parafraseado era que los desarrolladores web a veces interpretan las decisiones de un navegador como que no les importa su experiencia diaria, y la respuesta del equipo era la contraria, que no hay ninguna ventaja en empeorar la web en Safari.2 No tienes que aceptar ese sentimiento por fe, porque la cantidad de correcciones es la evidencia, y la propia descripción que hizo el laboratorio de las notas de versión fue que son tan largas que puedes pasar un buen rato desplazándote por ellas.2
La mejor ilustración de todas es una pieza de fontanería que la mayoría de los desarrolladores nunca ven. WebKit reescribió el cargador de módulos de JavaScript. Las notas de versión son específicas: el equipo “corrigió múltiples bugs de corrección de top-level await mediante una reescritura del ES module loader para cumplir con los estándares”, porque la implementación anterior estaba “basada en una propuesta abandonada de WHATWG Loader de 2016 que es anterior a la existencia misma de top-level await” y podía permitir que las importaciones accedieran a las exportaciones antes de que estuvieran completamente inicializadas.1 Reescribir un cargador de módulos para corregir toda una clase de bugs de orden de await es un esfuerzo enorme para algo que, hecho bien, nadie nota. Eso es la campaña contra los pequeños fastidios en un solo commit.
Cómo se destraba realmente un estándar: la historia de :has()
La narrativa más útil del laboratorio fue sobre el selector CSS :has(), el tan anhelado selector de padre. La versión parafraseada del panel: los ingenieros de navegadores dijeron que no durante buena parte de dos décadas, con el argumento de que los chips no eran lo bastante rápidos para evaluarlo sin destrozar el rendimiento de la página, hasta que por fin se hizo el trabajo para volverlo viable y se lanzó en todos los navegadores.2 La columna verificable que sostiene esa historia es real. WebKit lanzó :has() en Safari 15.4, Chromium lo siguió en Chrome 105 con la ingeniería liderada por la consultora de código abierto Igalia, y Firefox completó el conjunto en la versión 121, de modo que el selector que era “imposible” durante años ahora funciona en todos los motores principales.3
El laboratorio vinculó esto con un principio de diseño que vale la pena conocer por su nombre. La “prioridad de constituyentes” del proyecto HTML clasifica cuyas necesidades ganan cuando entran en conflicto: los usuarios sobre los autores, los autores sobre los implementadores, los implementadores sobre los especificadores, y todos ellos sobre la pureza teórica.5 Es la regla que explica por qué un navegador cargará para siempre con un feo apaño de compatibilidad antes que romper un sitio, y por qué una función que ayuda a los autores aún puede esperar años si implementarla perjudicaría a los usuarios por el rendimiento. :has() es esa regla resolviéndose en cámara lenta: útil para los autores, bloqueada por el costo para el usuario de hacerla rápida, y lanzada solo una vez que ese costo bajó.
El proyecto de los controles de formulario, y un desacuerdo en público
La capacidad de CSS más solicitada de la última década por fin está llegando: dar estilo a los controles de formulario nativos sin reconstruirlos a partir de <div>s. Safari 27 lanza appearance: base-select, que, en palabras de WebKit, te deja “eliminar el estilo nativo y empezar con una paleta limpia”, para luego superponer tu propio CSS conservando la semántica real del control, el manejo del teclado y la accesibilidad.1 Se combina con ::picker(select), ::picker-icon, ::checkmark y un elemento <selectedcontent>, la superficie de customizable-select que se cubre en dar estilo al elemento select real.
Lo que el laboratorio agregó fue la honestidad sobre lo inacabada que está la visión más amplia. Extender appearance: base a todos los controles de formulario es una dirección declarada, no una especificación lanzada, y el panel discrepó consigo mismo frente a las cámaras sobre la pregunta más difícil: cómo debería verse siquiera el punto de partida sin estilo. Parafraseando el intercambio, una postura era que un control sin estilo debería verse como un control moderno y sencillo; la réplica era que “moderno” es un objetivo de moda en constante movimiento y no algo que una especificación pueda fijar, así que la base debería heredar todo lo posible de la página y, por lo demás, sostener la menor opinión posible.2 La restricción de ingeniería en la que sí coincidieron es la parte genuinamente difícil: la función solo funciona si el renderizado por defecto y la estructura del DOM son idénticos en todos los navegadores, porque los autores darán estilo contando con ambos.2 Por eso un problema de 30 años sigue siendo un trabajo en curso y no una casilla marcada.
El motor web es un servicio del sistema
Un replanteamiento útil del laboratorio: WebKit es mucho más que Safari. WebKit y JavaScriptCore se incluyen en todos los sistemas operativos de Apple, incluido watchOS, que no tiene navegador alguno, y cualquier app que ejecute JavaScript se apoya en JavaScriptCore.2 El propio material de la WWDC de WebKit hace el mismo planteamiento, al describir interfaces de apps “impulsadas por el HTML, CSS y JavaScript que renderizan WebKit y JavaScriptCore, los mismos motores que hay dentro de Safari”, en todas las plataformas.1 La consecuencia práctica para los desarrolladores llegó en 2025, cuando SwiftUI ganó un WebView nativo y un modelo WebPage, convirtiendo a WebKit en una vista de primera clase de SwiftUI en lugar de un WKWebView envuelto en UIViewRepresentable.4 Cuando el motor web está tan dentro del sistema operativo, “¿esto debería ser nativo o web?” deja de ser una decisión binaria.
Qué lanza WebKit primero, y qué construye después
Hay dos hilos más pequeños que merecen la atención de un desarrollador. Primero, Safari sigue lanzando funciones de CSS por delante de otros motores: hanging-punctuation ha sido exclusiva de Safari durante años, la función CSS filter() (distinta de la ampliamente compatible propiedad filter) sigue siendo solo de WebKit, y Safari lanzó hace poco la función random(), con una random-item() acompañante para elegir entre valores discretos definidos en el borrador de CSS Values.67 El reflejo de “Safari va atrasado” pasa por alto con cuánta frecuencia va primero.
Segundo, la historia de las extensiones web se está consolidando. El esfuerzo multinavegador de WebExtensions está pasando de un grupo comunitario de varios años hacia un Grupo de Trabajo formal del W3C, con un borrador de estatutos de 2025 que apunta a una especificación de interoperabilidad real.8 Y Apple anunció un giro de cara al consumidor en la keynote de la WWDC 2026: “Describe an Extension”, que usa Apple Intelligence para generar e instalar una extensión personalizada de Safari a partir de una descripción en lenguaje natural, sin Xcode y sin pasar por la App Store.9 Tómalo como un anuncio de keynote más que como una API para desarrolladores, pero la dirección es clara: la superficie de extensiones se está ampliando a la vez tanto en la capa de estándares como en la capa del usuario final.
Qué quedarse de todo esto
El laboratorio es una ventana a un compromiso que la mayoría de la cobertura de funciones omite. Un equipo de navegadores puede perseguir funciones de titular o perseguir la corrección, y WebKit pasó esta versión eligiendo visiblemente lo segundo: 525 correcciones, un cargador de módulos reescrito para toda una clase de bugs de await, un selector de padre que esperó dos décadas a que el hardware lo alcanzara. La lección para cualquiera que construya sobre la plataforma es leer las notas de versión, no la keynote, cuando quieras saber qué mejoró de verdad. Las funciones están en customizable select, CSS Grid Lanes y el elemento HTML model; el razonamiento detrás del ritmo está en el laboratorio.
Preguntas frecuentes
¿Cuántas correcciones tiene Safari 27?
525 correcciones junto con 58 funciones nuevas, lo que WebKit describe como la mayor cantidad de correcciones en cualquier versión de Safari.1 El laboratorio enmarcó el año en torno a la corrección y los “pequeños fastidios” más que a las funciones de titular.
¿Qué es la reescritura del cargador de módulos?
WebKit reescribió el ES module loader de Safari para cumplir con los estándares, corrigiendo múltiples bugs de corrección de top-level await. La implementación anterior estaba basada en una propuesta abandonada de WHATWG Loader de 2016 que es anterior a top-level await, y podía permitir que las importaciones accedieran a las exportaciones antes de que estuvieran completamente inicializadas.1
¿Se está lanzando appearance: base?
appearance: base-select se lanza en Safari 27 para el elemento <select>, eliminando el estilo nativo para que puedas aplicar tu propio CSS conservando la semántica del control.1 Extender appearance: base a todos los controles de formulario es una dirección declarada pero una especificación sin resolver, y el panel del laboratorio discrepó abiertamente sobre cómo debería verse el valor por defecto sin estilo.2
¿De verdad Apple agregó extensiones de Safari generadas por IA?
Sí. Apple anunció “Describe an Extension” en la keynote de la WWDC 2026: usa Apple Intelligence para generar e instalar una extensión personalizada de Safari a partir de una descripción en lenguaje natural, sin Xcode ni la App Store.9 Es una función para el consumidor, no una API para desarrolladores.
Los artículos sobre funciones de Safari cubren el qué: dar estilo al <select> real, CSS Grid Lanes para masonry nativo y el elemento HTML <model>. Este cubre el porqué detrás del ritmo. El hub completo de la serie es la Serie del Ecosistema de Apple.
Referencias
-
WebKit, News from WWDC26: WebKit in Safari 27 beta. Source for the 58 new features and 525 fixes (“the largest pile of fixes in any Safari release”), the ES module loader rewrite (“Fixed multiple top-level await correctness bugs with a rewrite of the ES module loader for standards compliance,” replacing an implementation “based on an abandoned 2016 WHATWG Loader proposal that predated top-level await entirely”), the
appearance: base-selectdescription (“clear the native styling and start with a clean palette”) with::picker(select)/::picker-icon/::checkmark/<selectedcontent>, and the framing of WebKit and JavaScriptCore as the engines behind app interfaces across Apple platforms. ↩↩↩↩↩↩↩↩↩↩↩ -
Apple, WWDC 2026 session 8015, Safari and Web Technologies Group Lab. Paraphrased from a locally transcribed recording; Apple publishes no official captions for the labs, so the wording here is a paraphrase, not a quotation, and exact phrasing is unverified. Source for the team’s caring-about-the-platform framing tied to the length of the release notes, the
:has()narrative that engineers resisted it for roughly two decades on performance grounds, the live disagreement over the unstyledappearance: basebaseline (modern-control vs inherit-from-page) and the cross-browser identical-rendering-and-DOM-structure constraint, and the point that WebKit/JavaScriptCore run on every Apple OS including watchOS. ↩↩↩↩↩↩↩↩↩↩ -
WebKit, Using :has() as a CSS Parent Selector and much more, and the cross-engine shipping record: Safari 15.4, Chrome 105 (engineering led by Igalia), Firefox 121. Source for
:has()shipping in all major browser engines after years of being considered infeasible. ↩↩ -
Apple, WebKit for SwiftUI and WWDC 2025 session 231, Meet WebKit for SwiftUI. Source for SwiftUI’s native
WebViewandWebPagemodel introduced in the 2025 releases, making WebKit a first-class SwiftUI view. ↩↩ -
W3C, HTML Design Principles: Priority of Constituencies. Source for the ordering “users over authors over implementors over specifiers over theoretical purity.” ↩
-
MDN / caniuse,
hanging-punctuationand the CSSfilter()function. Source for both being supported in Safari/WebKit and not in Chrome or Firefox at time of writing (thefilter()function is distinct from the widely supportedfilterproperty). ↩ -
W3C, CSS Values and Units Module Level 5, which defines
random()andrandom-item(). Safari has shipped therandom()function;random-item()selects among discrete keyword or property values. ↩ -
W3C, WebExtensions Community Group and the 2025 draft WebExtensions Working Group charter. Source for the cross-browser WebExtensions effort moving from a community group toward a formal Working Group. ↩
-
Apple announced “Describe an Extension” at the WWDC 2026 keynote, generating and installing a custom Safari extension from a natural-language description via Apple Intelligence, without Xcode or the App Store. Reported by MacRumors, June 8, 2026. Described here as a keynote announcement and consumer feature, not a developer API. ↩↩
