passing base URL as a dictionary property vs a separate string argument

[wanderview]

passing base URL as a dictionary property vs a separate string argument

[jeremyroman]

FWIW I don't have a strong preference but I think allowing it to existing in both places is potentially confusing. What does new URLPattern({ pathname: '/foo/bar', baseURL: 'https://example.com/'}, 'https://example.net/') do?

[wanderview]

I don't support that for constructor currently. But I did just add support for it to test() and exec(). The webidl looks like:

boolean test(URLPatternInit input);
boolean test(USVString input, optional USVString baseURL);

Which means passing a second argument will coerce the first argument to a string. If the first arg is an init dictionary it pretty much won't be a valid URL. So this will always return false:

pattern.test({ pathname: '/foo/bar' }, 'https://example.com');

I could change this outcome to an exception with a human readable error message if I switched the webidl to:

typedef (USVString or URLPatternInit) URLPatternInput;
boolean test(URLPatternInput input, optional USVString baseURL);

But I chose not to do that since it seemed better to make the webidl reflect the intent of correct usage. I don't feel too strongly here if other think we should go a different way.

[wanderview]

Talked with @domenic this morning and he suggested we go with the union type to provide a more meaningful exception. It provides a better experience for developers at the cost of a slightly harder to read spec. We can add a note to the spec, though.

I think we should not support second baseURL argument for structured input for now. We will throw an exception if the user tries. If we get lots of requests for the feature, though, we can re-assess.

[wanderview]

This is now codified in the spec.