You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at WPT tests and Chrome results, the expected behaviour is to consider that the url is special and hostname is not considered opaque.
The same pattern is done in other places of the spec (canonicalisation algorithms of port, pathname, search and hash for instance), though it is not clear to me whether this has side effects.
What is the issue with the URL Pattern Standard?
URLPattern is using URL records, and passing some URL records to URL algorithms. This might lead to ambiguous behaviour.
For instance https://urlpattern.spec.whatwg.org/#canonicalize-a-hostname is passing the URL record to parse hostname (via https://url.spec.whatwg.org/#hostname-state).
It is unclear whether an URL record is a special URL or not, so it is unclear whether parsing of the hostname (https://url.spec.whatwg.org/#concept-host-parser) will lead to https://url.spec.whatwg.org/#concept-opaque-host-parser.
Looking at WPT tests and Chrome results, the expected behaviour is to consider that the url is special and hostname is not considered opaque.
The same pattern is done in other places of the spec (canonicalisation algorithms of port, pathname, search and hash for instance), though it is not clear to me whether this has side effects.
Discussing with @annevk, it is unexpected to pass URL records directly like done in https://urlpattern.spec.whatwg.org/#canonicalize-a-hostname. A future url spec refactoring might make that clear.
Ideally, the url given to the basic URL Parser should be an URL built by a URL parser.
Maybe that is what the spec should do.
The text was updated successfully, but these errors were encountered: