Transcript
[ Music ]
[ Applause ]
>> Good morning, everyone.
My name is Devin.
I'm thrilled to be here today
with all of you to tell you
about what's new in WebKit.
There's a lot we have to talk
about today, so we're going to
dive right in.
There are a lot of things that
are new and exciting for the web
platform and for web developers
this year.
Today's talk is going to cover a
variety of different topics
ranging from web specific APIs
to new ways that you can provide
a more native experience from
within your web content.
We have a lot to discuss, so
we're going to dive right in
starting with Dark Mode.
The system Dark Mode was first
introduced in MacOS Mojave.
But this year, it also comes to
iOS as part of iOS 13.
This means that the desktop
experience and the mobile
experience can now both adapt to
Dark Mode.
But don't worry.
It, it's not that complicated.
It's very easy to have your web
content also adapt to Dark Mode.
Let's take a look at it.
First, adding a color scheme CSS
property to any root CSS rule
with a value that includes dark
will tell WebKit that the entire
page supports Dark Mode.
And when in Dark Mode, the
default text and background
colors, as well as any form
controls, will automatically
update to match the rest of the
darker theme.
But as you can see, this won't
do anything for custom styles.
So, you'll still need to update
them yourself.
The way you can do that is using
a prefers color scheme dark CSS
media query.
It behaves just like any other
CSS media query, meaning that
the contained styles only apply
when the system is in Dark Mode.
You can use this to change any
other custom styles like CSS
images or other colors to match
the rest of the darker theme on
the page.
But for images that are not in
CSS, you can always use the
picture element through HTML.
And using the exact same media
query it will cause the two
images to automatically switch
between when the user enables
Dark Mode.
It's that simple.
And obviously, for any other
content, you can always use the
JavaScript matchMedia API,
again, with the exact same media
query to handle any other
dynamic content.
All of these techniques make it
really easy for you to adapt
Dark Mode to support the rest of
your web content.
And we can't wait to see your
super cool dark websites.
For more information about this,
there's a great post on the
WebKit blog and a great video in
the WWDC App that talks all
about supporting Dark Mode in
web content.
Be sure to check it out.
And that's a very quick look at
how to support Dark Mode in your
web content.
It's very easy.
Next, let's talk about a very
simple API that you can use
called Web Share which allows
you to invoke the native share
sheet from within web content.
It's standardized and it works
anywhere, whether that be in
Safari or in WK web view in an
app.
It's especially great on iOS
this year with all of the
improvements to the native share
sheet.
Using it is as simple as calling
navigator.share with the
relevant data.
It returns a promise which
resolves if a share action is
completed or rejects if the
share sheet is dismissed.
But keep in mind this API
expects to be called in response
to a user gesture like a tap.
So, if that's not the case, it
will immediately reject.
One of the cool things is that
you can already see the Web
Share API in action as it's been
adopted by some pretty major
websites.
A great example of this is
Twitter which also has some
phenomenal support for Dark
Mode.
Tapping any of the Share icons
on the page will open the native
share sheet with the title and
link of that tweet.
And you can try this out for
yourself in iOS 12.2 or later.
And that's the Web Share API.
A really simple way to invoke
native functionality from within
your web content.
Now, let's move a little bit on
to some new media features.
If you're developing a website
that strives to display the
content that is best suited for
the user's device.
You can now use the new Media
Capabilities API to determine
whether any video codec is
supported as well as if that
video codec will be fast enough
to knock off any frames or will
be power efficient during
playback.
This empowers you to make a more
informed decision about the type
of content you want to present.
And speaking of video content,
macOS Catalina and iOS 13 also
bring support for alpha channel
video.
Alpha channel video allows for
any HEVC encoded video content
to contain transparent pixels.
A very compelling use case of
this is that it allows your
video to seamlessly integrate
with the surrounding content
when the user enables Dark Mode.
Instead of making two separate
videos, one for use in Light
Mode and one for use in Dark
Mode, a single video with a
transparent background would
likely work for both.
And alpha channel videos can be
used anywhere that videos can be
used today.
There's no special syntax,
there's no special MIME type.
It just works.
But before you use it, you'll
want to make sure that alpha
channel video is available, such
as on older iOS or older macOS,
which you can do by adding an
alpha channel key to the, to
your capabilities object when
using the Media Capabilities
API.
If you'd like to know a little
bit more about alpha channel
video, including how to create
those videos on macOS Catalina,
be sure to check out the video
about creating HEVC videos with
alpha.
But if instead, you're a web
developer who builds a website
that includes peer-to-peer chat
functionality and you also want
to provide screen capture, you
can now use the getDisplayMedia
API in Safari 13.
Calling it will gain return a
promise and immediately prompt
the user for permission to
capture their screen.
If that permission is granted,
the promise will return with a
standard media stream of the
space that contains the Safari
window.
The returned media stream
behaves just like any other
standard media stream, meaning
that it can be used with WebRTC
to share your screen with
another person.
And those are some of the new
media features coming to macOS
Catalina, iOS 13, and Safari 13.
Now, we're going to talk a
little bit about a few new tools
that you can use to make your
web content more responsive and
performant on all platforms.
As web developers, part of our
job is to make sure that we
provide an experience that
doesn't consume too much battery
or unnecessarily perform
actions.
To help you better understand
why those things might be
happening, the Web Inspector has
added a new CPU Timeline.
This interface is packed with
actionable information.
And we really want you to be
able to use it effectively.
So, we've created a post on the
WebKit blog and a video in the
WWDC App all about understanding
CPU usage with Web Inspector.
Definitely check it out.
It'll do wonders for your
website.
And WebDriver is coming to iOS.
The standardized test format
from the W3C for automation and
regression testing is available
on all iOS devices running iOS
13.
You can use WebDriver to
automate regression testing of
your web content and make sure
that your, all the platforms you
support, whether that be desktop
or mobile, keep working exactly
as you would expect.
WebDriver on iOS works much the
same as on macOS.
And we have phenomenal
documentation for that on
developer.apple.com.
And we have some blog posts
coming soon to talk more about
it.
Now, let's change it a little
bit and talk about how to store
structured data from within your
web content.
There have been two main ways of
doing this in the past;
IndexedDB and WebSQL.
In Safari 13, WebSQL has been
completely removed.
All modern web browsers,
including Safari, support
IndexedDB.
And over the past year, we've
been hard at work making it more
standards compliant.
So, if you haven't already, be
sure to transition to using
IndexedDB as soon as possible.
And finally, let's talk about
Apple Pay, the easiest way to
accept payments on the web.
We have two main things to talk
about.
The first, Apple Pay, is now
fully supported with all of its
capabilities using the Payment
Request API.
Bringing the entirety of Apple
Pay JS's private, secure, and
streamlined experience to your
web content in a more
standardized way.
We strongly encourage you to
switch to the Payment Request
API as it supports everything
that Apple Pay JS can do and
it's continuing to evolve.
For a deeper dive into how to
use the Payment Request API for
Apple Pay, there's going to be a
great post on the WebKit blog
later today that'll do a deep
dive into these new
improvements.
And second, in iOS 13, you can
now use Apple Pay inside a
WKWebView.
Yeah.
[ Applause ]
This means that Apple Pay is now
available in even more apps.
But there are a few things to
consider.
When a user attempts to make a
purchase through Apple Pay,
there's an expectation that
they're communicating with the
page, not the containing web
browser or app.
Nothing should get in between
the user and the webpage during
the transaction or before it's
even started.
So, this means there are fewer
restrictions about when you can
use Apple Pay inside the
WKWebView as well as when you
can inject script into a
WKWebView.
Here's how it works.
If any script has ever been
injected to the current page of
the WKWebView, we will not allow
Apple Pay.
If the current page has already
called canMakePayments with an
Apple Pay payment method, we
will not allow any future script
injections.
They will be blocked with an
error.
But both of these restrictions
are only limited to the current
page.
So, any top-level navigation
will cause them to reset.
So, what does all of this mean?
If you're a web developer, it's
really important that you call
canMakePayments before you
attempt to show an Apple Pay
button or even start anything
with Apple Pay.
This way, your users will never
encounter a situation where an
Apple Pay button is shown and
tapping on it doesn't do
anything because it's been
disabled.
And if instead, you're an app
developer, really think about
whether you actually need to
inject script such as through
the WKUserScript API or the
evaluateJavaScript with
completionHandler call.
We've seen some examples in the
past of apps injecting script
when there's a WebKit API that
does the exact same thing.
There's no reason for that.
By injecting script, you could
be preventing the loaded web
content from providing its best
experience.
And that's what's new with Apple
Pay.
This was a quick look at some of
the great features available
that are new for web developers
this year.
You'll also definitely want to
check out Introducing
Desktop-class Browsing on iPad,
which covers how to use some
other new web platform features
like pointer events to really
make your desktop website feel
right at home on iPad.
I really hope you've enjoyed
learning about what's new for
web developers.
We can't wait to see what
beautiful designs and incredible
experiences you craft with these
new features and tools that are
available to you.
Have a great day.
[ Applause ]