- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Wed, 16 May 2012 15:58:51 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@whatwg.org>
Le 15/05/12 09:28, Ian Hickson a écrit :
> <img src="face-600-200@1.jpeg" alt=""
> src-template="face-%w-%h@%r.jpeg"
> src-versions="600x200x1 600x200x2 200x200x1">
>
> [snip]
>
> <img src="face-600-200@1.jpeg" alt=""
> srcset="face-600-200@1.jpeg 600w 200h 1x,
> face-600-200@2.jpeg 600w 200h 2x,
> face-icon.png 200w 200h">
Three comments:
1. from the point of view of an editor (I mean a wysiwyg application),
this is far too complex and painful. With my BlueGriffon hat on,
please trust me on that. Where is the harmony, the consistency with
the multi-source video and audio elements? Why should browsers and
editing tools have to deal with a different mechanism?
2. the %w and %h syntax above will clash with the necessary escaping of
non-URL compliant characters and I think this is a _very_ bad idea.
All examples I saw include filenames only but these are really URIs !
3. for the same reason, because some filesystems allow whitespaces and
commas and more in filenames, the latter seems to me dangerous and
certainly a bad idea. I know whitespaces in URIs will be encoded but
decoding srcset will then imply parsing it to extract URIs before
unescaping or whitespaces will become a problem. That's really too
expensive.
It's much more subjective but I have an extra comment: the proposed
srcset attribute is absolutely ugly. I think the srcset approach is
wrong.
</Daniel>
--
W3C CSS Working Group, Co-chair
Received on Wednesday, 16 May 2012 13:59:31 UTC