August 2020 - webkit-dev - lists.webkit.org

Request for feedback on CompressionStream and DecompressionStream
by Adam Rice 02 May '22

02 May '22

I am trying to gauge feedback on compression streams with a view to shipping them in Chromium. Very briefly, they are a way to do gzip and gunzip in the browser. Less briefly, the explainer https://github.com/WICG/compression/blob/master/explainer.md goes into some detail of the how and why. The specification https://wicg.github.io/compression/ gives verbose detail of how. You may also find the W3C TAG review https://github.com/w3ctag/design-reviews/issues/410 interesting. Any and all feedback is welcome! FAQ: Q. Will this support brotli, zstd, etc.? A. Not yet. It's on the radar. Thanks, Adam Rice, Chromium

3 3

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 on Import Conditions
by Daniel Clark 09 Mar '21

09 Mar '21

Hello WebKit-dev, I'd like to ask for WebKit's official position on import conditions, as described in the explainer at [1]. This proposal adds an inline syntax for module import statements to pass on more information alongside the module specifier. It includes support for JSON modules as a primary application, with the "type" condition used to mitigate the security issue described in [2] that previously blocked their adoption in HTML. The proposal is designed such that other conditions can be added in the future for additional use cases, some of which may not yet be anticipated. The champion group is particularly interested in your opinion on whether it's acceptable for import conditions to not be part of the module map key. The current state of our HTML spec integration PR at [3] is that they are not part of the module map key. We perform module map caching such that there will always be no more than a single fetch for a given module specifier regardless of failed module type checks. The thread at [4] discusses this issue in detail. We plan to request Stage 3 for this proposal at the upcoming TC39 meeting beginning on July 20. [1] Explainer: https://github.com/tc39/proposal-import-conditions [2] Modules MIME-type security issue: https://github.com/w3c/webcomponents/issues/839 [3] HTML Spec integration PR: https://github.com/whatwg/html/pull/5658 [4] HTML integration thread: https://github.com/whatwg/html/issues/5640 Mozilla standards-position ("worth prototyping") https://github.com/mozilla/standards-positions/issues/373 Thanks! Dan Clark

1 1

Position on emerging standard: Declarative Shadow DOM
by Mason Freed 24 Feb '21

24 Feb '21

Hello WebKit! I would like to request an official WebKit position on the Declarative Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890 Please see below for all of the relevant supporting documents and discussions. Explainer: https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335 Thanks, Mason Freed

2 9

Feedback on the performance.measureMemory API proposal
by Ulan Degenbaev 14 Dec '20

14 Dec '20

Hello webkit-dev, I'd like to solicit feedback as well as an official position from Webkit on our proposal for the new memory measurement API: https://github.com/WICG/performance-measure-memory The proposal generalizes the previous performance-memory proposal [1] that was abandoned [2] due to information leak of cross-origin resources. The new API addresses the information leak and process model issues raised in the previous feedback [3]. What is different in the new API? - It relies on COOP+COEP [4] for preventing cross-origin information leaks (see "Security Considerations"). Besides security, COOP+COEP also helps implementability because the browser needs to isolate the web page from other web pages. - It does not assume any particular process model and is defined using the standard concepts such as JS agent cluster and browsing context group. - It has an extensible and generic interface for breaking down memory usage by type (JS, DOM, GPU) and owner. Implementers can choose the level of detail they are willing to provide based on their performance trade-offs (see "Performance Considerations"). Thank you, Ulan. [1]: The previous proposal: https://github.com/WICG/performance-memory/blob/master/explainer.md [2]: Information leak affecting the previous proposal: https://github.com/mozilla/standards-positions/issues/85#issuecomment-42638… [3]: Feedback from Apple on the previous proposal: https://github.com/WICG/performance-memory/issues/14 [4]: COOP and COEP explained: https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0G… Other Relevant Links Explainer: https://github.com/WICG/performance-measure-memory Open issues: https://github.com/WICG/performance-measure-memory/issues WebPerf WG F2F June 2019 presentation (for older iteration of the API): https://docs.google.com/document/d/1uQ7pXwuBv-1jitYou7TALJxV0tllXLxTyEjA2n1… TAG design review (for older iteration of the API): https://github.com/w3ctag/design-reviews/issues/386 Issue on Mozilla standards-positions: https://github.com/mozilla/standards-positions/issues/281

1 1

Request for position on the Origin-Isolation header
by Domenic Denicola 11 Dec '20

11 Dec '20

Hello webkit-dev, I've been working on a new header called Origin-Isolation, which is a way of allowing origins to opt-out of using document.domain and cross-origin sharing of WebAssembly.Module, and thus allowing the browser to put them into an origin-keyed agent cluster instead of a site-keyed one. This could in turn allow the browser to make better behind-the-scenes decisions for process isolation, or other resource allocation decisions, since sites no longer have any ways to synchronously communicate cross-origin. Relevant links: * Explainer: https://github.com/WICG/origin-isolation * HTML spec PR: https://github.com/whatwg/html/pull/5545 * Test suite: https://github.com/web-platform-tests/wpt/tree/master/origin-isolation * Gecko "worth prototyping" standards position: https://mozilla.github.io/standards-positions/#domenic-origin-isolation A natural question one might ask is how this relates to COOP+COEP? The explainer has that covered: https://github.com/WICG/origin-isolation#coop--coep Thanks for your time! -Domenic

3 4

Request for position on Schemeful Same-Site
by Steven Bingler 30 Nov '20

30 Nov '20

Hello WebKit-dev, I'm seeking WebKit's position on Schemeful Same-Site. I've provided the explainer [1], spec [2], TAG review [3], and Blink's I2P [4] which contains some additional discussion you may find useful. Thanks, Steven [1] Explainer: https://github.com/sbingler/schemeful-same-site [2] Spec: https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incremen… [3] TAG Review: https://github.com/w3ctag/design-reviews/issues/497 [4] Blink I2P: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qB7DKqxkiaA

3 4

Request for position on Event Timing
by Rob Buis 23 Oct '20

23 Oct '20

Hi Webkit-Dev, I would like to get an official position from Webkit on the Event Timing Web Perf API. Besides providing information about input event latency it can be used to obtain First Input Timing metrics. This specification builds on the Performance Timeline specification, which is implemented in Webkit. Chrome has implemented the Event Timing API, see the chrome status entry below. - Specification: https://wicg.github.io/event-timing/ - Explainer: https://github.com/WICG/event-timing - MDN: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming - ChromeStatus: https://chromestatus.com/feature/5167290693713920 - Caniuse.com URL: https://caniuse.com/#feat=mdn-api_performanceeventtiming Regards, Rob.

5 8

Implementing MathML stylistic attributes in WebKit
by Frédéric Wang 28 Sep '20

28 Sep '20

Hello, Currently MathML attributes mathvariant, displaystyle and scriptlevel [1] [2] are implemented in WebKit using custom "style resolution" and "one-glyph rendering" inside the MathML layout code [3] [4] [5]. These features involve text rendering and interaction with CSS font-size, so it is difficult to implement them properly and completely that way. There are known bugs and missing features right now (e.g. mathvariant transform only applies to one-character strings, automatic displaystyle/scriptlevel does not work with fractions, etc) Several years ago, Gecko used to do something similar but that was causing a lot of problems (dynamic update, assertion failures...). At the end, this is now implemented in Gecko more reliably by mapping the attributes to internal CSS properties ; [6] is based on that. When I tried to do something like this in WebKit three years ago, I was only able to rely on proprietary -webkit-* extensions exposed to users [7]. So my questions are: (1) What is WebKit's mechanism to implement such stylistic attributes? (2) Is it possible to implement internal (i.e. not web-exposed to users) CSS properties/values in WebKit? (3) Is it ok to add more -webkit-* properties/values or should these properties be standardized at the CSS WG instead? I understand answers to these general questions from other browser project is either use internal properties or standardize them. Thanks, Frédéric PS: For a concrete example, see [8]. Automatic mathvariant is used for italic variables while font-size in fractions is calculated according to displaystyle / scriptlevel rules. The latter is incorrect (check the attached screenshot) while selection highlight is broken for the former. [1] https://mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute [2] https://mathml-refresh.github.io/mathml-core/#the-displaystyle-and-scriptle… [3] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/mathml.css [4] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathm… [5] https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathm… [6] https://mathml-refresh.github.io/mathml-core/#css-extensions-for-math-layout [7] https://bugs.webkit.org/show_bug.cgi?id=133845#c5 [8] https://bug-201242-attachments.webkit.org/attachment.cgi?id=377730 -- Frédéric Wang

2 4

Requesting a position on Document Policy
by Ian Clelland 22 Sep '20

22 Sep '20

Hi WebKit! I'm building out the infrastructure in Blink for Document Policy, and would like to ship at least part of it in Chrome for developers to take advantage of. I'd like to get an official position from WebKit leads on this. I'm also interested in getting thoughts from other WebKit folks about the design or implementation. Some details: Document Policy explainer: https://github.com/w3c/webappsec-permissions-policy/blob/master/document-po… Document Policy spec: https://w3c.github.io/webappsec-permissions-policy/document-policy.html GitHub Repository (shared with Permissions Policy (previously Feature Policy)): https://github.com/w3c/webappsec-permissions-policy Blink intent-to-ship discussion: https://groups.google.com/a/chromium.org/g/blink-dev/c/Za159T1QOek/m/lewQUF… Also previously discussed at the TAG: https://github.com/w3ctag/design-reviews/issues/408 I think that the last time I brought this to WebKit engineers would have been at TPAC last year, where it was discussed in the WebAppSec meetings as a way to provide a general configuration mechanism for documents, splitting off of ideas that had been floating around at the time for Feature Policy. While Document Policy itself doesn't prescribe any actual features, it could eventually be used to configure the behaviour of different web-platform features, such as: - Restricting the use of poorly-performing images - Disabling slow synchronous JS APIs - Configuring frame, image, or script loading styles - Restricting overall document sizes or network usage - Restricting patterns which cause page re-layout The initial intent, though, is to ship part of this in Chrome to support an opt-out for the Scroll-to-text-fragment feature. Document Policy has two different mechanisms which can work in conjunction with each other: The first is the Document-Policy (and Document-Policy-Report-Only) HTTP header, which just sets the policy on the document it ships with. The other is a negotiation mechanism between an embedder and its embedded content, which uses an Iframe attribute and an additional request header. I'm currently interested in shipping just the first of these mechanisms in Chrome. The second may warrant more discussion and review, and isn't needed for the Scroll-to-text-fragment opt-out. The details are in the Chrome Platform Status entry: https://www.chromestatus.com/feature/5756689661820928 Feel free to ask any questions; I'm happy to discuss this in whatever forum works best for folks, Thanks! Ian

2 2