June 2021 - webkit-dev - lists.webkit.org

Request for Position: CSS Module Scripts
by Daniel Clark 10 Jun '21

10 Jun '21

Hi WebKit-dev, I'd like to ask for WebKit's official position on CSS Module Scripts, as described in the explainer at [1]. This proposal allows developers to import a CSSStyleSheet using the same import mechanism as JavaScript Modules: import styleSheet from "./styles.css" assert { type: "css" }; The proposal has already been in discussion for a while now (long thread at [2], see also the TAG review [3]), but I think it would be useful to have WebKit's official position on it. Note that use of CSS modules will now require a type: "css" import assertion [4] to prevent the MIME type security issue raised at TPAC 2019 [5]. The CSS Module Script HTML Spec PR is at [6], and is currently blocked on resolution of an open issue [7] in the import assertions TC39 proposal. However import assertions is at Stage 3 so that proposal is unlikely to undergo significant changes. [1] Explainer: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v… [2] Discussion Thread: https://github.com/WICG/webcomponents/issues/759 [3] TAG review: https://github.com/w3ctag/design-reviews/issues/405 [4] Import Assertions: https://github.com/tc39/proposal-import-assertions [5] MIME type security issue: https://github.com/w3c/webcomponents/issues/839 [6] HTML Spec PR: https://github.com/w3ctag/design-reviews/issues/405 [7] Import Assertions host integration issue: https://github.com/tc39/proposal-import-assertions/pull/111 Thanks, Dan Clark Microsoft Edge

1 0

Request for position: COEP: credentialless
by Arthur Sonzogni 10 Jun '21

10 Jun '21

Hi webkit-dev, <webkit-dev(a)lists.webkit.org> This is a request for Webkit's position on Cross-Origin-Embedder-Policy:credentialless *Summary:* Credentialless is a Cross-Origin-Embedder-Policy (COEP) variant. Similarly to require-corp, it can be used to enable cross-origin-isolation. COEP:credentialless causes no-cors cross-origin requests not to include credentials (cookies, client certificates, etc...) *Motivation:* Sites that wish to continue using SharedArrayBuffer must opt-into cross-origin isolation. Among other things, cross-origin isolation will block the use of cross-origin resources and documents unless those resources opt-into inclusion via either CORS or CORP. This behavior ships today in Firefox, and Chrome aims to ship it as well in 2021. The opt-in requirement is generally positive, as it ensures that developers have the opportunity to adequately evaluate the rewards of being included cross-site against the risks of potential data leakage via Spectre. It poses adoption challenges, however, as it does require developers to adjust their servers to send an explicit opt-in. This is challenging in cases where there’s not a single developer involved, but many third parties. It would be ideal if we could find an approach that provided robust-enough protection against accidental cross-process leakage without requiring an explicit opt-in. *Explainer*: https://github.com/mikewest/credentiallessness/blob/main/explainer.md *Specification:* https://htmlpreview.github.io/?https://github.com/mikewest/credentiallessne… *W3C TAG thread:* https://github.com/w3ctag/design-reviews/issues/582 *WICG proposal.* https://github.com/WICG/proposals/issues/31 *ChromeStatus:* https://www.chromestatus.com/features/4918234241302528 Please let us know if you have any feedback! Thanks, Arthur @arthursonzogni

1 0

Request for position: Canvas 2D display-p3 support
by Christopher Cameron 10 Jun '21

10 Jun '21

Hi webkit-dev, (and sorry for the duplicate post here, I mangled the headers on the previous post!) This is a request for WebKit's position on display-p3 support for Canvas 2D. This is already being tracked in bugs.webkit.org here <https://bugs.webkit.org/show_bug.cgi?id=225140>. *Summary:* Adds a color space parameter to CanvasRenderingContext2DSettings, which defaults to "srgb" and can take on the value of "display-p3". Adds ImageDataSettings, which allows specifying a color space parameter to getImageData/createImageData and related constructors. *Spec:* WhatWG spec changes merged in this PR <https://github.com/whatwg/html/commit/85cb202a052c462bd6830b3dda96e7edbd1dc…> . *Tests:* https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/w… Includes tests of ImageData (get and put), and ensuring no loss when doing toBlob and toDataURL round-trips. Thank you for your feedback! Christopher

