Re: [webkit-dev] Request for Position on URLPattern

[Ben Kelly via webkit-dev]

FYI, there is now an intent-to-ship [0] for this feature in chromium.

[0]:
https://groups.google.com/a/chromium.org/g/blink-dev/c/-T5pJtBO8h4/m/cAkpQec1AwAJ

On Fri, Aug 13, 2021 at 4:19 PM Ben Kelly  wrote:

> Hello,
>
> I would like to request an official WebKit position on URLPattern [0].
> This is a web API for matching against URLs which is often done in
> javascript routing systems.  We also intend to use this same matching
> primitive in future changes to service worker scopes.  This larger set of
> use cases is described in the explainer. [1]  This particular request,
> however, is just for the URLPattern API and does not yet touch service
> workers.
>
> URLPattern was discussed in a couple of past TPAC meetings:
>
> * TPAC 2019 [2]
> * TPAC 2020 Video Call [3]
>
> In case it's helpful, we also have a summary of web developer feedback
> we've received so far. [4]
>
> Thank you.
>
> Ben
>
> [0]: https://wicg.github.io/urlpattern
> [1]: https://github.com/WICG/urlpattern/blob/main/explainer.md
> [2]:
> https://docs.google.com/document/d/1q090ovJ4gd8wSfVtvuoZLMZ51YkiFDsEZ0Jiqi41Iys/edit#heading=h.d6e4ecicreet
> [3]: https://github.com/w3c/ServiceWorker/issues/1535
> [4]: https://github.com/WICG/urlpattern/blob/main/dev-trials-feedack.md
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Network Information API reboot: request for early feedback

[Thomas Steiner via webkit-dev]

>
> I'm going to stop replying to this thread going forward since I have other
> things to do but please note that my lack of future response does not, in
> any way, constitute a lack of signal or acceptance of an argument, idea, or
> amendment to the proposal.
>

> Apple's WebKit team is against this proposal like we were with the old
> API, and that's not going to change unless a substantial amendment is made
> to address all of the concerns we've raised thus far (as well as any new
> concerns we may raise in the future) for this proposal and the old API.
>

Thanks for the discussion and for taking a clear stance. I know you were
going to stop replying, but so far you have only argued about the `metered`
part of the proposal. Any word on the proposed `sustainedSpeed` attribute?
One way a vendor could implement this API would be to always report `false`
for `metered` (despite the actual value potentially being another) and
still report connection speed data via `sustainedSpeed`.

Cheers,
Tom
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev