Re: [w3c/ServiceWorker] Until resultingClientId is implemented, what should FetchEvent.clientId be for navigation requests? (#1266)

> I don't see any discussion of null-vs-empty-string though. Maybe @jungkees knows.

In https://github.com/w3c/ServiceWorker/commit/8b483b091e0f0bae6b698cf05d915c2029748ae0, we effectively changed semantics of `clientId` from either-fetch-client-or-null-for-navigation to always-fetch-client (introducing `resultingClientId`.) We changed `clientId` to non-nullable DOMString as such. After that change, the expectation is `clientId` is always set to a string value initialized in HTML. Also, I think we had come across some discussion somewhere that using the empty string over null helps ergonomics.

For compatibility before implementing `resultingClientId`, will it help to change V1 spec back to set `clientId` to null for navigation requests and change its type to nullable adding a note to explain the future plan? (I've tested EdgeHTML also returns null. Haven't tested WebKit yet.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1266#issuecomment-361827619