If I understand correctly, a scheme-relative URI will end up being handled as one would expect through step 1 of parse a url-like import specifier.
The behavior looks sound, but I think it might merit an explicit call out comment. Starting with "/" is inclusive of starting with "//", but the list of prefixes — "/", "./", "../" — is easy to mistake as telling the story that this step is just about path-absolute/relative cases. As a result I was a bit surprised when it clicked that step 1 was able to produce a URL with a different origin from baseURL’s origin.
(The spec can’t anticipate everything that might not be obvious to every reader and my surprise may not be representative, so if others feel there’s no need to include a note mentioning that the scheme-relative case is handled here, I understand.)
If I understand correctly, a scheme-relative URI will end up being handled as one would expect through step 1 of parse a url-like import specifier.
The behavior looks sound, but I think it might merit an explicit call out comment. Starting with "/" is inclusive of starting with "//", but the list of prefixes — "/", "./", "../" — is easy to mistake as telling the story that this step is just about path-absolute/relative cases. As a result I was a bit surprised when it clicked that step 1 was able to produce a URL with a different origin from baseURL’s origin.
(The spec can’t anticipate everything that might not be obvious to every reader and my surprise may not be representative, so if others feel there’s no need to include a note mentioning that the scheme-relative case is handled here, I understand.)