Re: parsing issue in the editor's draft of css3-image

On Tue, Jul 21, 2009 at 4:21 PM, Yves Lafon<ylafon@w3.org> wrote:
> On Tue, 21 Jul 2009, fantasai 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. The same
>> rule is proposed for image(): if you have weird characters, or
>> if you just want to be safe, use quotes.
>
> Yes, but if you want to reuse a uri in image(), why adding the unquoted
> version that needs escaping that nobody will use anyway and not use the
> url() construct ? It is just confusing, and not only for parsers :)

I also don't see much use in allowing a non-quoted, non-url()'d value
in there like that.  If people use it at all they will *not* escape it
correctly.  Believe me, just saying "Must be in quote marks or url()"
is not putting any sort of undue burden on us authors.  Extraneous
choices that we don't want to use in the first place, on the other
hand, *does* make things harder for us.

~TJ

Received on Tuesday, 21 July 2009 21:26:44 UTC