March 2022 - webkit-dev - lists.webkit.org

Basuke Suzuki is now a WebKit reviewer!
by Kirsling, Ross 07 Mar '22

07 Mar '22

Hi everybody, I’m happy to announce that Basuke Suzuki is WebKit’s newest reviewer! Basuke has done significant work on the PlayStation and WinCairo ports, Curl, the socket-based remote web inspector, and bmalloc, so keep him in mind next time you need a review. Please join me in congratulating Basuke! Ross

3 2

WebKit Style: Whitespace for Objective-C protocols
by Myles Maxfield 03 Mar '22

03 Mar '22

Hello! I was working on a patch recently where I wanted to give an Objective-C variable a type of “id that conforms to protocol Foo.” Should this be spelled like this: id <Foo> myVariable Or like this: id<Foo> myVariable I don’t see anything about this in the WebKit style guide <https://webkit.org/code-style-guidelines/>. The former appears in WebCore, WebKit, and WebKitLegacy 1035 times, whereas the latter appears only 281 times. On the other hand, Apple’s documentation <https://developer.apple.com/documentation/metal/1433401-mtlcreatesystemdefa…> seems to prefer the latter. Another consideration - This question is only about Objective-C protocols, not Objective-C generics. We already have a longstanding practice of spelling generics without the space, e.g. NSArray<NSString *> *. So, we could either intentionally choose for protocols to look visually similar to generics, or alternatively we could intentionally choose for protocols to look visually distinct to generics. Consider seeing something like Foo<Bar <Baz> *> *. Would the inconsistent spacing annoying you? Or would the spacing help you understand that Baz is a protocol but Bar is supplied as a generic type? Maybe the * characters already make that clear? What should the style guide say here? Thanks, Myles

3 3

Request for Position: hidden=until-found HTML attribute and beforematch event
by Joey Arhar 02 Mar '22

02 Mar '22

Hello WebKit devs, I am implementing the hidden=until-found HTML attribute and beforematch event in Chromium, and I would like to hear WebKit's position on the feature. Chromestatus entry: https://chromestatus.com/feature/5400510406328320 Spec: https://github.com/whatwg/html/pull/7475 Explainer: https://github.com/WICG/display-locking/blob/main/explainers/hidden-content… Today, users can't search for content inside collapsed or hidden content in websites with find-in-page or scroll to text fragment. If the user wants to search all of the text in a page, it may require manually opening every expanded section before searching. This feature addresses this problem by allowing a variation of the hidden HTML attribute to be set on an element, indicating that it should not be rendered but should allow find-in-page to still search its contents and automatically reveal it. This is a more generic version of the auto-expanding details feature: https://lists.webkit.org/pipermail/webkit-dev/2021-September/031983.html

1 0