Git Product home page Git Product logo

standards-positions's Introduction

WebKit

WebKit is a cross-platform web browser engine. On iOS and macOS, it powers Safari, Mail, iBooks, and many other applications. For more information about WebKit, see the WebKit project website.

Trying the Latest

On macOS, download Safari Technology Preview to test the latest version of WebKit. On Linux, download Epiphany Technology Preview. On Windows, you'll have to build it yourself.

Reporting Bugs

  1. Search WebKit Bugzilla to see if there is an existing report for the bug you've encountered.
  2. Create a Bugzilla account to report bugs (and comment on them) if you haven't done so already.
  3. File a bug in accordance with our guidelines.

Once your bug is filed, you will receive email when it is updated at each stage in the bug life cycle. After the bug is considered fixed, you may be asked to download the latest nightly and confirm that the fix works for you.

Getting the Code

Run the following command to clone WebKit's Git repository:

git clone https://github.com/WebKit/WebKit.git WebKit

Building WebKit

Building macOS Port

Install Xcode and its command line tools if you haven't done so already:

  1. Install Xcode Get Xcode from https://developer.apple.com/downloads. To build WebKit for OS X, Xcode 5.1.1 or later is required. To build WebKit for iOS Simulator, Xcode 7 or later is required.
  2. Install the Xcode Command Line Tools In Terminal, run the command: xcode-select --install

Run the following command to build a debug build with debugging symbols and assertions:

Tools/Scripts/build-webkit --debug

For performance testing, and other purposes, use --release instead.

Using Xcode

You can open WebKit.xcworkspace to build and debug WebKit within Xcode.

If you don't use a custom build location in Xcode preferences, you have to update the workspace settings to use WebKitBuild directory. In menu bar, choose File > Workspace Settings, then click the Advanced button, select "Custom", "Relative to Workspace", and enter WebKitBuild for both Products and Intermediates.

Embedded Builds

iOS, tvOS and watchOS are all considered embedded builds. The first time after you install a new Xcode, you will need to run:

sudo Tools/Scripts/configure-xcode-for-embedded-development

Without this step, you will see the error message: "target specifies product type ‘com.apple.product-type.tool’, but there’s no such product type for the ‘iphonesimulator’ platform." when building target JSCLLIntOffsetsExtractor of project JavaScriptCore.

Run the following command to build a debug build with debugging symbols and assertions for embedded simulators:

Tools/Scripts/build-webkit --debug --<platform>-simulator

or embedded devices:

Tools/Scripts/build-webkit --debug --<platform>-device

where platform is ios, tvos or watchos.

Building the GTK Port

For production builds:

cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
ninja
sudo ninja install

For development builds:

Tools/gtk/install-dependencies
Tools/Scripts/update-webkitgtk-libs
Tools/Scripts/build-webkit --gtk --debug

For more information on building WebKitGTK, see the wiki page.

Building the WPE Port

For production builds:

cmake -DPORT=WPE -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
ninja
sudo ninja install

For development builds:

Tools/wpe/install-dependencies
Tools/Scripts/update-webkitwpe-libs
Tools/Scripts/build-webkit --wpe --debug

Building Windows Port

For building WebKit on Windows, see the WebKit on Windows page.

Running WebKit

With Safari and Other macOS Applications

Run the following command to launch Safari with your local build of WebKit:

Tools/Scripts/run-safari --debug

The run-safari script sets the DYLD_FRAMEWORK_PATH environment variable to point to your build products, and then launches /Applications/Safari.app. DYLD_FRAMEWORK_PATH tells the system loader to prefer your build products over the frameworks installed in /System/Library/Frameworks.

To run other applications with your local build of WebKit, run the following command:

Tools/Scripts/run-webkit-app <application-path>

iOS Simulator

Run the following command to launch iOS simulator with your local build of WebKit:

run-safari --debug --ios-simulator

In both cases, if you have built release builds instead, use --release instead of --debug.

Linux Ports

If you have a development build, you can use the run-minibrowser script, e.g.:

run-minibrowser --debug --wpe

Pass one of --gtk, --jsc-only, or --wpe to indicate the port to use.

Contribute

Congratulations! You’re up and running. Now you can begin coding in WebKit and contribute your fixes and new features to the project. For details on submitting your code to the project, read Contributing Code.

standards-positions's People

Contributors

annevk avatar erjanmx avatar hober avatar marcoscaceres avatar schweinepriester avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

standards-positions's Issues

Geolocation Sensor

