September 2021 - webkit-dev - lists.webkit.org

Request for Position: CSS Text Decoration Module for SVG <text>
by TAMURA, Kent 30 Sep '21

30 Sep '21

I'd like to request an official WebKit position on expanding support of "CSS Text Decoration Module" [1] for SVG <text>. Currently WebKit and Blink support only a few features for SVG <text>, and we'd like to add support of features which are currently supported for HTML. Firefox already supports various properties for SVG <text>, including text-emphasis-style. [1] https://drafts.csswg.org/css-text-decor-4/ -- TAMURA Kent Software Engineer, Google

2 1

Request for Position: Add 'xml' special handling to Node.lookupNamespaceURI()
by TAMURA, Kent 30 Sep '21

30 Sep '21

I'd like to request an official WebKit position on updating Node.lookupNamespaceURI() [1] so that it returns the XML namespace URI for "xml" prefix by default. It would simplify the implementation of XPathEvaluator.createNSResolver() significantly, and Firefox already supports this behavior. [2] This is a RFP to change the DOM specification. [1] https://dom.spec.whatwg.org/#dom-node-lookupnamespaceuri [2] https://github.com/whatwg/dom/issues/857 -- TAMURA Kent Software Engineer, Google

1 0

Request for Position on DNS-based HTTP->HTTPS redirect
by Eric Orth 28 Sep '21

28 Sep '21

