Note that if you want an escaped form of a URL, the usual approach is to fill out a url.URL struct and then call its String method. Then each piece is properly escaped, which is not something a single function can do.

There is also PathEscape and QueryEscape. I am confused why you brought up escapeZone.
For a data: URL, I would expect PathEscape to be appropriate.

@rsc It depends what you meen by 'appropriate'. PathEscape works but is not optimal because it apply percent encoding to some character that do not need to be escaped.

I don't think that you can put the data URI in url.URL and hope to be parsed correctly because it is not an URL. The data URI can be composed for example of a single svg file, that is not an URL. And if you want to put a text that looks like an url in a data URI it will be badly escaped, for example the query part will use + for spaces that is not allowed in data URI.

As I said in my question, the data URI allows more characters to be non escaped.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

What is the specific escaping to be applied? For the body of a data: URL I would expect # to be invalid (and need escaping) since even scheme:opaque URL forms can have #fragment following them, at least according to the url.URL docs. Similarly ? since they can have queries too. So that sounds like PathEscape. The text above says "some symbols" are unnecessarily escaped by PathEscape (at least for use in a data URL). Which symbols specifically?

@rsc The javascript encodeURI preserves the following symbols that are encoded by PathEscape:

!#'()*,/;?

But using encodeURI to encode the <data> part of the dataURI is probably not the right thing to do. The problem is that browsers accept "less encoded" data than the standard requires.

I don't know anymore if having the equivalent of encodeURI is a good idea, sorry.

This is probably too specific for the standard library. svg is probably the only case where very few bytes have to be escaped. If we were escaping a png, for example, base64 is probably better than %-encoding all the binary in the png. So any function here would have to let you pick the encoding or just be very niche.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group