https://webkit.org/blog/15063/webkit-features-in-safari-17-4/
[pixel]
WebKit
[ ]
* Downloads
* [ ]Feature Status
+ CSS Features
+ Standards Positions
* [ ]Documentation
+ Web Inspector
+ Tracking Prevention
* [ ]Policies
+ Project Goals
+ Bug Prioritization
+ Bug Report Guidelines
+ Code Style Guidelines
+ Commit and Review Policy
+ Feature Policy
+ Security Policy
+ Tracking Prevention Policy
* [ ]Contribute
+ Getting Started
+ Contributing Code
+ Testing Contributions
+ How to Report Bugs
+ GitHub Repository
* [ ]Blog
+ News Posts
+ CSS Posts
+ Contributing Posts
+ Privacy Posts
+ Performance Posts
+ JavaScript Posts
+ Standards Posts
+ Web Inspector Posts
+ Safari Technology Preview Posts
* [ ]
WebKit Features in Safari 17.4
Mar 5, 2024
by Jen Simmons and Jon Davis
[ ]
Contents
+ Architectural improvements
+ Web Apps
+ Form elements
+ CSS
+ Web API
+ JavaScript
+ Media
+ SVG
+ WebGL
+ Web Assembly
+ Web Inspector
+ Changes to Safari
+ Safari Extensions
+ Web Authentication
+ Bug Fixes and more
+ Updating to Safari 17.4
+ Feedback
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 beta, macOS Ventura, macOS Monterey, and in visionOS 1.1 beta.
Architectural improvements
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.
Web Apps
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.
Web Kittens web app open on macOS, with the File menu showing and
four custom shortcuts listedOn Mac, our Web Kittens web app includes
four shortcuts. You can see them listed in the File menu: New Kitten,
Discover, Messages, and Notifications. They each open a menu item by
going to the appropriate URL.
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.
Launchpad on macOS showing two app icons in a group titled Social
Networking
Form elements
Switch control
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 , 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
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.)
Vertical writing modes
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.
[vertical-form-controls-light]Try this demo of vertical form controls
in a browser that has support.
Horizontal Rules inside Select
You can use an