That's not compatible with implementations.

(In reply to comment #1)
> That's not compatible with implementations.

What I point is not encoding but decoding, so this should increase compatibility.

Compatibility with which encoding implementations? Or do decoding implementations typically implement this? (Though if you cannot get it generated that seems pointless.)

(In reply to comment #3)
> Compatibility with which encoding implementations? Or do decoding
> implementations typically implement this? (Though if you cannot get it
> generated that seems pointless.)

For example CGI.pm of perl emits semicolon-separated query string:
> perl -e'use CGI;$q=CGI->new;$q->param(foo => "bar");$q->param(hoge => "fuga");print $q->query_string()'
foo=bar;hoge=fuga

Ruby's cgi.rb emits &-separated string, but can parse ;-separated one.

I guess we might want to consider it a bit more then.

In any event, I want to use  this algorithm for the URLQuery API and there I definitely do not want ; to count as separator. "?na;me=value&name;2=othervalue" should just be split on & and then =.

Is there a web browser which doesn't escape ; in name on form submitting?

I'm not sure, but you can get such URLs by manipulating via JavaScript or simply with <a>.

What creates such URLs?

When it is via JavaScript, there's no direct generator function from a form like form.queryString().
If it uses escape(), it escapes ; and &.
If it uses encodeURI(), it doesn't escape neither ; and &, but it is wrong use.
If it uses encodeURIComponent(), it escapes ; and &.
So there's no problem.

When it is simple a href, it seems by some libraries or by hand.

If it uses libries,
Perl's CGI.pm decodes with ; and & as separators, and encodes with ; by default.
Python's cgi.py decodes with ; and & as separators, and urllib.py encodes with &.
Ruby's cgi.rb decodes with ; and & as separators, and uri.rb encodes with &.
PHP decodes with & as a separator (can change by arg_separator.input), and http_build_query encodes with &.
All of them encodes both & and ; of key.
So there's no problem.

If it is written by hand, there's many possibility.
It may use odd separator like !, ,, |, $, and so on.
Of course it includes a query string like "?na;me=value&name;2=othervalue".

Therefore I think splitting with [&;] is reasonable de facto standard.
Current decoding algorithm breaks CGI.pm, the majority, defending rare edge cases.

This is a URL spec bug now right?

(assuming it's a bug at all, I mean; I personally think it should be WONTFIXed as I see no value in using semicolons as well, and supporting multiple syntaxes is a recipe for security bugs, typically)

It's URL once HTML starts making that dependency. Agreed about WONTFIX. Seems better if everyone aims to converge to a single format.

I'm ok about WONTFIX if you decide it with understanding above facts I showed.

Ok, Anne, your call. (Assume HTML defers to URL for this stuff.)

Current libraries on the server also have other quirks as illustrated in bug 24222.

They are free to implement other things I think. The specification just defines parsing for the format produced by the web platform.