- From: Matt Giuca <notifications@github.com>
- Date: Wed, 18 Sep 2019 21:40:04 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/417/532962338@github.com>
> @mgiuca has told me he might do the spec work to try to factor out the scope behavior into a common place that both service workers and manifests can reference. That has not happened yet. I think it would be pretty easy; we'd just need a home for it. (Doesn't make sense to live in Service Workers or Manifest, IMO.) Where could it go? HTML? URL? Probably the same place where URLPattern would end up... where do you think that should live? I hadn't realised until recently that there was a mismatch (I didn't realise that SW scope matched query strings). The unified algorithm would need to be parameterized by whether it matches query strings or not. The discussion on deprecating the matching of query strings is on w3c/ServiceWorker#1469. > I believe the rest of the explainer is supportable in manifest and our intent would be to keep them aligned. We also need to make sure that every use case can be done by passing a JSON-like object to the URLPattern constructor (no other JS code or use of dynamic values). This came up in [this discussion](https://github.com/wanderview/service-worker-scope-pattern-matching/issues/1#issuecomment-531625389) where it was suggested that certain use cases could be taken care of by use of the URL constructor, but you can't do those things from a declarative context like Manifest. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/417#issuecomment-532962338
Received on Thursday, 19 September 2019 04:40:26 UTC