July 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

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 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

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

PSA: Bit fields won't be packed on Windows if you mix types
by Ryosuke Niwa 04 Sep '20

04 Sep '20

Hi, Unlike gcc and clang, MSVC pads each consecutive member variables of the same type in bitfields. e.g. if you have: struct AB { unsigned m_1 : 31; bool m_2 : 1; } then *MSVC pads m_1 and allocates sizeof(unsigned) * 2 for AB* whereas gcc and clang only allocate sizeof(unsigned) * 1 for AB. This is *not a compiler bug*. It's a spec. compliant behavior, and may in fact have a better run-time performance in some situations. However, for core objects like RenderObject and InlineBox, allocating extra 4-8 bytes per each object is prohibitory expensive. In such cases, please *use the same POD type for all bitfield member variables*. (Storage class classifiers and variable qualifiers seem to have no effect on how variables are packed; e.g. mutable, const, etc...). For example, MSVC will allocate sizeof(unsigned) * 1 for AB if we rewrite the above code as: struct AB { unsigned m_1 : 31; unsigned m_2 : 1; } When you're making this change, *be sure to audit all code that assigns a non-boolean value to m_2* because implicit type coercion into boolean is no longer in effect. For example, AB ab; ab.m_2 = 2; puts(ab.m_2 ? "true" : "false"); will print "true" before the change and will print "false" after the change. An easy way to ensure you've audited all such code is to add getters and setters for all bitfield member variables or wrap them in a special structure or class as done in http://trac.webkit.org/changeset/103353 and http://trac.webkit.org/changeset/104254. Best regards, Ryosuke Niwa Software Engineer Google Inc.

4 8

Feedback on Blink's text fragment directive proposal
by David Bokan 31 Aug '20

31 Aug '20

Hello webkit-dev, I'd like to solicit feedback as well as an official position from Webkit on our proposal for the text fragment directive: https://github.com/WICG/ScrollToTextFragment. In summary: this is a feature that allows authors and users to craft URLs to pages and specify a snippet of text on the page as a subresource (visually highlighting it and scrolling it into view). Analogous to element-id based fragment anchors but for text. You can try this out today in Chrome Beta by enabling chrome://flags/#enable-text-fragment-anchor. Here's an example link: https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20opti… Relevant Links: <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md> Explainer <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md> Spec <https://wicg.github.io/ScrollToTextFragment/> TAG Review <https://github.com/w3ctag/design-reviews/issues/392> (Currently Suspended) Blink Intent Thread <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/…> Issue on Mozilla standards-positions <https://github.com/mozilla/standards-positions/issues/194> We've been using the GitHub repo for issue tracking but happy to take feedback (official or otherwise) in any form. Thank you! David

4 4

Suggesting to enable paint timing by default
by Noam Rosenthal 20 Aug '20

20 Aug '20

Following the discussion with Simon in https://bugs.webkit.org/show_bug.cgi?id=78011 Since we have a pretty stable spec (https://w3c.github.io/paint-timing/) lots of passing web platform tests, other browser vendor support and a working implementation of first contentful paint, I am planning to submit a patch to enable paint timing by default. https://bugs.webkit.org/show_bug.cgi?id=211736 Any objections? Other thoughts?

4 13