- From: Karl <notifications@github.com>
- Date: Fri, 14 Jul 2023 03:48:48 -0700
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/issues/779/1635679104@github.com>
I agree that this part of the JS URL API is awkward. To give another data point: in my library WebURL, which implements the WHATWG standard in Swift, I made this change ("not present" is communicated as `nil`, not as an empty string) and [some other tweaks](https://karwa.github.io/swift-url/main/documentation/weburl/weburl/jsmodel-swift.property). > WebURL uses nil to signal that a value is not present, rather than an empty string. This is a more accurate description of components which keep their delimiter even when empty. For example, consider the following URLs: > >http://example.com/ >http://example.com/? > >According to the URL Standard, these URLs are different; however, JavaScript’s `search` property returns an empty string for both. In fact, these URLs return identical values for every component in JS, and yet still the overall URLs compare as not equal to each other. This has some subtle secondary effects, such as `url.search = url.search` potentially changing the URL. > >WebURL avoids this by saying that the first URL has a `nil` query (to mean “not present”), and the latter has an empty query. This has the nice property that every unique URL has a unique combination of URL components. I appreciate that the JS API cannot be changed at this point, though. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/url/issues/779#issuecomment-1635679104 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/url/issues/779/1635679104@github.com>
Received on Friday, 14 July 2023 10:48:54 UTC