- From: Zack Weinberg <zweinberg@mozilla.com>
- Date: Tue, 21 Jul 2009 14:31:33 -0700
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: Yves Lafon <ylafon@w3.org>, Bert Bos <bert@w3.org>, www-style@w3.org
fantasai <fantasai.lists@inkedblade.net> wrote: > Yves Lafon wrote: > > On Mon, 20 Jul 2009, Bert Bos wrote: > > > >> It doesn't create a special case, but the obligation for an author > >> to escape commas and characters that cannot occur in a value, such > >> as unbalanced parentheses and semicolons: > >> > >> http://example.org/foo?s10,34;x={} > >> > >> would have to be written as: > >> > >> http://example.org/image?s10\,34\;x=\{\} > >> > >> (This creates some 13 tokens, if I counted correctly.) > >> > >> I'm all for omitting parentheses and quotes when possible, but for > >> URLs I don't think it is possible. > > > > Frankly I can't think of an author escaping URIs that way, see how > > & are not escaped in HTML hrefs... using url() which is an existing > > construct not only gives what is expected but also gives the same > > user experience for authors, ie: "Oh for this property should I use > > url() or not" is a good recipe for errors. > > We already have this problem with url(). Commas, brackets, etc. > must be escaped inside url() unless the URI is quoted. ??? url() gets special treatment from the tokenizer, it appears to me that the only characters you have to escape inside an unquoted url() are " ' ( ) all of which are very rare (if I read RFC3986 right, '() are reserved subdelimiters and " cannot be used at all). (Tangential nitpick: there's an ambiguity in the section 4.1.1 regex, [!#$%&*-~] includes \ but {escape} is also an alternative at that level.) It's this special treatment that I do not want to see extended to image(); and I don't like Bert's suggestion of allowing an arbitrary sequence of tokens as the first argument to image(), either. I would have the image() syntax be 'image(' [ URI | STRING ] , ... ) or maybe even just 'image(' STRING , ... ) zw
Received on Tuesday, 21 July 2009 21:32:17 UTC