Specifically the HSTS-like behavior outlined by Section 8.5 of https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07 We understand that Webkit (or perhaps DNS infrastructure more generally in Apple OS's) implements general support for HTTPS records and has been querying them since 2020, but we are unfamiliar with and request a position on Webkit's support for the specific HTTP->HTTPS redirect behavior.

1 0

Kimmo Kinnunen is a WebKit Reviewer
by Dean Jackson 27 Sep '21

27 Sep '21

I'm happy to announce that Kimmo Kinnunen is now a WebKit Reviewer. Congratulations Kimmo! Dean

2 1

Request for position: block navigation toward external protocol from sandboxed iframe.
by Arthur Sonzogni 27 Sep '21

27 Sep '21

Hi webkit-dev, This is a request for Webkit's position about blocking navigation toward external protocols from sandboxed iframe. *Summary:* Gates sandboxed iframe navigation toward external protocol behind any of: - allow-popups - allow-top-navigation - allow-top-navigation-with-user-gesture (+ user gesture) *Motivation:* Developers are surprised that a sandboxed iframe can navigate and/or redirect the user toward an external application. General iframe navigation in sandboxed iframe are not blocked normally, because they stay within the iframe. However they can be seen as a popup or a top-level navigation when it leads to opening an external application. In this case, it makes sense to extend the scope of sandbox flags, to block malvertising. *Issue:*https://github.com/whatwg/html/issues/2191 *Specification:*https://github.com/whatwg/html/pull/7124 *Mozilla position*https://github.com/mozilla/standards-positions/issues/581 I would love to hear your feedback. Arthur @arthursonzogni

1 0

Request for position on app history API
by Domenic Denicola 24 Sep '21

24 Sep '21

Hi webkit-dev, The Chrome team, with some help from Mozilla folks, have been working on a proposal for a new history/navigation API aimed specifically at the needs of single-page apps. The current name is the "app history API". You can see the explainer at [1] (and the name bikeshedding thread at [2] 😊). So far the API has a lot of web developer enthusiasm and engagement on the issue tracker, including a polyfill [3]. We've been prototyping behind a flag in Chromium and are planning to go to origin trial soon, as we have some large sites that want to try conditionally switching out their current router code for code based on app history to see if this brings about the desired simplifications or shakes out any bugs. We also have a lot of web platform tests [4] and a mostly-complete but definitely still WIP spec [5]. We'd love to get your thoughts, whether they're a general appraisal or a more in-depth dive into the API choices and spec. I'm hopeful we can together make developers really happy with a new API for this historically-tricky problem space. Other links you may enjoy are the Mozilla standards positions issue [6] and the initial W3C TAG design review [7]. Thanks so much for your time, -Domenic [1]: https://github.com/WICG/app-history [2]: https://github.com/WICG/app-history/issues/83 [3]: https://github.com/frehner/appHistory [4]: https://github.com/web-platform-tests/wpt/tree/master/app-history [5]: https://wicg.github.io/app-history/ [6]: https://github.com/mozilla/standards-positions/issues/543 [7]: https://github.com/w3ctag/design-reviews/issues/605

1 0

Removal of makeRef() / makeRefPtr()
by Chris Dumez 22 Sep '21

22 Sep '21

Hi, With WebKit adopting C++17 a while back, there are no longer any benefits to using makeRef() / makeRefPtr() as far as I can tell. Code that was written like so: auto protectedThis = makeRef(*this); auto protectedPage = makeRefPtr(page); auto result = makeRef(foo->bar()); auto lambda = [protectedThis = makeRef(*this)] { }; m_node = makeRef(node); // m_node being a Ref<Node> m_node = makeRefPtr(node); // m_node being a RefPtr<Node> Can now be written in a more concise way: Ref protectedThis { *this }; RefPtr protectedPage { page }; Ref result = foo->bar(); auto lambda = [protectedThis = Ref { *this }] { }; m_node = node; `m_node = node;` or `m_node = &node; // depending if node is a reference or pointer. I am currently in the process on transitioning our code from one style to the other and removing makeRef() / makeRefPtr() altogether. I am sending this email so people are not confused when they try to use makeRef() / makeRefPtr() in new code. --  Chris Dumez

1 0

Request for Position on Gamepad input events
by Matt Reynolds 21 Sep '21

21 Sep '21

Hello webkit-dev, I would like to request Webkit's official position on adding events for button and axis inputs to the Gamepad API. This feature would add events that fire when gamepad button or axis inputs change, enabling applications to respond to input changes as they occur instead of relying on the current polling-only interface. The goal is to enable applications to respond to gamepad inputs with minimum latency. Chrome Platform Status: https://chromestatus.com/feature/5989275208253440 Explainer: https://docs.google.com/document/d/1GUeLs5RXdTlaiLgyBf6FUdJXu71dzCpsiLkawkC… Design doc: https://docs.google.com/document/d/1rnQ1gU0iwPXbO7OvKS6KO9gyfpSdSQvKhK9_Okz… Spec change pull request: https://github.com/w3c/gamepad/pull/152 TAG design review: https://github.com/w3ctag/design-reviews/issues/662 Thanks, Matt Reynolds

1 0

Intent to Remove: XSS Auditor
by Brent Fulgham 20 Sep '21

20 Sep '21

Hi Folks, We have continued to ship the XSS Auditor for a number of years after Blink and other engines have abandoned this approach in favor of modern XSS defenses like CSP. The XSS Auditor was a great idea in its day, but now poses a maintenance burden that far outweighs the small (perhaps nonexistent) benefit it provides. We intend to remove the XSS Auditor in the coming weeks to better align with the behavior of other browsers. Please let me know as soon as possible if you have reasons why this would be a significant issue for your port. Best regards, -Brent

1 0

Request for Position: Auto-expanding details elements
by Joey Arhar 17 Sep '21

17 Sep '21

Hello WebKit devs, I am implementing the auto-expanding details elements feature in Chromium, and I would like to hear WebKit's position on the feature. Chromestatus entry: https://chromestatus.com/feature/5032469667512320 Spec: - https://github.com/whatwg/html/pull/6466 - https://html.spec.whatwg.org/multipage/interaction.html#interaction-with-de… Explainer: https://github.com/WICG/display-locking/blob/main/explainers/auto-expanding… WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=228843 Today, users can’t search for content inside details elements when they are closed. If the user wants to search the page for content inside details elements with find-in-page, then they have to manually expand every details element in the page before they use find-in-page. This feature makes the hidden contents of closed details elements searchable by find-in-page and makes the browser automatically open them when trying to scroll to their hidden contents so that users can always search inside them. In addition to find-in-page, this feature should also work for Element fragments (navigating to a hash with an element id) and ScrollToTextFragment in order to make content hidden inside <details> elements more findable, searchable, and shareable.

1 0