2 1

Safari/Webkit Team and Developer Communication
by Matthew Thomas 10 Jun '21

10 Jun '21

To *Safari/Webkit-Developers*, I'd like to draw your attention to the following threads on this years WWDC21: https://developer.apple.com/forums/thread/681748 (Safari/Webkit Team and Developer Communication") https://developer.apple.com/forums/thread/681575 (Notifications for Web-Apps on iOS?) As web-developers we feel we have limited influence over Safari (specifically iOS Safari) and there's the growing perception that Safari is being strategically underfunded with specific features never being developed in order to push users towards the AppStore and it's 70+ billion $ in yearly revenue. We also understand that as people who actually develop browsers you are as passionate if not more so than the development community about the open web but we also understand that you don't have control over exactly what gets built/funded. Our feeling is that: - The Safari/Webkit Team does not have the budget/staffing it needs to keep up with the full feature set of a modern browser. - Upper management *strategically underfunds* or does not develop specific features to push developers to use the AppStore instead where Apple can then take a 30% cut off revenue / lock apps into the Apple ecosystem. - Upper Management does not see much value in funding the open-web in general but specifically does not want to fund anything that would allow native-app like functionality in a web-app on a mobile device. - Developer feature requests are largely ignored because of point no 2. - Other browsers are not allowed in iOS primarily because of point no 2. (with privacy/security being a very secondary reason) In terms of developing web-apps Safari on iOS is the *number one limiting factor*. Every year goes past, we request the same basic set of features but the *core *capabilities of web-apps remains largely stagnant. The Safari team needs a much higher budget, a ton more staff and should be able to operate relatively independently of external business goals. Priorities should be set between a combination of what's good for users and what's good for developers, how much money the AppStore makes should not be a consideration when deciding what does and what doesn't get developed. Safari and Web-Apps are often touted by Apple Legal in antitrust/monopoly investigations as the alternative to the AppStore. How can they be the alternative with the current feature set. This threat alone should push Apple to fund the Safari team and make web-apps a viable competitor with native. Please take a read of the linked posts above and please respond if you have any opinions or you don't agree with any of the assumptions/perceptions above. We implore you, talk to your colleagues, directors, senior directors, svps, vps, *advocate* for the open-web / web-apps and try to push Safari in a direction where it at least has the core basic features that native apps have. This change has to come from within the organization, all we can do as outsiders is appeal for your help. Thank-you for your hard work and time, please help us make this change.

1 0

Use of Swift (for bridging) in the WebKit project
by Jer Noble 09 Jun '21

09 Jun '21

