The Future of Style aggregates posts from various blogs that talk about the development of Cascading Style Sheets (CSS) [not development with Cascading Style Sheets]. While it is hosted by the W3C CSS Working Group, the content of the individual entries represent only the opinion of their respective authors and does not reflect the position of the CSS Working Group or the W3C.
Safari 17.4 adds vertical writing mode support for form control elements across macOS, iOS, iPadOS, and visionOS.
Setting written text vertically is commonly observed in East Asian languages. For example, Chinese, Japanese, and Korean (CJK) may be written vertically and read top-to-bottom, flowing in lines from right to left. Similarly, Traditional Mongolian is a vertical script that flows in lines from left to right.
Support for
vertical text has been available in browsers for several years
using the CSS
writing-mode
property. However, until recently, support
for the vertical-lr
and vertical-rl
values for form controls was inconsistent among all browsers.
Consequently, as part of Interop 2023, the industry
committed to working towards vertical writing mode support in form
controls. We are excited to see
cross-browser support improve considerably. And we are proud
that Safari
17.4 brings support for vertical writing modes to form controls
everywhere you find Safari.
Adopting vertical form controls is as simple as adding a CSS
declaration using the writing-mode
property and
applying it to your controls. For a right-to-left block flow
direction, as observed in CJK languages, use writing-mode:
vertical-rl
. Or, for a left-to-right block flow direction,
use writing-mode: vertical-lr
.
button, textarea, progress, meter, input, select {
writing-mode: vertical-rl;
}
Support for vertical writing mode is available for the following
elements: <button>
,
<textarea>
, <progress>
,
<meter>
, <input>
, and
<select>
. WebKit is committed to supporting
vertical writing modes on any new controls moving forward,
including <input
type="checkbox" switch>
, which was also added in
Safari
17.4.
Note that in all browsers, any popup UIs associated with form
controls, such as the menu for a <select>
element, or the color picker for an <input
type="color">
are still displayed horizontally.
Adding vertical writing mode support for form control elements in WebKit was a large undertaking that involved over 10 unique types of controls. Below are some of the changes that were needed to support this feature in WebKit.
WebKit’s user-agent stylesheet made frequent use of physical
properties, such as width
, height
, and
margin
. In order to support vertical writing modes,
this usage was updated to use logical properties, such as
inline-size
and block-size
, where
appropriate.
Form controls in WebKit make heavy use of custom layout code. While the interfaces were designed to support logical properties, the implementations often assumed a horizontal writing mode. We updated the methods to compute logical widths to ensure they considered the writing mode.
Additionally, custom baseline adjustment logic, which makes controls such as checkboxes and radio buttons look great alongside text, was updated to use the central baseline for vertical writing modes. This ensures that controls continue to look great alongside text in a vertical writing mode.
Rendering form controls with a vertical writing mode required unique changes depending on the control and system capabilities.
On macOS, WebKit’s form controls match the look and feel of the
operating system. However, macOS itself does not support vertical
writing modes. Consequently, some controls, such as
<progress>
, are simply rotated after obtaining
the system image in order to support vertical rendering.
Other controls cannot simply be rotated due to details such as
shadows, for example <select>
, so we used a
custom fallback rendering approach.
If a control was already custom painted in WebKit, it was
updated to use logical coordinates rather than physical
coordinates. We used this approach throughout the iOS rendering
code and it was also necessary in our rewrite of the listbox
(<select multiple>
) on macOS.
Finally, some controls, such as checkbox and radio buttons, did not require any rendering changes. As “glyph-like” controls, they look the same in all writing modes.
WebKit remains committed to improving internationalization support in our engine. By adding vertical writing mode support for form control elements in Safari 17.4, we hope to empower authors to create the best content for their local and global communities.
A special thanks goes to Tim Nguyen, who kicked off the vertical form controls project in WebKit, and Alan Baradlay, whose deep knowledge of CSS layout proved invaluable in driving the project to the finish line.
We love hearing from you. Send a tweet to @webkit to share your thoughts on this feature. Find us on Mastodon at @jensimmons@front-end.social and @jondavis@mastodon.social. You can also follow WebKit on LinkedIn. If you run into any issues, we welcome your WebKit bug reports on WebKit features like this. Reporting issues makes an enormous difference.
You can also download the latest Safari Technology Preview to try out new web platform features like this before they appear in a Safari beta.
Webpage | DOM size | Max depth |
---|---|---|
amazon.com | 3746 | 22 |
youtube.com | 9082 | 30 |
Google results page | 3458 | 48 |
reddit.com | 4460 | 21 |
MDN Promises article | 4167 | 17 |
walmart.com | 3382 | 25 |
Facebook (after scrolling) | 9957 | 63 |
Gmail (opened email) | 3494 | 69 |
HBO Max | 5478 | 19 |
Airbnb.com (login and open filters) | 3388 | 38 |
Adobe Photoshop (Quick Actions panel) | 6751 | ≥ 24 |
Adobe Photoshop (Text Box new) | 6331 | ≥ 31 |
bbc.com/news/world | 3898 | 26 |
nationalgeographic.com | 4111 | 23 |
Google docs | 3558 | 15 |
Google sheets | 5730 | 18 |
Stack overflow post | 2521 | 19 |
Microsoft Outlook | 2870 | 32 |
Microsoft Teams | 2542 | 32 |
apple.com/apple-vision-pro | 2857 | 18 |
2488 | 59 | |
timesofindia.indiatimes.com | 2789 | 22 |
.r9gx1vl:not(:checked) ~ .fui-Radio__indicator >
*
.f17xb19f > :not(.fui-CardPreview__logo)
.appContainer-459 ::after
.r1no3lux pre[class^='language']>code
.fiiet6c span:nth-child(1)
.f15hebdy>div>div>div
.flp1aja span:not(.giphy-gif)
img:not([itemtype*="Emoji"])
.f1mj8y37>*:not(.ms-StackItem)
#root ~ script[src*="cdn-client.medium.com"] ~ div >
div:not([role]):not([tabindex]):not([id]):not([class*="jfk"]):not([class*="gtx"])
._1WiHgiOg6qjeGNfJmJm0hu .o365cs-base
[class^="ms-Icon--"]::before
.todo-area .todo-list li .toggle:checked +
label
.reminder-group .high-priority:hover > :checked ~
label
.high-priority
class. However, a todo element would
partially match the rightmost portion of the selector, i.e.,
:checked ~ label
.
As announced on browserbench.org today, in collaboration with other browser engine developers, Apple’s WebKit team is excited to introduce Speedometer 3.0, a major update that better reflects the Web of today. It’s built together by the developers of all major browser engines: Blink, Gecko, and WebKit with hundreds of contributions from companies like Apple, Google, Intel, Microsoft, and Mozilla. This post is a deep dive into how the collaborative Speedometer project improved the benchmark’s measurements methods and test content.
To recap history, in 2014, the WebKit team at Apple released the Speedometer browser benchmark, designed to measure the responsiveness of websites and web apps.
The original Speedometer simulated user interactions in web applications, driving TodoMVC sample apps written using different JavaScript frameworks to add, complete, and remove todo items. It was unlike other DOM or web app benchmarks publicly available at the time. These older benchmarks were mostly collections of micro-benchmarks, and didn’t reflect how DOM APIs were used in real web apps, or how individual APIs interacted with the rest of the web browser engine. Speedometer quickly became an important tool for performance measurement and tuning not just in WebKit but also in other browser engines.
In 2018 the WebKit team, in collaboration with Google’s Chrome team, released Speedometer 2.0, updated to use the latest frameworks and libraries available at the time. The Speedometer benchmark has since gained even more popularity among browser engines as a guide for optimization, and among independent testers and reviewers to compare different devices, operating systems, and browsers.
Today’s release of Speedometer 3.0 marks a major step forward in web browser performance testing. It improves the accuracy of measurement and measures the performance of a wide variety of contents.
Speedometer 3.0’s release is a result of the collaboration among browser developers to improve the Web as a whole together. Much as Interop 2024 represents joint work to test and improve standards compliance, Speedometer 3.0 is a joint effort to test and improve browser performance.
Where previous Speedometer versions were developed as part of the WebKit project, Speedometer 3.0 has been developed and released under a joint multi-stakeholder governance model including the three major engine browsers: Blink, Gecko, and WebKit, and the repository has received hundreds of open source contributions since the original announcement in December 2022. This collaboration better ensures fairness in measurement and workload composition. And together, the group created a shared vision for the benchmark.
We’ve improved the way Speedometer measures runtime performance. Prior Speedometer versions measured the time to run a test script synchronously as “sync” time; and the time until a zero-delay timer scheduled at the end of “sync” work fires as “async” time, as shown in the following diagram:
However, this method sometimes misses important work that browser engines do in response to script-driven changes, because synchronous tasks and the zero-delay timer are scheduled without considering the timing of rendering updates. It also didn’t capture any work frameworks delay until the next requestAnimationFrame (rAF) callback, a common technique in modern frameworks. The following diagram illustrates how important work could be missed by the time calculations.
Speedometer 3.0 takes advantage of the fact that all browser engines have adopted the HTML5 event loop model for updating the webpage rendering. It measures test scripts within a requestAnimationFrame callback as “sync” time, and the time to fire zero-delay timer scheduled in a second requestAnimationFrame as “async” time:
Because the zero-delay timer is now scheduled in a second requestAnimationFrame, it’s guaranteed to be fired after all the zero-delay timers scheduled during the synchronous portion of the test had fired. Thanks to HTML5’s event loop processing model, browser engines update the rendering of web pages after all requestAnimationFrame are called before the next zero-delay timer fires. These changes greatly improved Speedometer’s ability to accurately measure the runtime of synchronous work and asynchronous work browsers do in response to script that handles user events.
The test harness has also been rewritten to use modern JavaScript features like modules, native promises, let & const, async & await, and class syntax, which were not widely available at the time Speedometer 1.0 was first written.
Like its precursors, Speedometer 3.0 sums up the runtime taken to simulate user actions such as adding todo items, completing them, and removing them per each workload, and computes the geometric mean of the totals across different workloads. The final score is calculated as the arithmetic mean of the reciprocal of the geometric mean:
Since Speedometer’s benchmark content was last updated in 2018, web browsers have gotten increasingly better at handling Speedometer content. Moreover, new hardware, such as Apple Silicon Macs, continues to push the boundary of what’s possible in computing. Where originally scores were scaled to be under 100, modern browsers now can score over 500 on the fastest devices. To make scores easier to compare and to make room for future improvements, we’ve adjusted the score so that a typical web browser will get a score in the 20-30 range to start out.
Now let’s take a look at the test content in Speedometer 3. Like the past versions of Speedometer, version 3.0 includes TodoMVC-based todo apps that emulate adding, completing, and removing todo items. To better represent the modern Web, the most widely used JavaScript UI frameworks were identified from the HTTP Archive in March 2023:
The monthly downloads in NPM was also taken into account to find frameworks with high momentum:
Based on these data points, we’ve included the following JavaScript frameworks in our todo apps: Angular, Backbone, jQuery, Lit, Preact, React, React+Redux, Svelte, and Vue. For each framework, the most commonly used version at the time was picked. Todo implementations written in vanilla JavaScript using ES5, ES6, and web components are also included.
In addition, Speedometer 3.0 includes “complex DOM” versions of some of the TodoMVC applications. In these complex DOM versions, each todo app is embedded inside a UI structure which mimics a web application with many deeply nested DOM nodes and plenty of CSS rules. Even though the benchmark still emulates the same set of operations, doing so in the context of more DOM elements and CSS rules adds work and captures additional performance bottlenecks.
In order to ensure the variety of performance scenarios to be tested, Speedometer 3.0 includes 6 simple DOM todo applications and 6 complex DOM todo applications.
Together, these changes to todo apps dramatically improved the coverage of the benchmark. But Speedometer 3.0 takes it a step further and includes entirely new kinds of applications.
Speedometer 3.0 includes two test apps that mimic typical news sites, built using the popular single page application frameworks Next.js and Nuxt. It emulates user actions such as clicking on menu items and navigating to another page in the single page app setup.
Speedometer 3.0 also includes four charting applications based on Observable Plot, chart.js, React stockcharts, and WebKit’s performance dashboards. Observable Plot and React Stockcharts are based on D3 and test manipulating SVG-based graphics. Chart.js and WebKit’s performance dashboards test drawing canvas-based graphics.
Finally, Speedometer 3.0 has added two text editing applications: a JavaScript code editor built with CodeMirror and a WYSIWYG editor built with TipTap. In both scenarios, it emulates the steps to create a new editable region, loading a large amount of text, and syntax highlighting or boldening text:
The addition of these new applications dramatically broadens the scope of what Speedometer 3.0 measures, and provide new opportunities for browser engines to optimize a broad spectrum of features like JavaScript, style, layout, graphics, and DOM.
Today marks a remarkable milestone for the Web platform.
Speedometer 3.0 sets a whole new standard for measuring web browser
performance. As browser developers optimize their engines, this
will expand the horizon of what Web developers can achieve in the
years to come. Because the goal of the Speedometer benchmark is to
reflect the real-world Web as much as possible, we’re expecting
this benchmark to evolve over time. We’ll be regularly updating the
list of frameworks to be tested, and periodically updating the
tested framework’s versions to reflect the real world usage. You
can
try Speedometer
3 benchmark on browserbench.org. If you have any
feedback or questions, feel free to file issues on Github.
Safari Technology Preview Release 190 is now available for download for macOS Sonoma and macOS Ventura. If you already have Safari Technology Preview installed, you can update it in System Settings under General → Software Update.
This release includes WebKit changes between: 274067@main…274941@main.
safe
keyword in flexbox
properties. (274304@main)
(118000717)getComputedStyle()
to work with functional
pseudo-elements like ::highlight()
. (274846@main)
(117864743)History
to throw a
SecurityError when not in a fully active Document. (274260@main)
(118750576)shadowrootclonable
attribute
and aligned with declarative shadow root standards changes. In
particular, web developers will now have to set this attribute if
they want their declarative shadow root to be clonable. (274727@main)
(123006751)eval()
in a default value expression inside
a rest parameter creates a variable in the environment of the
function rather than the separate one of the parameters;eval()
, or a closure
created in a default value expression of a preceding parameter, but
only if there is a var
binding by the same name;var
bindings. (274109@main)
(121961421)VTTRegion.track
. (274936@main)
(123172214)backdrop-filter
to apply to the border area
of an element with a border-radius
. (274757@main)
(122295068)turn
unit in
<angle>
. (274778@main)
(120840743)cursor: pointer
matching standards. (274422@main)
(122715957)captureStream
stuttering with WebGL.
(274454@main)
(122471664)We’re very excited to introduce a new HTML form control as part of Safari 17.4: a switch.
Two switches as seen on iOS, with the second switch using a custom CSSaccent-color
.
The HTML for this example looks roughly like this:
<style> .special { accent-color: papayawhip } </style>
<input type=checkbox switch checked>
<input type=checkbox switch checked class=special>
Switches are a popular control on mobile platforms as well as in a large variety of UI frameworks, but until now they were not built into the web platform. Seeing the widespread need for this control we decided to change that.
The way we approached this is consistent with how other new form controls have been added to HTML:
<input type=url>
will treat it
as <input type=text>
. Likewise, a browser that
does not support <input type=checkbox switch>
will treat it as <input type=checkbox>
.:indeterminate
pseudo-class never matches.switch
role, announcing the states “On” and
“Off” just like a switch from the OS. On macOS, if you enable
“Differentiate Without Color”, or on iOS, if you enable “On/Off
Labels”, the switch will show accessibility indicators.<input
type=checkbox>
, if you use appearance: none
,
you get full control over its appearance as a web developer. It
goes even a bit further as we ensured all properties will have
their initial values when you use appearance: none
.
(See also the experimental ::thumb
and
::track
pseudo-elements explained below for planned
enhancements in this area.) Control over styling is more limited
with appearance: auto
(the default). The
accent-color
property is supported and will be applied
to the switch’s “track” background, as demonstrated in the image
above.We’d love to see what you do with it and what else you would like this control to do.
Generally, we recommend using a switch when the end user understands the user interface element as a setting that is either “on” or “off”. A checkbox is well suited for when the end user would understand the element as something to be selected.
::thumb
and ::track
pseudo-elementsIn Safari if you go to Settings → Feature Flags, you can enable “::thumb and ::track pseudo-elements”, which gives web developers more control over the individual parts that make up a switch: its thumb and track. Essentially, this turns a single element into three, one parent with two sibling children.
We decided not to ship these pseudo-elements for now to give the
standardization process additional time to finalize how they should
work. We also want to make sure that when we ship them, they work
for the other HTML controls they are designed for, such as
<input type=range>
. This way
@supports(::thumb)
will be all the feature detection
you need.
We’d love to hear what you make of this new HTML form control. Send a tweet to @webkit to share your thoughts on this feature. You can find us on Mastodon at @jensimmons@front-end.social and @jondavis@mastodon.social. You can also follow WebKit on LinkedIn. If you run into any issues, we welcome your WebKit bug reports on WebKit features like this. Reporting issues makes an enormous difference.
You can also download the latest Safari Technology Preview to try out new web platform features like this before they appear in a Safari beta.
And finally, a big thank you to Lily Spiniolas for doing a lot of work on this feature during her internship at Apple. Not just prototyping an implementation in WebKit, but also creating a pull request for the HTML Standard and carefully thinking through many aspects of its design.
Just like Safari 15.4 and Safari 16.4, this March’s release of Safari 17.4 is a significant one for web developers. We’re proud to announce another 46 features and 146 bug fixes.
You can experience Safari 17.4 on iOS 17.4, iPadOS 17.4, macOS Sonoma 14.4, macOS Ventura, macOS Monterey, and in visionOS 1.1.
It’s always exciting to ship new features that you can use while building websites and web apps for your users. WebKit engineers also work on many important projects beyond implementing new web platform features. Recently, much effort has gone into multiple infrastructure projects that strengthen WebKit for the long-term.
We completed the final installment of our multi-year long rewrite of our inline layout engine (more on that later). We built two new iOS frameworks with hundreds of new APIs to support functionality used by web browsers, including multiprocess, JIT, and advanced keyboard & touch event access — and we are pivoting WebKit to use these new frameworks. We’re working on several other large projects that deepen security and privacy. And we’ve been hard at work to make Safari even faster. For many years, Safari has held the crown of the world’s fastest browser. It’s important to us to keep pushing the boundaries of speed, as the websites you build continue to get more complex. Hundreds of recent changes result in Safari 17.4 showing a significant performance bump.
Safari 17.4 brings two improvements to web apps on Mac.
First, Safari adds support for the
shortcuts
manifest member on macOS Sonoma. This gives
you a mechanism in the manifest
file for defining custom menu commands that will appear in the
File menu and the Dock context menu.
A web app shortcut consists of a name
, (the words
you’d like to appear in the menu), and a url
. When a
user activates the command, it opens the specified URL inside the
web app.
"shortcuts": [
{
"name": "New Kitten",
"url": "/new-kitten"
},
{
"name": "Discover",
"url": "/discover"
}
]
Users can set up custom keyboard shortcuts for app menu commands in System Settings > Keyboard > Keyboard Shortcuts > App Shortcuts. By default, macOS does not assign web app shortcuts any keyboard commands.
Second, Safari 17.4 now supports the
categories
manifest member on macOS Sonoma. This
member
provides you with a mechanism for telling the browser which
categories
your web app belongs in. On Mac, when a user creates a Launchpad
folder that contains web apps, the folder is automatically named
accordingly.
The switch is a popular interface for many use cases, but until
now, there was no easy way to put a switch on the web. Instead
developers might use a checkbox input field, remove the visual look
of the checkbox with appearance: none
, and write
custom styles to create something that looks like a switch.
Now, with WebKit for Safari 17.4, HTML supports a native switch.
If you code <input type="checkbox" switch>
, the
browser will simply create a switch for you, and map it to
role=switch
and related ARIA features.
Try this demo in Safari 17.4. Currently, in other browsers you will see three checkboxes.
Extending the current HTML checkbox provides several benefits
and honors the W3C’s HTML Design
Principles. First, this design degrades
gracefully — which means you can use <input
type="checkbox" switch>
today. Browser that have support
will show a switch, while browsers that do not have support will
show a checkbox. No user will get a broken experience, and you
don’t have to wait until all of your users have a browser with
support in order to utilize this on your website or web app. This
design also
does not reinvent the wheel. It matches the way form controls
have always worked on the web, and feels just like the code you’re
used to. It’s an incremental
evolution of the web. And as a simple solution, it
avoids needless complexity.
The accent-color
property can be used to change the
background color of the switch in the “on” state. And, exactly like
other form controls, you can use appearance: none
to
remove the system default styling and apply your own, perhaps while
leveraging :before
and :after
.
In the future, there will likely be multiple pseudo-elements to
make it even easier to style the switch with your custom styles.
You can try out ::track
and ::thumb
in
Safari Technology Preview today and let us know what you think of
this approach. See how they work in this demo, after
enabling the “::thumb and ::track pseudo-elements”
feature flag. (These pseudos are waiting to ship until there is
a more comprehensive plan for styling form controls proposed,
discussed and resolved on at the CSS Working Group.)
From the beginning, the web has always been interactive. Even before any method of custom styling was available, form controls and input fields provided the means for users to communicate back to the website and to each other. The web was also originally designed in an era when the Latin alphabet (used by many languages, including English) was the presumed default, with its horizontal top-to-bottom writing mode.
For thirty years, form controls have presumed a horizontal writing mode. Typesetting in a vertical writing mode for languages like Chinese, Japanese, Korean, and Mongolian did not include vertical form controls. Now that’s changed. Starting in Safari 17.4, vertical form controls are supported. This includes meter, range, progress and other form controls that could make for great UI in any language when laid out in a vertical format.
Try this demo of vertical form controls in a browser that has support.You can use an
<hr>
element (a horizontal rule) inside a
<select>
element to draw a separator line. WebKit
shipped support in Safari
17.0 on macOS. Now, Safari 17.4 on iOS 17.4, iPadOS 17.4, and
in visionOS 1.1 also has support.
Try a demo and read the story of how hr
in
select
was supported years ago, went away, and is now
restored.
WebKit for Safari 17.4 also adds support for the
showPicker()
method for <input
type="date">
on macOS.
One of the infrastructure projects that’s been underway in WebKit during the last several years is the complete rewrite of our inline layout engine. Safari 17.4 marks the completion of this project and the retirement of the twenty-one year-old legacy line layout engine.
Inline layout is integral to displaying content on the web. It determines the size and layout — wrapping, justification, spacing, and baseline alignment — of all text and other inline-level content. As developers, we often focus on the invisible block boxes on a web page and write CSS to layout those boxes using Flow, Tables, Flexbox or Grid. The content inside those boxes is placed using complex inline layout algorithms that developers often don’t need to think much about.
We’ve been shipping our new inline layout engine incrementally for many years. As more and more of the new engine was complete, more and more of the content on web pages was positioned by the new engine. This means users have been benefiting from WebKit’s new inline layout engine for a while. The legacy system was only triggered if there were something that hadn’t been yet implemented in the new engine. The last major step needed was the reimplementation of Ruby — and now it’s also a proper inline layout feature, fixing past inconsistencies.
Projects like these can be disruptive. Often browser teams will choose to not ship any new features while a multi-year rewrite project is in progress. WebKit instead chose to keep shipping new features, often implementing them twice — once in the legacy line layout engine, and again in the new inline layout engine. Now that this work is done, we no longer have to implement anything twice. This work also let us go through a large number of bugs reported on bugs.webkit.org, confirm they are no longer a problem, and close them as fixed.
We’re excited for WebKit’s future with this new engine. This investment results in increased interoperability by aligning to the latest web standards, fewer inline layout bugs, better performance, improvements to stability, and the ability to implement new features far more easily. The completion of inline layout also marks the beginning of rewriting the layout engine for other formatting contexts, starting with Flexbox.
When Flexbox shipped, it brought a powerful new tool to the web
—
box alignment. The
align-content
property made it possible to easily
vertically center content inside a box! Or you could use it to
align content to the bottom to the box, to align baselines of text,
and more. When CSS Grid shipped, box alignment became possible in a
second layout mode. Since 2017, you’ve been able to align the
direct children of both Flexbox and Grid containers.
Now, we are proud to be the first browser shipping support for
align-content
inside two more formatting contexts —
block layout and table layout. This means if all you want to do is
align a box’s content in the block direction, you don’t need to
involve Flexbox or Grid. Plus, you can now mix alignment with
floats, and you can use it inside table cells.
div { align-content: center; } /* one-line vertical centering */
In addition, we updated the handling of
align-content
and justify-content
on
scroll containers in WebKit for Safari 17.4. Now, for example, you
can use CSS to set the initial scroll position to the end rather
than the start of the content.
div { overflow: auto; align-content: unsafe end; } /* end-aligned scroller */
Be sure to test alignment on scroll containers across browsers, as many are still in the process of updating to the specified behavior. Those that have not yet updated may clip content.
Websites today can be complex, with large teams working across
multiple projects, relying on pattern libraries or frameworks to
keep everything organized and consistent. It can become tough for
large teams to handle how their CSS cascades. Tools like Cascade
Layers and :has()
have changed the game, allowing
developers to apply styles more masterfully. Yet, developers often
want a way to scope styles to the individual component they’re
working on, without worrying about the big picture or preventing
unintended consequences.
CSS Scoping was created to provide several more powerful options for organizing and structuring CSS. (Note, there have been many debates over many years on how style scoping might work. Search results for “CSS scoping” often yield old, unimplemented or completely different ideas.)
WebKit for Safari 17.4 adds supports the @scope
rule and expands the capabilities of the :scope
pseudo-class. Scoping changes how the cascade works in some
surprising ways, so do be sure to read about its impact before
deploying widely.
If your project is making heavy use of components, constructed independently and loaded in random order, scoping can help you by ensuring certain styles only apply to the contents of a specific element, and never to anything else on the page.
By default, all CSS on a project applies universally. It has a
“scoping root” of <html>
. And the :root
pseudo-element refers to the root element in the DOM — the
html
element. CSS Scoping lets you use
<style> @scope
to reset the scoping root to a
certain element, to the parent of the <style>
element.
<article id="my-component">
<style>
@scope {
h1 { font-size: 4rem; }
}
</style>
<h1>This is 4rem text.</h1>
</article>
<h1>This will not be styled by the CSS above.</h1>
In this case, because <article>
is the direct
parent of <style> @scope
, all of the styles
defined inside @scope
will only impact
article
and the content inside article
.
Nothing outside article
is affected.
But that’s not all CSS Scoping can do. Let’s imagine we want to
apply styles to a sidebar, but we don’t want those styles to apply
to everything in the sidebar. We can use @scope
to
create a donut of sorts — with a hole in the middle where the
styles don’t apply.
@scope (aside) to (section) {
h2 {
font-size: 3rem;
}
}
<aside id="my-sidebar">
<h2>This is 3rem text.</h2>
<section>
<h2>This is not styled by the CSS above.</h2>
</section>
</aside>
You can try this
demo in a browser with support.
By defining a scoping root with a scope-start selector
(aside
) and a scoping limit with a scope-end selector
(section
), we can effectively stop the cascading of
the styles.
Also, anytime you use CSS Scoping, it radically changes what happens when there’s a tie in specificity.
Since the creation of CSS, when multiple selectors have equal specificity, the one that appears last in the CSS cascade is the one that gets applied. For example, if this is your CSS:
.blue h1 { color: blue; }
.yellow h1 { color: yellow; }
Then this is your result.
<section class="blue">
<section class="yellow">
<h1>This headline is yellow.</h1>
</section>
</section>
<section class="yellow">
<section class="blue">
<h1>This headline is yellow.</h1>
</section>
</section>
The headline is always yellow, because .yellow
comes later in the CSS file. The order in the HTML does not
matter.
But with scoping, the selector that applies to an element that’s closer in the DOM to the scoping root is the one that will apply when their specificities are tied.
Let’s use @scope
instead of descendant
selectors:
@scope (.blue) {
h1 { color: blue; }
}
@scope (.yellow) {
h1 { color: yellow; }
}
Now, the headline color is determined by the DOM order in HTML, not the cascade order in CSS:
<section class="blue">
<section class="yellow">
<h1>This headline is yellow.</h1>
</section>
</section>
<section class="yellow">
<section class="blue">
<h1>This headline is blue!</h1>
</section>
</section>
The headline is yellow when .yellow
is the closer
ancestor, and it’s blue when .blue
is the closer
ancestor.
This is a fundamental change to how CSS works, so don’t get caught off guard. Use CSS Scoping with a lot of thought and care.
Note that a selector like .blue h1 { }
has higher
specificity than a selector like @scope (.yellow){ h1 {
}}
. The specificity of the scoping root’s selector is not
added to the specificity of the selectors inside the
@scope
rule, unlike Nesting. And .blue h1
is higher specificity than h1
.
WebKit for Safari 17.4 also expands the purpose of the :scope
pseudo-class. When used inside a @scope
block,
:scope
matches the block’s defined scope root. This
provides a way to apply styles to the root of the scope from inside
the @scope
block itself. In the following example,
:scope
applies a border to the article
element.
<article id="my-component">
<style>
@scope {
:scope { border: 1px solid black; }
h1 { font-size: 4rem; }
}
</style>
<h1>This is 4rem text.</h1>
</article>
You can try this
demo in a browser with support.
For years, the
white-space
property in CSS has provided a mechanism for
doing two things at once: 1) defining whether and how white space
is collapsed, and 2) defining whether and how lines wrap. The CSS
Working Group has since noted that this was likely a mistake, to handle
two different qualities in one property. With the introduction of
text-wrap
, the CSSWG has rethought how the long and
shorthand versions of these properties combine into an architecture
that makes more sense and gives us needed flexibility.
Now the white-space
property is a shorthand for
two
new
longhand properties:
white-space-collapse
and text-wrap-mode
,
both added in WebKit for Safari 17.4. These longhands let you
change the collapsing and wrapping modes independently, each
without affecting the other.
The white-space-collapse
property controls how
white space is collapsed. By default, it’s set to
collapse
, causing strings of multiple spaces to become
a single space. You can change the value instead to
preserve
in order to keep all the spaces, or use other
the values: preserve-breaks
,
preserve-spaces
, or break-spaces
. These
values all behave as they have for years with the
white-space
property.
The new text-wrap-mode
property provides a
mechanism for setting whether or not text should wrap. The
wrap
value turns it on, and the nowrap
value turns it off.
This work sets the stage for the text-wrap
shorthand and it’s longhands text-wrap-style
and
text-wrap-mode
, some of which you can currently test
in Safari
Technology Preview.
WebKit for Safari 17.4 adds support for percentages in
letter-spacing
and
word-spacing
. This lets you define spacing as a
percentage of the element’s font-size
— and keeps
tracking the font-size
even when it grows or shrinks
on descendant elements.
WebKit for Safari 17.4 adds support for the
::spelling-error
and
::grammar-error
pseudo-elements. These make it possible
to create your own custom styling for text that is marked by the
browser as misspelled or grammatically incorrect.
The vast majority of content on the web is communicated through
HTML, but CSS does have the ability to insert content into the
page. Until now, sometimes this kind of content could not be made
accessible. Now in WebKit for Safari 17.4, you can provide
alternative text with accessible content
fallback — content: "foo" / "alt-text";
For example, perhaps we want to prefix certain links with the little ⓘ icon to let users know this item leads to more detailed information. That symbol might be read by screenreader as “Circled Latin Small Letter I” or “Information source combining enclosing circle”, neither of which do a good job communicating the intended purpose. Perhaps a better experience would be to simply hear “Info:”.
.info::before {
content: "ⓘ" / "Info:";
}
Previously, the -webkit-alt
property served this
function. It has been deprecated in favor of the new content alt
text syntax. The new syntax is also more expressive as it allows
for cascading, and allows you to chain multiple strings and
attr()
as alternative text.
When CSS Transitions were created, they allowed authors to
create a gradual timed transition between old and new values by
interpolation. Sometimes, however, interpolation is not possible.
For example, there’s no meaningful intermediary value between
float: left
and float: right
, so,
transitions ignored these properties. They simply jumped from the
first state to the second immediately, without any ability to
define when the jump should happen.
Yet, web developers have wanted a way to at least be able to define when the transition should happen for discrete properties. So the CSS Working Group figured out a way to make that possible. Now, you can tell the browser that you want an element to be capable of transitioning discrete property values, which lets you control their transition timing using the easing functions.
WebKit for Safari 17.4 adds support for the
transition-behavior
property. The
transition-behavior: allow-discrete
rule lets you
enable transitions between discrete property values, so that you
can control their timing via
transition
.
li {
list-style: disc;
color: blue;
transition: all 2s, list-style 0.5s step-end;
transition-behavior: allow-discrete;
}
li:hover {
list-style: square;
color: red;
}
Try this demo
code in a browser with support.
Toggle transition-behavior
off to see the difference.
The :has()
pseudo-class provides tremendous value. We keep making it more and
more powerful by adding support for additional pseudo-classes
within :has()
. WebKit for Safari 17.4 adds support for
:has(:any-link)
,
:has(:link)
,
and :has(:-webkit-any-link)
, making it possible to
select an element depending on whether or not it contains a
link.
WebKit for Safari 17.4 adds support for CSS custom
properties to the
::backdrop
pseudo-element, allowing variables to be
applied to the backdrop behind
dialog
elements and other top layer items.
WebKit for Safari 17.4 also adds offset-position
support for circle()
and ellipse()
.
And WebKit for Safari 17.4 makes -apple-
prefixed
pseudo-elements no longer valid.
This release of Safari adds support for an assortment of small Web API additions that give you extra tools in your developer toolkit.
With support for the
element.checkVisibility()
method, you can
determine the visibility of an element across a variety of
conditions including how CSS properties such as
display
, visibility
, and
opacity
are applied.
WebKit for Safari 17.4 also extends its Declarative
Shadow Root support. The
Element.prototype.setHTMLUnsafe()
,
ShadowRoot.prototype.setHTMLUnsafe()
, and
Document.parseHTMLUnsafe()
methods, as well as the
ShadowRoot clonable
property are now available.
The setHTMLUnsafe()
methods work similar to setting an
element’s innerHTML
property, enabling unsanitized DOM
tree mutation but with additional support for declarative shadow
roots. The parseHTMLUnsafe()
method similarly parses
unsanitized HTML with declarative shadow root support and returns a
document. And the clonable
read-only boolean property
allows you to detect if a ShadowRoot is clonable.
WebKit for Safari 17.4 adds support for the CustomStateSet
interface for custom element state management. This interface
includes methods to add()
, delete()
, or
detect if the element has()
a given state, and more.
Importantly, these states added to a custom element can be styled
using the :state()
pseudo-class by users of the custom
element.
The
DOMMatrixReadOnly interface now supports the
scaleNonUniform()
method that creates a new DOMMatrix
scaling on X, Y, and Z axes. The X axis scaling factor must be
specified, but the Y and Z axes default to 1
. The
scaling is centered at the given origin that defaults to (0,
0, 0)
.
Lastly, WebKit for Safari 17.4 adds support for
AbortSignal.any()
giving you a convenient way to
combine abort signals such as user input (e.g. a user clicks a
cancel button) and a timeout to send an abort signal to an async
operation.
New JavaScript features in Safari 17.4 add new expressiveness
and convenience with promise resolvers, improved
internationalization formatting, ArrayBuffer
ownership
management, and Array grouping features.
WebKit for Safari 17.4 adds support for the
Promise.withResolvers
static method. It allows
developers the convenience of creating a promise and configure the
resolution and rejection handlers after it has been created. The
method returns the promise along with the resolution and rejection
functions.
const { promise, resolve, reject } = Promise.withResolvers();
The TimeZoneOffset
format is now available for
Intl.DateTimeFormat
. It allows you to specify the
difference of the local time to UTC time in positive or negative
hours and minutes depending on whether the local time is ahead or
behind.
new Intl.DateTimeFormat("en-US", {
dateStyle: 'long',
timeStyle: 'long',
timeZone: '-0800'
}).format(new Date())
Additionally, Number.prototype.toLocaleString
and
Intl.NumberFormat
have been updated so the string
representation correctly aligns with recent specification
changes.
There’s also new expressive API for managing the concept of
ownership for ArrayBuffers.
ArrayBuffer.prototype.transfer
creates a new
ArrayBuffer with the same contents and properties as the target
ArrayBuffer (such as being resizable) and detaches it from the
original ArrayBuffer. You can use
ArrayBuffer.prototype.transferToFixedLength()
to
guarantee a non-resizable ArrayBuffer with the same content as the
buffer. ArrayBuffer.prototype.detached
will tell you
if the buffer has been transferred and is detached.
WebKit for Safari 17.4 also adds the Array grouping feature that
includes Object.groupBy
and Map.groupBy
methods. These methods give you powerfully simple tools for
grouping datasets.
const todos = [
{ task: "Water the flowers", context: "home", estimate: "5 minutes" },
{ task: "Get the TPS report done", context: "work", estimate: "45 minutes" },
{ task: "Find new insurance", context: "home", estimate: "180 minutes" },
{ task: "Fix a website bug", context: "work", estimate: "25 minutes" },
{ task: "Answer emails", context: "anywhere", estimate: "10 minutes" }
];
let contextual_tasks = Object.groupBy(todos, ({ context }) => context);
console.log(contextual_tasks);
let tasks_by_time = Map.groupBy(todos, ({ estimate }) => {
return parseInt(estimate.split(' ')[0]) < 15 ? "short" : "long";
});
console.log(tasks_by_time);
WebKit for Safari 17.4 adds support for several audio and video codecs.
First, WebKit for Safari 17.4 on iOS, iPadOS and in visionOS adds support for WebM. While the WebM container (with both the VP8 and VP9 video codecs) has been fully supported on macOS since Safari 14.1, support on iOS and iPadOS was limited to VP8 in WebRTC. Now, WebM is fully supported everywhere.
The Vorbis audio codec is also now supported in WebKit on iOS 17.4, iPadOS 17.4 and in visionOS 1.1.
And WebKit for Safari 17.4 expands what WebCodecs can do with the addition of support for the HEVC codec.
When support for video embedding arrived in HTML5 with the
<video>
and <source>
elements, the web standard specified that the first file that’s
recognized by the browser should be chosen and played. This put the
burden on the developer to make sure the best files were listed
before lesser-quality files.
<video>
<source src="movie.webm">
<source src="movie.av1">
<source src="movie.mov">
</video>
Are you sure the first format listed is always a better choice than
the rest?
This made sense in a simpler time, when there were just a few codecs available. Now, there are many codecs with different qualities. It’s not always possible for developers to know which file is the best one for a user to stream. And it can be impossible to put them in one specific order that’s best for all users.
A browser might easily be capable of playing several of the files offered, but one of those files could be compressed with a codec that the user’s device can decode using hardware, while the rest might only be decoded by software alone.
It’s definitely a better user experience to use hardware decoding. Doing so significantly impacts power usage and makes a battery last longer. So now, in WebKit for Safari 17.4, the best file for the user is chosen, instead of defaulting to the first file that has support. Video codecs with hardware decoding support on various Apple devices include VP9, h.264, HEVC and AV1.
WebKit for Safari 17.4 adds support for HTML
character entities to WebVTT
(Web Video Text Tracks Format), the technology used to add
subtitles and captions to video files on the web. HTML entities are
a way to write special characters without having the browser
mistakenly think they are part of the HTML code. For example,
·
represents the “·” character.
WebKit for Safari 17.4 adds support whiteBalanceMode
to MediaStream. In photography, adjusting white balance is a
technique for compensating for the fact that “white” is a different
color under different lighting conditions. Sunlight is very blue,
while indoor lights tend to be quite orange. Our brains
automatically adjust, so as humans, we rarely notice. But cameras
need technology to help them adjust color temperature so that the
resulting photo or video has the kind of coloring people expect.
Now modes for white balance are available for the
MediaStream Image Capture API on the web.
WebKit for Safari 17.4 adds support for
kernelUnitLengthX
and kernelUnitLengthY
to
SVGFESpecularLightingElement
.
WebKit for Safari 17.4 adds support for four new WebGL
extensions: EXT_clip_control
,
EXT_depth_clamp
,
EXT_polygon_offset_clamp
, and
WEBGL_polygon_mode
.
WebKit for Safari 17.4 enables extended constant expressions to support more advanced WebAssembly linking.
Web Inspector for Safari 17.4 has two new features. First, when a page attempts to load a font URL blocked by Lockdown Mode, a message is logged to the Console.
Second, Web Inspector now groups load errors for source maps. Source map files are used for converting a combined or minified file back into its original state. Grouping load errors helps reduce noise while debugging. You can disable this behavior in Web Inspector Settings under Experimental settings.
Safari 17.4 itself includes three changes to the UI and user experience. First, you can now configure the Favorites Bar to show your bookmarks with only their icons. Edit the name of the bookmark in the favorites bar, and remove the name. The icon will remain.
Second, Safari 17.4 now supports webpage translation inside
<iframe>
elements.
And third, Safari 17.4 adds support for Apple Cash virtual card numbers and showing the user their Apple Cash balance when using AutoFill.
Safari 17.4 includes a change to web extensions that allows extensions to open Private Browsing windows even when they don’t have access to Private Browsing.
WebKit for Safari 17.4 adds support for WebAuthn’s
PublicKeyCredentials.getClientCapabilities()
function.
Use it to find out which WebAuthn features are supported. It
returns a Promise of a record<DOMString,
boolean>
containing capabilities and their values.
In addition to all the new features, WebKit for Safari 17.4 includes work polishing existing features.
<summary>
element
role. (13661104)combobox
role. (112488137)innerHTML
and
innerText
changes to labels did not update their
corresponding input element’s accessibility title. (113872525)<details>
and
<summary>
elements not included in VoiceOver
form controls menu or list. (117308226)aria-activedescendant
changes. (117747058)getComputedStyle()
for invalid
pseudo-elements. (98504661)querySelector()
to not throw an exception
for -webkit-
prefixed pseudo-elements. (99299129):user-invalid
triggering while typing a
date. (110687369)text-transform: full-size-kana
to
align with Unicode 15. (111508663)contain: inline-size
breaking
grid-template-rows: auto
. (113915953)svh
and dvh
units being
unexpectedly equal when the Safari tab bar is not visible.
(115085360)mixed-blend-mode
to blend correctly against
the root background. (115688282)backdrop-filter
with many interoperability
improvements. (115703346)oklab
and oklch
lightness value
clamping. (116195533)::selection
pseudo-element color. (117796745)-webkit-
prefixed pseudo-elements. (118081134)::backdrop
to be allowed after
::slotted()
. (119015204):checked
and
:indeterminate
to match at the same time.
(119075969)min-height
not sizing row correctly. (119736473)rect()
and
xywh()
as the equivalent inset()
.
(119739406):has(+ :not(.class))
pseudo-class selector. (119819247)content
computed value serialization.
(120061551)getComputedStyle()
and KeyframeEffect.prototype.pseudoElement
so they
require them starting with ::
(or :
for 4
legacy pseudo-elements). (120170550)linear()
easing. (120290721):host
selector.
(120428386):not(:has(:not(foo)))
getting misclassified
as scope breaking. (120492012)::slotted
pseudo-element in a
container query getting resolved against the wrong scope.
(122224135)-apple-
prefixed pseudo-elements no longer
valid. (120268884)<select>
not refreshing the dropdown
after an <option>
is removed on iPad.
(88292987)text-indent
to affect the selected file(s)
label for file inputs. (105223868)dir=auto
to work for hidden
,
password
, submit
, reset
, and
button
input types, made dirname
work for
password
and submit
input types, and
removed dirname
support from number
input
types. (113127508)autocomplete
with a
webauthn
token. (116107937)<option>
elements outside of an
<optgroup>
getting added to the preceding group.
(117930480)system-ui
font family within
<canvas>
. (117231545)<progress>
to use the page’s preferred
rendering update interval. (118976548)direction
attribute
in the list of attributes whose values are matched
case-insensitively with attribute selectors. ( (119432066)Temporal.Now.timeZone()
to be updated to
timeZoneId()
. (118674314)ondataavailable
at every timeslice event.
(115979604)object-fit: fill
on
<video>
elements. (118020922)video.buffered
attribute.
(118550061)id
settings. (118551267)getDisplayMedia
frameRate
always at 30 regardless of constraints. (118874132)writing-mode:
vertical-rl
or direction: rtl
. (102620110)getComputedStyle
was incorrect. (117523629)<div>
within a
transformed parent <div>
with overflow:
hidden
. (118901069)offsetHeight
and offsetWidth
are 0 for an inline box wrapping a block. (119955792)ch
unit value in
vertical-rl
and vertical-lr
when
text-orientation
is not upright. (120293590)overflow: hidden
to not prevent CSS Subgrid
from applying. (120848131)align-content
and
justify-content
on scroll containers causing
overflowing content to become inaccessible. (121366949)<br>
element with clear
.
(121444267)white-space: nowrap
. (121859917)margin-trim
behavior for floats to match
specification changes. (115794102)scripting.executeScript()
. (107996753)scripting.unregisterContentScripts()
. (113171510)vertical-rl
, or flexbox reverse mode elements.
(104944522)scrollTo()
followed by an animated scroll
ending at the wrong scroll position. (117608836)rx
or ry
exclusively
via CSS having no effect. (113500023)<iframe>
without affecting the size of the
<iframe>
. (120178866)currentTime
is
changed to 0 not restarting when unpaused. (118826588)wheel
and
gesturechange
events inside an iframe.
(105243167)Range.getClientRects()
and
Range.getBoundingRect()
for certain ranges.
(112543805)Request
‘s
referrer
feature and Response.redirect()
.
They now always use UTF-8. (115219660)<meta
name="color-scheme">
when their name
or
content
attribute changes. (115958450)FetchResponse.formData()
to parse headers
names as case insensitive. (116742000)scrollIntoView({ block: 'center' })
. (117755250)resizeBy
and resizeTo
to use int
rather than float
to align
with specifications. (118872048)Element.prototype.setAttributeNode()
to not
treat attribute names case insensitively. (119013600)spellcheck
attribute not
toggling spelling markers on input elements. (119269616)getElementsByName()
to only return HTML
elements, not SVG, MathML, or other types of elements.
(120275680)button
value for a
pointerup
event not matching the
pointerdown
event. (120429508)document.open
. (120893136)captureStream
stuttering with WebGL.
((122471664)tan()
function to not trigger the color
picker. (118724061){"width":1920,"height":1080,"frameRate":24}
.
(61747755)degradationPreference
.
(121041723)Safari 17.4 is available on iOS 17.4, iPadOS 17.4, macOS Sonoma 14.4, macOS Ventura, macOS Monterey and in visionOS 1.1.
If you are running macOS Ventura or macOS Monterey, you can update Safari by itself, without updating macOS. On macOS Ventura, go to > System Settings > General > Software Update and click “More info…” under Updates Available.
To get the latest version of Safari on iPhone, iPad, or Apple Vision Pro, go to Settings > General > Software Update, and tap to update.
We love hearing from you. To share your thoughts on Safari 17.4, find us on Mastodon at @jensimmons@front-end.social and @jondavis@mastodon.social. Or send a reply on X to @webkit. You can also follow WebKit on LinkedIn. If you run into any issues, we welcome your feedback on Safari UI, or your WebKit bug report about web technologies or Web Inspector. Filing issues really does make a difference.
Download the latest Safari Technology Preview on macOS to stay at the forefront of the web platform and to use the latest Web Inspector features.
You can also find this information in the Safari 17.4 release notes.
Safari Technology Preview Release 189 is now available for download for macOS Sonoma and macOS Ventura. If you already have Safari Technology Preview installed, you can update it in System Settings under General → Software Update.
This release includes WebKit changes between: 273602@main…274066@main.
light-dark()
function for color
values. (273634@main)
(117033939)@starting-style
. (273740@main)
(121918611):host
selector. (273987@main)
(120428386)::slotted
pseudo-element in a
container query getting resolved against the wrong scope. (274050@main)
(122224135):-webkit-full-screen-ancestor
pseudo-class. (273620@main)
(100782937):-webkit-full-screen-controls-hidden
pseudo-class. (273619@main)
(121323330):-webkit-full-page-media
pseudo-class.
(273618@main)
(121752962):-webkit-full-screen-document
pseudo-class. (273639@main)
(121816310)document.referrer
initialization. (273830@main)
(97689906)RangeError
if Set
methods are called on an object with negative size
property. (274009@main)
(121310940)eval()
function from another realm to not
cause a direct eval
call. (273782@main)
(121546048)eval()
call with ...spread
syntaxt to be a direct call. (273788@main)
(121547890)content-visibility:
hidden
. (273602@main)
(117916396)align-content
and
justify-content
on scroll containers causing
overflowing content to become inaccessible. (273737@main)
(121366949)white-space: nowrap
. (121859917)display: none
as the
default UA style rule. (273991@main)
(122185838)history.pushState()
and
history.replaceState()
to ignore the
title
argument. (273650@main)
(75695791)lang
attribute in no namespace to only apply
to HTML and SVG elements. (273726@main)
(117795695)clonable
. (274063@main)
(121516711)which
from KeyboardEvent
.
(273701@main)
(106580687)<video>
or <audio>
element in
the Elements tab. (273777@main)
(118865793)navigator.credentials.create()
rejects with
“NotAllowedError: Operation Failed” after a conditional UI request
is aborted. (273918@main)
(109936742)EXT_texture_mirror_clamp_to_edge
,
WEBGL_render_shared_exponent
, and
WEBGL_stencil_texturing
. (273645@main)
(121835897)The CSS Working Group has published an updated Working Draft of CSS Text 4. This CSS module defines properties for text manipulation and specifies their processing model. It covers line breaking, justification and alignment, white space handling, and text transformation.
This is a fairly minor update, mostly focused on refinements to the text-spacing-trim property, which should be of interest for CJK typography. Changes since the last Working Draft are listed in the Changes section.
Please send feedback by either filing an issue in
GitHub (preferable) or sending mail to the (archived)
public mailing list
www-style@w3.org with the spec code ([css-text-4]
)
and your comment topic in the subject line. (Alternatively, you can
email one of the editors and ask them to forward your comment.)
Safari Technology Preview Release 188 is now available for download for macOS Sonoma and macOS Ventura. If you already have Safari Technology Preview installed, you can update it in System Settings under General → Software Update.
This release includes WebKit changes between: 272449@main…273601@main.
content
alternative
text syntax. (272455@main)
(26942023)<header>
inside
<main>
and sectioning elements. (273188@main)
(48370244)<input type=checkbox
switch>
. (273206@main)
(121215059)transition
property to produce the
shortest serialization. (272513@main)
(119822401)animation
property to produce the
shortest serialization. (272629@main)
(120439368)supports()
syntax for @import
rules. (273591@main)
(109060734)getComputedStyle()
for invalid
pseudo-elements. (272543@main)
(98504661)oklab
and oklch
lightness value
clamping. (272501@main)
(116195533):has(+ :not(.class))
pseudo-class selector. (272678@main)
(119819247)content
computed value serialization.
(272476@main)
(120061551)getComputedStyle()
and KeyframeEffect.prototype.pseudoElement
so they
require them starting with ::
(or :
for 4
legacy pseudo-elements). (272499@main)
(120170550)linear()
easing. (272613@main)
(120290721):-webkit-full-screen
pseudo-class
to :fullscreen
. (272577@main)
(120335917):-webkit-any-link
to
:any-link
and :matches()
to
:is()
. (272559@main)
(120337922)getComputedStyle()
pseudo-element parsing to
support the full range of CSS syntax. (272649@main)
(120471227):not(:has(:not(foo)))
getting misclassified
as scope breaking. (273177@main)
(120492012)@supports
to correctly handle support for
some -webkit
prefixed pseudo-elements that were
incorrectly treated as unsupported. (272726@main)
(120577690)-webkit-alt
and alt
properties. (272480@main)
(120051066)resize: auto
property.
(273035@main)
(120138995)-apple-
prefixed pseudo-elements no longer
valid. (272538@main)
(120268884):-webkit-animating-full-screen-transition
pseudo-class. (273529@main)
(121302758):-khtml-drag
pseudo-class. (273261@main)
(121303391)text-indent
to affect the selected file(s)
label for file inputs. (272837@main)
(105223868)navigator.cookieEnabled
to return
false
when cookies are blocked. (273522@main)
(121284878)<textarea>
element with
1rem
padding. (273029@main)
(90639221)writing-mode: vertical-rl
. (272799@main)
(120066970)ch
unit value in
vertical-rl
and vertical-lr
when
text-orientation
is not upright. (272536@main)
(120293590)overflow: hidden
preventing CSS Subgrid.
(273134@main)
(120848131)<br>
element with clear
. (273407@main)
(121444267)<iframe>
without affecting the size of the
<iframe>
. (272503@main)
(120178866)<switch>
element. (272831@main)
(120732837):state()
pseudo-class. (272474@main)
(120072599)getElementsByName()
to only return HTML
elements, not SVG, MathML, or other types of elements. (272530@main)
(120275680)button
value for a
pointerup
event not matching the
pointerdown
event. (273263@main)
(120429508)document.open
. (272960@main)
(120893136)KeyboardEvent.altGraphKey
.
(273379@main)
(102980723)KeyboardEvent.keyLocation
. (273457@main)
(121564228)browsing.scripting.executeScript
to handle
all valid argument types. (120727491)getClientCapabilities
to align with WebAuthn
standards to use a record type with camelCase values. (272998@main)
(120442670)EXT_conservative_depth
and
NV_shader_noperspective_interpolation
. (272979@main)
(120907578)degradationPreference
. (273172@main)
(121041723)The web is amazing. It makes collaborating, learning, and connecting easy for billions of people, because it’s intentionally designed to run on radically different devices.
It’s your job as a web developer to ensure your project works in every browser and for every user — and that can be hard to do. It’s a far easier undertaking when browsers have identical implementations of the web technology you use.
Identical implementations are accomplished through the web standards process, where people collaborate together to write extremely detailed technical documents that define each new web technology — right down to how website bugs should work.
One way to check and see if browsers follow the web standards is through automated testing. There are several shared repositories of such tests, including Web Platform Tests. WPT contains over 1.8 million tests, of which over 95% pass in all of the major browsers.
The Interop project aims to improve interoperability by encouraging browser engine teams to look deeper into specific focus areas. Now, for a third year, Apple, Bocoup, Google, Igalia, Microsoft, and Mozilla pooled our collective expertise and selected a specific subset of automated tests for 2024.
Some of the technologies chosen have been around for a long time. Other areas are brand new. By selecting some of the highest priority features that developers have avoided for years because of their bugs, we can get them to a place where they can finally be relied on. And by selecting exciting new technology, we can ensure it’s interoperable from the beginning.
To better understand where interoperability is going in the future, let’s first take a look at the impact of Interop 2023.
Interop 2023 was even more of an overwhelming success than Interop 2022. In January 2023, 48% of the chosen tests passed in all three of the major browser engines (in those shipped to users: Chrome and Firefox for desktop Linux, and Safari on macOS Monterey). A year later, that pass rate rose to 95% (in Chrome Dev and Firefox Nightly for desktop Linux, and Safari Technology Preview on macOS Ventura).
The success of Interop 2023, seen on the “Experimental” dashboard. The “Interop” line, in dark green, shows the percentage of tests that passed in all three — Chrome Dev, Firefox Nightly, and Safari Technology Preview.What did Interop 2023 accomplish?
border-image
now works as originally
intended.:has()
, Motion Path,
CSS Math Functions, inert
and @property
are now supported in every modern browser.adoptedStyleSheets
, ElementInternals
,
Form-Associated Custom Elements, and the basic behavior of Shadow
DOM and Custom Elements.:nth-child()
,
:nth-last-child()
, :modal
,
:user-valid
, and :user-invalid
.We hope this work gives you a renewed sense of confidence to use these technologies. If you found any of them hard-to-use in the past, give them another try.
Interop 2023 had twenty-six focus areas, twenty of which are being retired as a success. Work will continue on Custom Properties, Pointer and Mouse Events, URL, and a new grouping called “Layout” — consisting of Flexbox, Grid, and Subgrid.
Now, we are doing it all again for 2024. Ninety-six focus area proposals were submitted for consideration. Ultimately, sixteen were chosen. Grouping some of the new proposals together, and continuing some of the work from 2023, gives Interop 2024 a total of seventeen focus areas.
The Interop 2024 dashboard, looking at the “stable” browsers (those currently in the hands of everyday people). Coincidentally, the overall Interop score is once again starting at 48%.New this year, Microsoft Edge now has its own column on the Interop dashboard. This currently represents Edge and Edge Dev running on Windows 10.
Interop 2023 included an Accessibility Investigation project. Led by Apple’s accessibility team, the group worked diligently to create new accessibility testing infrastructure for WPT, and write over 1300 new accessibility tests. These tests have now been included in Interop 2024 as a focus area, encouraging browsers to increase their support.
The majority of new accessibility tests cover WAI-ARIA, in particular, the Roles Model and the Accessible Name and Description Computation (AccName). Together, these provide a consistent mechanism for conveying the purpose or intent of an element so assistive technology users understand what it is and what they can do with it.
Other new accessibility tests cover how those technologies are
incorporated into host languages. For example, the HTML Accessibility API Mappings
specification (HTML-AAM) defines the default accessibility
semantics of HTML elements, along with related rules for how
browsers work with features like the <label>
element and image alt
text. (See the
html-aam/roles WPT tests as an example.)
Another new set of tests cover the accessibility of
display: contents
. This display mode in CSS provides a
useful mechanism for removing the box around content — helpful when
wanting to adjust the parent/child/grandchild relationships of
content for the purposes of Flexbox or Grid. But it was off limits
for use for years, because of the lack of accessibility in
early implementations. Removing the box on an item completely
removed all the contents of that box from the accessibility tree.
Sighted users could still see the child content, but many users of
assistive technology experienced it completely disappearing. Most
of these problems have been fixed in browsers, but not all, not for
every situation. These new tests are the next step toward full
accessibility and interoperability.
By including these new Accessibility tests in Interop 2024, the hope is to fix every issue in all browsers. We want it to be easier for developers to create accessible sites and make the web better for everyone, including people with disabilities.
CSS Nesting is a focus area for Interop 2024 to ensure any differences are ironed out, and to provide you with the confidence to use it. The ability to nest CSS shipped in all four major browsers in 2023 — first in Chrome, Edge, and Safari in April/May. And then in Firefox in August.
The web standard changed slightly between May and August,
relaxing the original requirement that every nested selector start
with a symbol. Developers can now simply write
article
, rather than needing to use &
article
.
All of the implementations have since been updated, but there
are still small bits that could benefit from attention to
interoperability, especially as the final complex details of how
Nesting works are settled in the CSS Working Group. Most of
Safari’s test failures, for example, are about how nested CSS
interacts
with the Shadow DOM via :host
.
The @property
at-rule started shipping in
browsers over the last few years. As part of Interop 2023, the
Custom Properties focus area rose from 4% of tests passing in all
stable browsers to 7.6% passing — with 90.7% passing in all of the
preview browsers. Firefox is the last browser to add support, which
is currently in progress in Firefox Nightly. Since this work isn’t
done yet, the focus area is being continued in 2024.
With @property
,
developers can declare CSS custom properties in a fashion similar
to how browser engines define CSS properties — specifying its
syntax, inheritance behavior, and initial value.
@property --size {
syntax: "<length>";
inherits: false;
initial-value: 0px;
}
This allows you to do things in CSS that were impossible before, like animating gradients or certain parts of transforms.
Declarative Shadow DOM is a declarative API that lets you create reusable widgets and components by using only HTML — no JavaScript is necessary. It’s been supported in Safari 16.4 since March 2023, and in Chrome 90 since April 2021. Firefox has an implementation in Firefox Nightly.
Declarative Shadow DOM was one of the often-asked-for features in the State of HTML 2023 survey, so it was chosen to be part of Interop 2024 to ensure it becomes interoperable across all browsers.
The font-size-adjust
property is a great example of
the usefulness of placing attention on older technology. Firefox
first implemented font
size adjust in 2008, but it was rarely used or even discussed by
web designers and developers. The early spec evolved over time,
adding support for more languages through the two-value syntax, and
becoming easier to use with the from-font
value.
The WebKit team implemented the basic version in Safari 16.4 and added the updates in September’s Safari 17.0. Mozilla updated their implementation in Firefox 118, also in September 2023. Both Safari and Firefox now pass 100% of all tests. Chrome began an experimental implementation in 2015, but has yet to ship it. Now with Interop 2024, it’s likely every browser will gain complete support.
Font size adjust provides a simple way to conform all the fonts
used in a string of text to be the same visual size — so every
character in 1.4rem
-sized text, for example, has the
same x-height — or cap height, ch
width,
ic
width, or ic
height. The two value
syntax allows you to choose which measurement to conform.
This property is especially useful when you are mixing code with regular text, or mixing multiple languages together, and the different fonts within the same sentence have different sizes. With font size adjust you can avoid weirdly-big letters. No more fussing with font metrics to find a magic number that makes them all look the same size.
The CSS `font-size-adjust: from font` makes the Courier font adjust its size to match its x-height with that from Iowan Old Style, instead of typesetting the code to be visually larger. The size uniformity holds even when fallback fonts are used instead.Learn more about font-size-adjust
by watching
What’s new in CSS from WWDC23.
A quirky aspect of the WebSocket API is that you need to use
non-HTTP(S) schemes: ws:
(insecure) and
wss:
. As the URLs function otherwise identically to
HTTP(S) URLs, this makes the API a bit frustrating to deal with.
Based on web developer feedback the WebKit team decided to address
this last year by making the API support HTTP(S) URLs as well. We
shipped support in Safari 17.0.
This means that instead of writing:
function webSocketHandle(path) {
const url = new URL(path, location);
url.protocol = location.protocol === "https:" ? "wss:" : "ws:";
return new WebSocket(url);
}
// ...
const ws = webSocketHandle(path);
You can now write the much more ergonomic:
const ws = new WebSocket(path);
By bringing this to Interop 2024, we hope other browsers will adopt it as well, making it universally available for web developers.
IndexedDB is an API that provides powerful ways to store data client-side, in an object-oriented database. It started shipping in browsers in 2011, and over the years the web standard has kept evolving. Both version 2 and version 3 are supported by all major browsers. Version 2 is fully interoperable, but version 3 needs a bit of attention to bring up the quality of implementations. Being part of Interop 2024 will help ensure implementations are completed and aligned.
CSS Grid and Flexbox were both included in the original Interop project in 2021. Subgrid was added in Interop 2023. While all three layout methods are now in great shape, they still aren’t quite perfect. The tests for these three areas are now being combined into one Focus Area called Layout. Work will continue to ensure complex edge cases are more interoperable. Meanwhile, developers should absolutely feel confident using these three technologies, since all browsers have solid support for Flexbox, Grid, and now Subgrid.
Pointer events are DOM events that are fired for a pointing device. They create a single DOM event model to handle pointing input devices such as a mouse, pen/stylus, or touch with one or more fingers. This API first started shipping in browsers in 2012, and landed everywhere by 2019, but still had rocky interoperability.
In 2022, the Interop team launched an Investigation Project to look deeper into the current state of Pointer and Mouse Events, in an effort to clarify consensus and write tests that captured the state of that consensus. For Interop 2023, those tests enabled Pointer and Mouse Events to be a Focus Area, where the test pass rate was part of the Interop 2023 dashboard and score. Over the year, Pointer and Mouse Events rose from a test pass rate of 34% to 81% — the most significant progress of any area.
While passing 81% of tests is a significant improvement, there is more work to do, therefore Pointer and Mouse Events will continue to be a Focus Area for 2024.
The new
popover
attribute in HTML provides a
built-into-the-browser way to have an element pop into view on the
top layer of a page. If you are creating an overlay over the entire
web page, the
dialog
element is the best option. But when you want to
turn any other element into a popup message, user interface, or
other kind of content that appears and disappears, the
popover
element provides a framework to do it.
Support for popover
shipped in Chrome 114 and
Safari 17.0 in 2023. Firefox currently has support in progress in
Firefox Nightly. Being part of Interop 2024 will ensure this highly
desired feature has a fantastic start.
Relative Color Syntax is a new way to define colors in CSS that allows you do so while referring to another color. You can, for instance, lighten or darken an existing color by a certain amount. You can take a color variable, adjust the saturation, and assign the new color to a second variable. Relative Color Syntax can be especially powerful when creating a design system.
Learn more about Relative Color Syntax by watching What’s new in CSS from WWDC23.Safari 16.4 was the first browser to ship support, in March
2023. Chrome 119 and Edge 119 shipped support in Oct and Nov 2023.
Currently, none of the implementations have support for using
currentcolor
with Relative Color Syntax.
The Relative Color Syntax focus area for Interop 2024 doesn’t
test overall support of Relative Color Syntax. It’s narrowly
focused on whether or not currentcolor
is supported,
and includes tests of out-of-gamut behavior — checking to see what
happens on displays that don’t have support for P3 color. Inclusion
in Interop 2024 will help these final bits get done.
The <video>
element provides powerful
functionality for putting video on the web. But often, developers
want and need to do more. The
HTMLVideoElement
interface provides special
properties and methods for manipulating video objects in
JavaScript. And one of those methods is
requestVideoFrameCallback()
. It lets you perform
per-video-frame operations on video in an efficient manner —
operations like video processing or analysis, painting to canvas,
and synchronization with audio sources.
Supported since Chrome 83 and Safari 15.4, inclusion in Interop 2024 will help browsers complete and polish our implementations.
The scrollbar styling focus area includes two CSS properties
that can be used to style scrollbars. The
scrollbar-width
property provides three values:
auto
, thin
, and none
. The
auto
value is the default width; thin
provides a thinner scrollbar; and none
hides the
scrollbar while still allowing content to scroll. Firefox 64
implemented
support in December 2018, and it just shipped in Chrome 121 and
Edge 121.
The
scrollbar-gutter
property lets you reserve space
for the scrollbar, so the layout is the same whether or not a
scrollbar is present. The scrollbar-gutter: stable
rule lets you tell the browser to reserve space for a scrollbar,
even when a scrollbar isn’t there. This can prevent layout shifts
from happening between states where scrollbars are needed or not
needed. It shipped
in Chrome 94, Edge 94 and Firefox 97, in 2021–22.
Safari has the most work to do to complete this Focus Area.
Chrome and Firefox already pass 100% of the tests. Ironically, it
was Safari who first
provided the ability to style scrollbars with nine
pseudo-elements, ::-webkit-scrollbar-*
, back in
2009. However that approach to styling scrollbars never became
an official CSS web standard. The CSS Working Group instead
opted
for a far simpler approach.
This Focus Area brings attention to two new features for controlling animation. Both shipped in Chrome 117 and Edge 177 in Sept 2023.
The
@starting-style
rule in CSS lets you define starting
values for a particular element. This is needed when the element is
about to go through a transition. It also provides a way for
transitioning in or out of display:none
.
.alert {
transition: background-color 2s;
background-color: green;
@starting-style {
background-color: transparent;
}
}
In the above example, the background-color
will
transition from transparent to green when the element is appended
to the document.
Previously, only animations could animate
discretely-animatable properties. The
transition-behavior
property in CSS expands that
capability to CSS transitions, paving the way for transitioning the
display
property when showing or hiding elements.
The direction in which text flows is a vital aspect of
typesetting on the web. Some languages flow from left-to-right,
while others flow from right-to-left.
One of the many bits of technology supporting text
direction is the
dir
attribute. It lets you specifically mark any
HTML element with the direction: left
,
right
, or auto
— where auto
asks the browser to guess from the first letter. The interaction of
directionality and shadow trees was not well-defined until
recently. Now that it’s been addressed at a standards level, adding
it to Interop 2024 helps us ensure implementations align as
well.
Web designers have long wished for a way to prevent very short
or one-word lines of text — often known as widows or orphans. Since
the advent of responsive web design and the lack of control over
the width of columns, this desire has gotten even more challenging.
The text-wrap
property provides you with multiple options for telling the browser
how to wrap text with different methods for calculating line breaks
for specific use cases.
The text-wrap: balance
rule is a great solution for
headlines. It balances a few lines of text so that each line has
about the same amount of text as the others. It shipped in Chrome
114 and Firefox 121, and is implemented in Safari Technology
Preview.
Interop 2024 also includes tests of how
text-wrap-mode
, text-wrap-style
, and
white-space-collapse
behave. The CSS Working Group
recently changed to how these longhands interact with each other,
so support is currently uneven between browsers. Interop 2024 will
help ensure all browser engines update to the latest web
standards.
URLs are one of the most fundamental parts of the web. Without them, the web would not exist. But like many things invented very early in the history of the web, support has yet to be fully interoperable. To improve this, the WHATWG wrote the URL Living Standard packed with details on exactly how URLs should work. The tests supporting this web standard were a focus area for Interop 2023, improving the pass rate from 77% to 85%. To ensure interoperability, the work in this area will continue in 2024.
Safari is proud to lead the pack, passing 99.7% of the tests. Improvements in other browsers will help ensure websites work correctly everywhere.
Interop 2024 also includes three investigation areas. These are “homework projects” for the Interop team to work on. All three this year are about writing and making it possible to run more tests — Accessibility Testing, Mobile Testing, and WebAssembly Testing. The Mobile Testing investigation project aims to complete the infrastructure needed at WPT to be able to test browsers on mobile operating systems, potentially to include those scores on the Interop project dashboard in the future.
While two of the three investigations are projects continuing from last year, they all are starting 2024 at zero percent done. Each team involved will set new goals for this year, and the dashboard will report progress on those goals.
Keep up with the progress of Interop 2024 throughout the year, on the Interop 2024 dashboard.
We continue to believe that interoperability is one of the fundamental pillars that makes the web such a success. Our efforts in Interop 2022 and 2023 demonstrate how deeply we care about the web. We are excited to again collaborate with our colleagues in seizing this opportunity help the web work better for everyone.
z-index
nightmare, without being cut off by the overflow behavior of a
parent element, and without needing JavaScript code. The API is
available in Chromium-based browsers, Safari, and as a preview in
Firefox. This year, the Interop project is focusing on making the
Popover API work the same across implementations. At Microsoft,
we're very excited about this and especially about the positive
impact it will have on the upcoming customizable
<select>
element, a feature we've originally
prototyped.
Photo of flags of the world by Vladislav Klapin on Unsplash
At the end of 2023 W3C staff members Richard Ishida and Fuqiao Xue were running the internationalization work of the Consortium. When Richard transitioned to semi-retirement on 1 January, 2024, Fuqiao Xue took over the role of Internationalization Lead, and is now the contact point for all internationalization related activity at W3C. Richard has reduced his time commitment, and will focus largely on the aspects of the work related to Language Enablement.
Internationalization is making the World Wide Web worldwide. The
Web needs to work for anyone who speaks any language or writes in
any script.
Internationalization is designing content, applications,
technologies and specifications in a manner that they can be
adapted to all languages and writing systems. It makes it possible
for people throughout the world to use the Web in their own
language and feel natural about it. I18N isn't translations and
localization although it sets up the architecture to provide them.
It is really a design paradigm. One that sets out to deliver the
promise that the Web breaks down geographical barriers.
Internationalization is about communication. It counters the
digital divide, fosters digital economy and individual development,
it promotes cultural understanding, inclusivity. I18N is one of the
pillars of the Web for All.
Richard joined the W3C Team in 2002 with a background in translation and interpreting, computational linguistics, translation tools, and global user interface design. He had become involved in Internationalization by learning various languages -- French, then Spanish, Italian, German, Russian, and Japanese, choosing languages with the aim of communicating with a large proportion of the earth’s inhabitants. Coming from Xerox, where he received a corporate award for the Xerox product development process, Richard provided services and training in international design and localizability of user interfaces and documents. Over the years at W3C, Richard introduced outreach activities to the internationalization work, and then went on to develop, in phases, a robust gap-analysis framework to document and figure out which specific issues need fixing. The framework can be applied to all the languages we are investigating. Gap-analysis documents describe gaps, give them a priority, and point to specifications, tests, etc. This is complemented by a suite of GitHub issue lists, an issue tracker page, and a notification system that sends one email a day to subscribers related to their area of interest, and contains links to issues that have changed in the framework repositories, or those of CSS, HTML, or other W3C working groups. This allows individuals who use the Web like you and me to easily and quickly contribute. This is what Richard wants to achieve: language enablement.
To appreciate the place it holds within Internationalization work at W3C, you need to understand that three axes are critical to achieving progress in making the World Wide Web truly worldwide:
Watch Richard present "Making the World Wide Web worldwide" in a 15 minute video. Then see the W3C standards and drafts tagged with I18N.
Fuqiao Xue joined the W3C Team in 2017 and the first project he worked on was CLReq, which set out to document requirements for Simplified and Traditional Chinese, and discussed Chinese layout requirements with a number of technologists and linguists from Mainland China, Taiwan, Singapore, and other regions. The work is still ongoing but the results are documented as an evergreen document. Interested in languages and writing systems since childhood, Fuqiao learned more and more about Internationalization and began to understand its importance. Fuqiao wants more experts, both technical and linguistic, to get involved and help us ensure that the Web meets local needs around the world.
"Languages are more than just a means of communication," said Fuqiao Xue. "They are vessels of culture, carrying with them traditions, stories, knowledge, and ways of understanding the world that have been passed down through generations."
Like Web accessibility, Internationalization needs to be built from day one because it can be very expensive and time consuming to retrofit. It's also good to develop in more than one language at a time to do it well and thoroughly. We're familiar with the notion that there are costs to non-conformance, but there are also opportunities in further breaking the language barriers. The best one is bridging the digital divide within and between countries. Another is leveling the playing field of market dominance. As internet penetration and digital literacy increase in regions like Asia and Africa, non-English content and platforms will gain prominence. 2024 is the 30th year of the Internet in China. Thanks to Internet penetration, there's been an increase in netizens and speed, as well as the emergence of non-English markets. Consider that of all the country levels, the .cn domain has the most domain names registrations.
To conclude, Internationalization of the Web is where communication meets emerging technologies and platforms, and where people all over the world connect. The scope of work is immense and the potential is exciting. To produce the change we want to our Web, we need people like you to step up to participate and work through the issues.
Last month, Safari 17.2 brought our biggest December release of web technology ever — with 39 new features and 169 bug fixes. Now, in January, Safari 17.3 brings bits of polish to that release.
@supports
queries with declarations.
(113652033)Samesite=Lax
. (119362503)display: none
. (119191813)Safari 17.3 is available for iOS 17, iPadOS 17, macOS Sonoma, macOS Ventura and macOS Monterey.
If you are running macOS Ventura or macOS Monterey, you can update Safari by itself by going to Software Update, and clicking “More info”. On macOS Ventura, that’s > System Settings > General > Software Update > More info.
To get the latest version of Safari on your iPhone or iPad, go to Settings > General > Software Update, and tap to update.
We love hearing from you. To share your thoughts on Safari 17.3, find us on Mastodon at @jensimmons@front-end.social and @jondavis@mastodon.social. Or send a reply on X to @webkit. If you run into any issues, we welcome your feedback on Safari UI, or your WebKit bug report about web technologies or Web Inspector. Filing issues really does make a difference.
Download the latest Safari Technology Preview to stay at the forefront of the web platform and to use the latest Web Inspector features.
You can also find this information in the Safari 17.3 release notes.
The Future of Style features:
If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to this aggregator, please get in touch with fantasai.