Closed letitz closed 1 year ago
I don't think we should do this.
Hi @annevk!
As stated in #91, I consider the current state of affairs (spec name = local, header = private) to be an unfortunate accident. I think it would be marginally better to align terms between spec and implementation, in order to minimize developer confusion.
In this light, is this something you could live with, and we could standardize in Fetch?
I think I've also stated what I prefer in #91. 😊
Right! So far, however, only preferences have been expressed by all parties. I'm looking to answer a more specific question here: do you think keeping with the old name would block standardization?
Unless you believe we could not standardize PNA under that name and with that terminology in HTML/Fetch, I think it best to minimize confusion by reverting back to the name that was used for a couple years and align with header names.
I don't know.
To elaborate, Fetch at least tends to use the correct terminology, even if that's not the terminology we end up exposing through APIs. You can see this with various timing APIs, for instance. The same is true elsewhere in the web platform, e.g., with URLs. It would be weird to break tradition with that.
Understood. Given the lack of formal standards positions from other browsers, we'll go ahead and rename this spec back to be consistent with its API. In the meantime, would you mind responding on the WebKit standards position (https://github.com/WebKit/standards-positions/issues/163) with how WebKit feels about the possibility of upstreaming this specification to Fetch? I believe we would need such a statement when upstreaming into Fetch anyway. At that point, we can revisit terminology while merging.
@johnathan79717 I believe this is ready for review. Can you PTAL?
Thanks!
cc @johnathan79717 @iVanlIsh