Hi all! We're working on some new features that currently use APIs exposed through Swift. We have not yet approved writing and committing WebKit code in Swift, given runtime, library, and just plain mental overhead that comes with adding a new language to the project. But I'd argue that doing so for the purpose of allowing existing C++ code to call into Swift APIs is probably not terrible. Should we relax our "no new language" policy, only for the purposes of allowing our core language code to call into APIs in Swift? (ref: https://bugs.webkit.org/show_bug.cgi?id=226757) Thanks, and look forward to hearing from everyone, -Jer

3 4

sam@webkit.org
by Christopher Cameron 09 Jun '21

09 Jun '21

Hi webkit-dev, This is a request for WebKit's position on display-p3 support for Canvas 2D. This is already being tracked in bugs.webkit.org here <https://bugs.webkit.org/show_bug.cgi?id=225140>. *Summary:* Adds a color space parameter to CanvasRenderingContext2DSettings, which defaults to "srgb" and can take on the value of "display-p3". Adds ImageDataSettings, which allows specifying a color space parameter to getImageData/createImageData and related constructors. *Spec:* WhatWG spec changes merged in this PR <https://github.com/whatwg/html/commit/85cb202a052c462bd6830b3dda96e7edbd1dc…> . *Tests:* https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/w… Includes tests of ImageData (get and put), and ensuring no loss when doing toBlob and toDataURL round-trips. Thank you for your feedback! Christopher

1 0

Re: [webkit-dev] Feedback on Blink's text fragment directive proposal
by David Bokan 09 Jun '21

09 Jun '21

[sending (again, sorry) from correct e-mail] I think Nick's replies <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html> mostly still apply, some updated answers to those questions. (1) We’re concerned about compatibility issues in a world where some > browsers support this but not all. Aware browsers will strip `:~:`, but > unaware browsers won’t. I saw that on the blink-dev ItS thread, it was > mentioned that at least one site (webmd.com) totally breaks if any > fragment ID is exposed to the page. This makes it difficult to create a > link that uses this feature but which is safe in all browsers: > - Since there is no feature detection mechanism, it’s hard for a webpage > to know whether it should issue such a link. It would have to be based on > UA string checks, which is regrettable. > - A link meant for a supporting browser can end up in a non-supporting > browser, at the very least by copy paste from the URL field, and perhaps > through other features to share a link. > We do have a feature detection <https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-futu…> mechanism for this. On the latter point, this is true but we think implementing fragment directive stripping (removing the part after and including `:~:`) is trivial even if the UA doesn't wish to implement the text-fragment feature. FWIW, we haven't seen or heard of another such example since. > (2) The portions of this Community Group report that monkey patch other > standards (HTML, URL and CSSOM View I think?) should be turned into PRs > against those specifications. Monkeypatching other specs is not a good way > to build specifications for the long term. > We still need support from another vendor to start merging the monkey patches into the real standards - if Apple's supportive I'd be happy to start on that immediately. > (3) Text fragment trumping a regular fragment ID seems a bit strange. The > more natural semantic would be that the text search starts at the fragment, > so if there are multiple matches it’s possible to scroll to a more specific > one. It’s not clear why the fragment is instead entirely ignored. > This was discussed in more detail in issue#75 <https://github.com/WICG/scroll-to-text-fragment/issues/75>; I agree with Nick's point that the disambiguation syntax is already specific enough that starting from a fragment isn't necessary. This also keeps us mostly-compatible with the TextQuoteSelector <https://www.w3.org/TR/annotation-model/#text-quote-selector> specified in WebAnnotations which I think may have benefits for interaction with annotation applications. On Mon, Aug 31, 2020 at 1:31 PM David Bokan <bokan(a)google.com> wrote: > I think Nick's replies > <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html> > mostly still apply, some updated answers to those questions. > > (1) We’re concerned about compatibility issues in a world where some >> browsers support this but not all. Aware browsers will strip `:~:`, but >> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was >> mentioned that at least one site (webmd.com) totally breaks if any >> fragment ID is exposed to the page. This makes it difficult to create a >> link that uses this feature but which is safe in all browsers: >> - Since there is no feature detection mechanism, it’s hard for a webpage >> to know whether it should issue such a link. It would have to be based on >> UA string checks, which is regrettable. >> - A link meant for a supporting browser can end up in a non-supporting >> browser, at the very least by copy paste from the URL field, and perhaps >> through other features to share a link. >> > > We do have a feature detection > <https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-futu…> > mechanism for this. > > On the latter point, this is true but we think implementing fragment > directive stripping (removing the part after and including `:~:`) is > trivial even if the UA doesn't wish to implement the text-fragment feature. > FWIW, we haven't seen or heard of another such example since. > > >> (2) The portions of this Community Group report that monkey patch other >> standards (HTML, URL and CSSOM View I think?) should be turned into PRs >> against those specifications. Monkeypatching other specs is not a good way >> to build specifications for the long term. >> > > We still need support from another vendor to start merging the monkey > patches into the real standards - if Apple's supportive I'd be happy to > start on that immediately. > > >> (3) Text fragment trumping a regular fragment ID seems a bit strange. The >> more natural semantic would be that the text search starts at the fragment, >> so if there are multiple matches it’s possible to scroll to a more specific >> one. It’s not clear why the fragment is instead entirely ignored. >> > > This was discussed in more detail in issue#75 > <https://github.com/WICG/scroll-to-text-fragment/issues/75>; I agree with > Nick's point that the disambiguation syntax is already specific enough that > starting from a fragment isn't necessary. This also keeps us > mostly-compatible with the TextQuoteSelector > <https://www.w3.org/TR/annotation-model/#text-quote-selector> specified > in WebAnnotations which I think may have benefits for interaction with > annotation applications. > > On Mon, Aug 31, 2020 at 12:42 PM Darin Adler <darin(a)apple.com> wrote: > >> On Aug 31, 2020, at 9:33 AM, David Bokan <bokan(a)chromium.org> wrote: >> >> We've made lots of improvements to the spec, notably around issues raised >> in Mozilla's standards-position >> <https://github.com/mozilla/standards-positions/issues/194>. >> >> >> Do you think those improvements address Maciej’s concerns from last >> December? Since you didn’t say that explicitly I was wondering what your >> take on that was. >> >> — Darin >> >

6 18

Request for Position: accent-color CSS property
by Joey Arhar 09 Jun '21

09 Jun '21

Hello WebKit devs, I am implementing the accent-color CSS property in Chromium, and I would like to hear WebKit's position on the feature. Chromestatus entry: https://chromestatus.com/feature/4752739957473280 Spec: https://drafts.csswg.org/css-ui-4/#widget-accent CSSWG spec issue: https://github.com/w3c/csswg-drafts/issues/5187 The accent-color CSS property allows web developers to specify a color which is used to paint the "accent" parts of certain form control elements. For example, "accent-color:red" makes checkboxes appear red instead of the default blue. In Chromium, these are input elements with type=checkbox, type=radio, or type=range, as well as progress elements. On MacOS, WebKit already uses the accent color specified by the user in System Preferences to paint type=radio and type=checkbox. The accent-color CSS property would make the form controls paint just like they do with the System Preferences accent color, but specified in CSS instead of in System Preferences. Thanks, Joey Arhar

1 0

Request for Position on alignment keywords in flexbox
by David Grogan 09 Jun '21

09 Jun '21

Hi WebKit devs, I'm making <https://www.chromestatus.com/feature/5777880099323904> Blink's flexbox implementation support the keywords start, end, self-start, self-end, left, right. I.e. finishing flexbox's implementation of https://drafts.csswg.org/css-align-3/#positional-values. Neither Blink nor WebKit currently support those keywords in flexbox. wpt.fyi <https://wpt.fyi/results/css/css-flexbox?label=master&label=experimental&ali…> This is a request for Webkit's position on implementing those keywords in flexbox. Thanks, David

1 0

ImageBitmap support
by Ken Russell 08 Jun '21

08 Jun '21

Hi WebKit folks, Does anyone have thoughts on bringing ImageBitmap support out from behind the experimental feature flag in Safari? As part of recent WebGL feature work, several missing code paths were enhanced, and now all of the ImageBitmap creation paths from various sources like videos, ImageData, etc. are passing tests. Asking on behalf of the MediaPipe <https://mediapipe.dev/> team - this provides the video effects to Google Meet, and they'd very much like to get everything working well in Safari! Thanks, -Ken -- I support flexible work schedules, and I’m sending this email now because it is within the hours I’m working today. Please do not feel obliged to reply straight away - I understand that you will reply during the hours you work, which may not match mine. (credit: jparent@)

1 0