W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] The <pic> element

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 04 Jun 2012 10:25:39 +0200
Message-ID: <4FCC7103.7070501@gmx.de>
To: Kornel Lesiński <kornel@geekhood.net>
Cc: whatwg <whatwg@whatwg.org>, Anselm Hannemann Web Development <info@anselm-hannemann.com>
On 2012-06-04 09:32, Kornel Lesiński wrote:
> On Mon, 04 Jun 2012 01:05:23 -0500, Anselm Hannemann Web Development
> <info@anselm-hannemann.com> wrote:
>
>>> An alternative is to pick different delimiters. See, for instance,
>>> <http://tools.ietf.org/html/rfc2295#section-8.3>.
>>
>> I also would like to see another delimiting syntax which is clearer.
>> What about JSON-syntax or just " | "?
>> I mean a backslash is not that common in a URL but commas are more and
>> more and you all know that escaping is no fun.
>> So we should really try to avoid this.
>
> Another character could work in theory, but I wonder whether it would
> work in practice.
>
> For example <meta name=viewport> was documented to support only comma,
> but thanks to silent error recovery authors ended up using and relying
> on semicolon:
> http://lists.w3.org/Archives/Public/www-style/2011Oct/0652.html
>
> I wonder whether reverse of it could happen with list of sources, e.g.
> unexpected comma parsed as invalid media query could end up delimiting
> sources in some implementations, and then we'll end up with worst of
> both worlds (both ambiguous comma and other unintuitive delimiter needed
> for web-compat).

1) Use a format where the delimiter is always the same, (2) where 
escaping never is needed, and (3) specify the parser to ignore all 
malformed attribute values.

Best regards, Julian
Received on Monday, 4 June 2012 08:26:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:42 UTC