It seems to depend on "is special" in Chrome and Firefox, which isn't ideal.

I mean, Chrome and Firefox don't even escape spaces (or anything not in the C0 controls set) in non-special paths…

3986 defines path segments to contain these characters:

pchar       = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

That doesn't include ^, so it needs to be percent-encoded.

@achristensen07 Are you okay with aligning Safari on this?

I think so. This is a case where Chrome and Firefox have the same behavior, so aligning with them would likely increase compatibility. It looks like the most compatible solution depends on "is special"
Like I said in issue 608, we really need complete tests with each ASCII code point in each part of a URL with and without a special scheme.

FYI. The discussion around issue #379 has a good overview of the percent encode sets.

FWIW, I've been looking at interoperability between this standard and the URL type in Apple's Foundation framework (which I assume would also be of interest to WebKit). It is documented as conforming to RFC-1738.

The biggest difficulty in getting Foundation to parse the serialised output of this standard is the difference in percent-encode sets. This makes it harder for applications to transition to a web-compatible URL model, as converting to a Foundation URL means adding percent-encoding, so the serialised URL string changes. Anything which minimises that would be appreciated, and if it is actually a better description of how browsers behave, it seems like a no-brainer.

That said, if Safari currently does not encode it, and Chrome/Firefox conditionalise it, and neither of them "broke the web", it seems reasonable to conclude that few if any sites actually care whether it is encoded or not. In that case, the better choice IMO would be to unconditionally encode it and align with RFC-3986 as a bonus. Conditional percent-encode sets are awful.

test://test/^: https://jsdom.github.io/whatwg-url/#url=dGVzdDovL3Rlc3QvXg==&base=YWJvdXQ6Ymxhbms=
test:^: https://jsdom.github.io/whatwg-url/#url=dGVzdDpe&base=YWJvdXQ6Ymxhbms=
https://test/^: https://jsdom.github.io/whatwg-url/#url=aHR0cHM6Ly90ZXN0L14=&base=YWJvdXQ6Ymxhbms=

It seems Gecko branches on "is special", but Chromium doesn't. Chromium branches on "opaque path", which seems more reasonable?

I would be willing to align WebKit and the standard with Chromium here (assuming that @achristensen07 is still on board). @hayatoito @valenting what do you think?

I am strongly in favor of doing this. Aligning the standard with Chromium seems like a good path forward.

Sounds good to me.

I checked the Chromium's implementation. As you noticed, the current implementation doesn't branch whether "is special" or "is not special" on percent encoding of path. I don't have any intention here; I didn't know this is not Standard compliant until now.