Request for position on an emerging web specification

  • WebKittens who can provide input:

Information about the spec

Design reviews and vendor positions

Anything else we need to know

Defines the GeolocationSensor interface for obtaining the geolocation of the hosting device. The spec claims this is a modern incarnation of Geolocation API. The W3C already have a well-maintained and highly interoperable Geolocation spec. Thus, this new specification seems to provide limited value.

AudioContext.setSinkId

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Anything else we need to know

AudioContext.setSinkId sets the ID of the audio device to use for output. This allows the AudioContext to route audio to a connected output device of user's choosing.

Auto-sizes for lazy-loaded images in HTML

Request for position on an emerging web specification

(Please delete inapplicable rows.)

  • WebKittens who can provide input:

Information about the spec

  • Spec Title: Add sizes=auto to lazy-loaded <img>
  • Spec URL: whatwg/html#8008
  • GitHub repository:
  • Issue Tracker (if not the repository's issue tracker): whatwg/html#4654
  • Explainer (if not README.md in the repository):

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

On webkit-dev, @zcorpan wrote:

I'd like WebKit's position on the proposal: Add sizes=auto to lazy-loaded <img>

This allows web developers to omit the sizes attribute, or explicitly specify sizes=auto, for <img> elements that have loading=lazy. The browser will use the layout width of the image as input to the srcset resource selection (lazy images don't start loading until layout is known, at the earliest). For eager-loading images, it's invalid and equivalent to 100vw.

Chromium position:
whatwg/html#4654 (comment)

CSS overflow for replaced elements

  • WebKittens who can provide input: @smfr. They had input in the CSSWG discussion captured on the issue.

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

This issue has relevant context for the motivation to introduce this functionality for replaced elements. The first resolution was to introduce a new property (object-overflow) but we pivoted to use the existing overflow property based on feedback here.

Anything else we need to know

On WebKit-dev, @khushalsagar wrote:

Hello WebKit!

This is a follow up to previous RFP which introduced the object-overflow property to allow replaced elements to paint with ink overflow. Based on feedback in the CSSWG, the proposal has been updated to use the existing overflow property to provide the same functionality.

The issue capturing the discussion is here. We'd appreciate your feedback on the updated proposal.

Thanks.
Khushal Sagar
Google Chrome team

Deprecating Non-ASCII characters in cookie domain attributes

Request for position on an emerging web specification

(Please delete inapplicable rows.)

Information about the spec

Design reviews and vendor positions

  • TAG Design Review:
  • Mozilla standards-positions issue:

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

On webkit-dev, @johannhof wrote:

Hi folks,

This is a heads up that I'm planning to deprecate non-ASCII characters in
cookie domain attributes in Chromium, meaning that these cookies will be
rejected going forward. See
https://groups.google.com/a/chromium.org/g/blink-dev/c/x3DY-PuZhNw for all
details.

This is following a discussion in the HTTP WG and subsequent
specification in RFC 6265bis. While John Wilander from Apple was part of the discussion, I'd still like to extend the request to this list to give feedback on the proposal.

From my understanding, for Safari, this is handled in the OS network stack
instead of WebKit, and I believe the internal bug on your side to
be rdar://88349235

As both Chromium and Safari currently accept these cookies, there is a
potential for breakage. However, in Chrome, usage appears to be low enough
to move forward with deprecation and removal, see the linked thread above.

Thanks!

Johann

Secure Payment Confirmation (SPC)

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

Over on webkit-dev, @stephenmcgruer wrote:

I am seeking WebKit's position on the Secure Payment Confirmation Web API currently under development in the Web Payments Working Group.

Secure Payment Confirmation (SPC) is a proposed Web API to support streamlined authentication during a payment transaction. It is designed to scale authentication across merchants, to be used within a wide range of authentication protocols, and to produce cryptographic evidence that the user has confirmed transaction details.

SPC adds payment-specific capabilities atop WebAuthn and is designed with stronger privacy protections than current risk analysis approaches that rely on data collection.

MediaTrackSupportedConstraints.backgroundBlur

Request for position on an emerging web specification

(Please delete inapplicable rows.)

  • WebKittens who can provide input: @youennf

Information about the spec

Design reviews and vendor positions

  • TAG Design Review:
  • Mozilla standards-positions issue:

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

On WebKit-dev, @riju wrote:

This is a request for WebKit's position on adding support for Background Blur API on MediaStreamTrack.

The PR that introduced this behavior to the medicapture-extensions spec and the explainer was co-authored by
Apple engineer Youenn Fablet and approved by Jan-Ivar Bruaroey (Mozilla).

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5077577782263808

WebRTC meeting minutes:
https://www.w3.org/2022/05/17-webrtc-minutes.html#t07

Thanks,
Riju.

CSS Cascading and Inheritance Level 6 (@scope)

Request for position on an emerging web specification

  • WebKittens who can provide input: @anttijk

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

This RFP covers the @scope rule only, not the new combinator nor the new notation.

TLS Encrypted Client Hello

Request for position on an emerging web specification

  • WebKittens who can provide input: networking and TLS folks

Information about the spec

Anything else we need to know

Brief summary of the issue or the subject of the spec.

ECH is a mechanism for encrypting the TLS ClientHello (which includes, among other things, the destination hostname) under a server public key.

import.meta.resolve()

Request for position on an emerging web specification

  • WebKittens who can provide input:

Information about the spec

Design reviews and vendor positions

  • TAG Design Review:
  • Mozilla standards-positions issue:

Bugs tracking this feature

Anything else we need to know

On WebKit-dev, @domenic proposed:

We're proposing a small additional function to add to the HTML Standard, named import.meta.resolve(). See the PR 1 and a mini-explainer 2. Gecko folks have reviewed the PR and contributed to the discussion, but any thoughts from WebKit would be very welcome.

We're hoping to ship in Chrome within the next few weeks, and I imagine web developers would love it if you were to also implement. We have a basic implementation and web platform tests you may find useful 3.

Thanks,
Domenic

Declarative Shadow DOM

Request for position on an emerging web specification

  • WebKittens who can provide input: @rniwa

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Would unblock shadow DOM use in above-the-fold content in performance sensitive pages and applications.

Fetch streaming upload

Request for position on fetch streaming upload

  • WebKittens who can provide input: @youennf

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

Streaming upload allows web developers to attach a ReadableStream to a Request. The web developer can pass the Request to fetch() to upload the ReadableStream.

DisplayMediaStreamConstraints.surfaceSwitching

Request for position on an emerging web specification

(Please delete inapplicable rows.)

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

On WebKit dev, @eladalon1983 wrote:

This is a request for WebKit's position on extending getDisplayMedia to
also accept DisplayMediaStreamConstraints.surfaceSwitching.
The PR that introduced this behavior to the getDisplayMedia spec was
approved by Apple engineer Youenn Fablet.

Links:

Document Picture in Picture API

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Anything else we need to know

We'd like to provide the ability for a site to open an always-on-top picture in picture window that supports arbitrary web content, rather than video only. The API proposed in the explainer is approximate, but well within the spirit of what we intend.

ContentVisibilityAutoStateChanged event

Request for position on an emerging web specification: ContentVisibilityAutoStateChanged event

Information about the spec

Design reviews and vendor positions

Anything else we need to know

CSSWG discussion: w3c/csswg-drafts#7384 (comment)

meta: add some sort of auto-triage

There's various bits of auto-triaging we could do when an issue is filed; from the spec URL we can infer the venue of the work, and in many cases we can infer topic from that too.

Controlling screen brightness

Hello WebKittens (@marcoscaceres)!

Your input is welcome on the ability to control screen brightness, and if it is positive, then further input on how we should expose that on the web platform would be valuable.

Feedback and positions from the community and other browser vendors is being collated below:

w3c/screen-wake-lock#335

Form-associated custom elements

Request for position on form-associated custom elements

Information about the spec

Design reviews and vendor positions

  • Chromium and Mozilla have full implementation

Bugs tracking this feature

Anything else we need to know

APIs using for allowing custom elements to participate in form submission and constraint validation. Chromium and Mozilla have shipped this feature and WebKit has begun implementing ElementInternals; however, WebKit's implementation currently lacks the form-associated APIs.

Constructable Stylesheet Objects (including adoptedStyleSheets)

Request for position on an emerging web specification

(Please delete inapplicable rows.)

  • WebKittens who can provide input:

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

N / A

Anything else we need to know

From the WCCG's report to TPAC in 2021

Constructable Stylesheets and adoptedStyleSheets enable adding styles directly to shadow roots without creating new DOM elements. Because a single stylesheet object can be adopted by multiple scopes, it also allows sharing of styles that can be centrally modified.

Motivation

  • There is no effective way to share styles across components while allowing them to be centrally modified.
  • Creating <style> elements for each style used in each shadow root has a measurable performance overhead.
  • CSS Module Scripts, another critical feature, depends on constructible stylesheets.

Scoped Custom Element Registries

Request for position on an emerging web specification

(Please delete inapplicable rows.)

  • WebKittens who can provide input: @rniwa

Information about the spec

Additionally, here is a writeup from the WCCG that was presented at last year's TPAC
https://w3c.github.io/webcomponents-cg/#scoped-element-registries

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Brief summary of the issue or the subject of the spec.
(taken from the OP)

The global registry is a possible source of name collisions that may arise from coincidence, or from an app trying to define multiple versions of the same element, or from more advanced scenarios like registering mocks during tests, or a component explicitly replacing an element definition for its scope.
...
This proposal adds the ability to construct CustomElementRegistrys and chain them in order to inherit custom element definitions. It uses ShadowRoot as a scope for definitions.

Web Share Target API

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Summary: While the Web Share API allows browsers to make use of the operating system's native "share" mechanism in web-to-native contexts, the Web Share Target API intent is to enable web-to-web and native-to-web sharing scenarios.
What is WebKit's position on this spec?

VirtualKeyboard API

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Implemented in Chromium: https://web.dev/virtualkeyboard/

File System Access API (Local Filesystem)

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

The File System Access API allows websites to directly interact with the computer's local files. Shipped in Chromium 86.

Note: I'm not talking about the Origin Private File System part of the File System Access API that has already been implemented in WebKit, but about the part that allows for direct access to local files.

View Transitions API Level 1

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

The spec still has some open issues but the overall feature design is concrete at this point. Also here is the chrome status entry.

HTTP response status code in Resource Timing

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Link to entry on the Chrome Platform Status: https://chromestatus.com/feature/5163838794629120

CSS Properties and Values API Level 1

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

CHIPS (Cookies Having Independent Partitioned State)

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Anything else we need to know

CHIPS is a proposal for a new cookie attribute, Partitioned. This attribute will indicate to user agents that these cross-site cookies should only be available in the same top-level context that the cookie was first set in.

CHIPS has been discussed in PrivacyCG and beyond for a while, and participants from other browsers including Safari (@johnwilander) have generally signaled support so far (with a few details to figure out), see privacycg/proposals#30.

Import Maps

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Import maps unlock much value in using javascript modules, allowing developers to use "bare specifiers", aliasing modules to versioned urls, etc.

Align Timers (including DOM timers) at 125 Hz

Request for position on an emerging web specification

Information about the spec

Anything else we need to know

Note that this is not a new spec. This Chrome feature changes the behavior of an existing web API in a way that is spec-compliant.
The feature runs all timers (with a few exceptions) with a non-zero delay on a regular 8ms aligned wake up (125 Hz), instead of as soon as their delay has passed.
This affect DOM timers; On foreground pages, run DOM timers with a non-zero delay on a regular 8ms aligned wake up, instead of as soon as their delay has passed.

Navigation API

Request for position on an emerging web specification

  • WebKittens who can provide input:

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

Linked explainers explain it well.

From a developer point of view this is a massive leap forward over the existing, kludgy solutions for routing / navigation interception. This is a difficult API to polyfill correctly, but a positive signal from WebKit would allow us to at least know there's a better future on the way.

From a framework implementer point of view, the biggest win with this API would allow us to properly centralize route handling, and perhaps begin to share / reuse more framework agnostic routing mechanisms. Most frameworks today must intercept anchor click events and effectively spoof navigation behavior, and this behavior is generally not compatible across various implementations, and requires a fair bit of (often brittle) code.

Angular : https://github.com/angular/angular/blob/main/packages/router/src/directives/router_link.ts#L396-L415
Vue: https://github.com/vuejs/router/blob/main/packages/router/src/RouterLink.ts#L138-L301
Remix: https://github.com/remix-run/react-router/blob/main/packages/react-router-dom/index.tsx#L270-L301

WebXR Raw Camera Access API

Request for position on an emerging web specification

  • WebKittens who can provide input: @grorg as a WebKitten involved in Immersive Web CG/WG

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

The WebXR Raw Camera Access Module extends the capabilities of the core WebXR Device API by allowing the sites to request "camera-access" feature when creating XR sessions. The feature allows the sites to obtain access to camera pixels (via an integration with WebGL, exposing the pixels as WebGLTextures). This capability has been requested for a long time by developers.

WebTransport

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

Chrome added their prototype support to it on version 97: https://chromestatus.com/feature/4854144902889472

Gamepad API Trigger-Rumble Haptics Extension

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

We would like to extend the GamepadHapticActuator interface to expose the trigger-rumble capability in the Web for compatible gamepads.

P.S.: I have already sent an email to webkit-dev, but decided to continue the discussion here.

Shared Storage

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

On WebKit-dev, Eric Trouton wrote:

Hi Webkit-Dev Team,

We've been working on the Shared Storage API that supports a variety of use cases that may be impacted by 3rd Party Cookie Deprecation. The idea is to provide a storage API (named Shared Storage) that is intended to be unpartitioned. Origins can write to it from their own contexts on any page.
To prevent cross-site tracking of users, data in Shared Storage may only be read in a restricted environment that has carefully constructed output gates. Over time, we hope to design and add additional gates.

We would like to hear what you think about it. Chrome is implementing (available in Chrome Canary on M104) but open to evolving the API over time and are appreciative of your feedback.

chrome status: https://chromestatus.com/feature/6256348582903808

spec: TBD

Thank you,
Eric

User Preference Media Features Client Hints Headers

Request for position on an emerging web specification

  • WebKittens who can provide input: ?

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

This has been implemented by Google Search.

Web Custom formats for Async Clipboard API

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

Previous request for position in webkit-dev: https://lists.webkit.org/pipermail/webkit-dev/2021-May/031855.html

Web custom formats for Async Clipboard API aims to web applications read and write custom, unsanitized, web-originated payloads from the clipboard using a standardized web custom format. Support for this is important for allowing native applications to exchange data with web applications outside the standardized formats.

I'm filing this request because Adobe is interested in this API for supporting copy/paste interop between our web and native applications using our own formats.

Iframe credentialless (was: Anonymous iframe)

Request for position on an emerging web specification

This was previously filled as: https://lists.webkit.org/pipermail/webkit-dev/2022-April/032205.html
but didn't get any replies. Since WebKit is now using this new Github Medium, I am asking again. We would appreciate your feedback. In particular, there is a recent discussion with Mozilla who suggested activating it via a sandbox flag instead.

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

Anonymous iframes give developers a way to load documents in third party iframes using new and ephemeral contexts.

Anonymous iframes are a generalization of COEP credentialless to support 3rd party iframes that may not deploy COEP. Like with COEP credentialless, we replace the opt-in of cross-origin subresources by avoiding to load non-public resources. This will remove the constraint that 3rd party iframes must support COEP in order to be embedded in a COEP page and will unblock developers looking to adopt cross-origin-isolation.

This way, developers using COEP can now embed third party iframes that do not.

Wildcards in Permissions Policy Origins

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Design Doc

This feature will add support for wildcard in permissions policy structured like SCHEME://*.HOST:PORT (e.g., https://*.foo.com/) where a valid Origin could be constructed from SCHEME://HOST:PORT (e.g., https://foo.com/). This requires that HOST is at least eTLD+1 (a registrable domain). This means that https://*.bar.foo.com/ works but https://*.com/ won’t (if you want to allow all domains to use the feature, you should just delegate to *). Wildcards in the scheme and port section will be unsupported and https://*.foo.com/ does not delegate to https://foo.com/.

Before, a permissions policy might need to look like:
permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://cdn1.foo.com" "https://cdn2.foo.com" "https://foo.cdn2.foo.com")

With this feature, it could look like:
permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://*.foo.com")

Eyedropper API

Request for position on an emerging web specification

  • WebKittens who can provide input: @pxlcoder

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Brief summary of the issue or the subject of the spec.
API that allows users to choose colors from anywhere on the screen

Render blocking status in Resource Timing

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Introducing field to PerfomanceResourceTiming to indicate the render blocking status of a resource
Link to entry on the Chrome Platform Status: https://chromestatus.com/feature/5166965277589504

HTTP Client Hints + Client Hints Infrastructure

Request for position on an emerging web specification

Information about the spec

Additional spec URL, repository, and issue tracker: https://wicg.github.io/client-hints-infrastructure/, https://github.com/WICG/client-hints-infrastructure, & https://github.com/WICG/client-hints-infrastructure/issues/.

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

These two specs jointly define the underlying infrastructure and mechanisms of Client Hints, but don't actually specify any hints themselves. Filing this mostly to have something to then link to when we're asked for opinions on specific client hints, for general client hint infra discussion.

Web Background Synchronization (BackgroundSync)

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Background sync is a new web API that lets you defer actions until the user has stable connectivity.
This is useful for ensuring that whatever the user wants to send, is actually sent.

App Manifest "screenshots" member

Request for position on supporting "screenshots" member in app manifest

(Please delete inapplicable rows.)

  • WebKittens who can provide input:

Information about the spec

Design reviews and vendor positions

Bugs tracking this feature

Anything else we need to know

Most browsers have facilities to enable users to add a website to their homescreen. Several browsers provide the ability to install PWAs. Currently the context that’s available to convey is the website’s origin, as well as the name and icons made available through the Web App Manifest. This is different from other store mechanisms, on all platforms, that also share developer-provided information such as a description and screenshots.

Microsoft’s Aaron Gustafson has proposed a Web App Manifest Application Information draft (see spec above), through which we can obtain that information.

Chrome implemented a new, richer user interface on mobile that displays this information (description and screenshots) when the developer has provided it (See help article). Chrome has started experimenting this on Desktop.
We’ve carefully designed this interface to continue to highlight known information such as the origin, and are working with the permissions and privacy teams to make sure we can evolve it responsibly going forward.

MSE-in-Workers

Request for position on an emerging web specification

Information about the spec

Design reviews and vendor positions

Anything else we need to know

See also the previous request for position in 2021 on the webkit-dev list: https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html

This feature addition to the Media Source Extensions specification enables web apps to use the MSE API in a DedicatedWorker. The app can attach a worker MediaSource object to a window/main context HTMLMediaElement by obtaining a MediaSourceHandle from the MediaSource object, transferring it to the window/main context, and setting that handle on the media element's srcObject attribute. This feature's specification has iterated in the W3C Media Workgroup, and has incorporated all feedback received to date. Experimental implementation in Chrome has already been reported to produce strongly positive metrics improvements by at least one origin trial site, due to the ability to perform media fetching and buffering in a worker context without blocking so much on a busy main/window context.

WebAssembly Relaxed SIMD

Request for position on an emerging web specification

(Please delete inapplicable rows.)

  • WebKittens who can provide input:

Information about the spec

Design reviews and vendor positions

  • TAG Design Review:
  • Mozilla standards-positions issue:

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

On WebKit-dev, @dtig wrote:

Hi webkit-dev,

The WebAssembly Relaxed SIMD proposal introduces new vector operations that
take advantage of widely available instruction sets to accelerate compute
workloads. The proposal relaxes the strict portability constraints of
the fixed-width
SIMD proposal. We're
hoping to ship this in Chrome 105/106 contingent on a Phase 4
(currently at Phase 3) vote in the Wasm CG, requesting a WebKit position for the proposal.

Proposal: https://github.com/WebAssembly/relaxed-simd
Spec: https://github.com/WebAssembly/relaxed-simd/tree/main/document/core
Implementation status (V8, SpiderMonkey):
https://github.com/WebAssembly/relaxed-simd/blob/main/proposals/relaxed-simd/ImplementationStatus.md
Preliminary performance data that motivated the proposal:
WebAssembly/simd#79

Thanks,
Deepti

Custom Highlight API

Request for position on an emerging web specification

(Please delete inapplicable rows.)

Information about the spec

  • Spec Title: CSS Custom Highlight API Module Level 1
  • Spec URL: https://drafts.csswg.org/css-highlight-api-1/
  • GitHub repository:
  • Issue Tracker (if not the repository's issue tracker):
  • Explainer (if not README.md in the repository):

Design reviews and vendor positions

Bugs tracking this feature

  • WebKit Bugzilla:
  • Radar:

Anything else we need to know

On WebKit-dev, @dandclark wrote:

Hi webkit-dev,

I would like to request WebKit's current position on the CSS Custom Highlight API [1]. Edge and Chrome are planning to ship this soon [2].

Safari implemented an early version of this API in 99 [3], gated behind the Highlight API experimental flag. It looks like it's been updated since then to match changes in the spec, e.g. HighlightRangeGroup has been renamed to Highlight. The remaining major difference between the Safari and Chromium implementation is that the Safari implementation doesn't yet support live Ranges, only StaticRanges. The API is still off-by-default, behind the experimental flag.

Is there anything that can be shared about WebKit's plans to further develop the API and eventually ship it on-by-default?

Thanks,
Dan Clark

[1] https://drafts.csswg.org/css-highlight-api-1/
[2] https://groups.google.com/a/chromium.org/g/blink-dev/c/pxgVrAzMfyk
[3] https://developer.apple.com/safari/technology-preview/release-notes/#r99

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.