Rename non-relative-flag

[annevk]

• not-a-base-url flag
• cannot-be-a-base-url flag

Better suggestions welcome.

When we change this at least HTML needs to be updated too.

[SimonSapin]

Maybe call it hierarchical flag and invert the logic? It’s annoying to type and pronounce, but RFC 3986 seems to be using that term for roughly this concept.

[domenic]

I liked my "cannot-be-a-base-url flag" idea since it clears up my confusion over exactly what the flag is for. In whatwg/html#660 @annevk explained that "The flag indicates whether a relative URL can be parsed against it." Whereas it's not clear to me that "hierarchical" URLs can be used as a base URL.

[SimonSapin]

I’d like a term for URLs with that flag set, for using in rust-url documentation. It’s currently "non-relative URL", e.g. "Non-relative URLs (typical of data: and mailto:) and some file: URLs don’t have a host." for the fn host(&self) -> Option<&str> method.

"URLs that can’t be a base" doesn’t feel like a category of its own but (I think) leaves the reader wondering which URLs can be used as a base or not.

(This is half arguing about this issue and half asking for doc-writing advice :))

[annevk]

I think hierarchical is bad since it will just lead to confusion with RFC 3986 which has slightly different ideas on this that don't match browsers.

URLs that cannot be used as a base URL does seem like a category. I think it's basically all URL strings that do not have a / after the scheme followed by a ":", minus special URLs. Admittedly a little tricky, but that's how it is.

[SimonSapin]

I’m ok with something like "can be a base". (Rather than "cannot", to avoid double negations.)

I’d like this to be decided one way or another before I land servo/rust-url#176, since it includes public API named after this flag.

[annevk]

"can be a base" however would have to be set by default, which is highly unusual for flags. So I don't think that's an option.

[SimonSapin]

I don’t understand why flipping the default is a problem. The defaults are just the starting point of the parsing algorithm, then don’t form a "well-formed" URL record in themselves. For example the empty string is not a scheme per https://url.spec.whatwg.org/#syntax-url-scheme

And even with "can be a base" the default can still be unset and the flag be set in another set of cases in the parsing algorithm.

But I can live with double negations if you feel strongly that the alternative is worse.

[annevk]

I think it would be quite weird to unset something and only have checks for it being unset. "cannot-be-a-base-URL flag" is still my favorite.

[SimonSapin]

Ok. Does it help if I send a PR for that?

[annevk]

Yes, please, I'll get to it tomorrow. Been rather busy with HTML and DOM.

[SimonSapin]

FWIW I’ve started to rewrite rust-url docs to use phrases like "cannot-be-a-base URLs" and "If this URL is cannot-be-a-base", with hyphens as-is.