Am 21.05.2012 07:49 schrieb Mike Gossmann:
When all the picture vs srcset started showing up on twitter, I was initially
behind picture. I'm sure you all know the arguments for it, and I liked those
arguments. Today though, I was reading an article about the two, and there was
a misunderstanding about how srcset was working in the comments, and it made me
realize that something closer to srcset would be ideal.
The big thing I realized is that as a developer, I do not want to write more
media queries - or anything that works at all like them - into image elements.
It's redundant. There's a good chance there's already a bunch of CSS in place
controlling the shape and size of the image element itself, why should I have
to write a bunch more, somewhere else, to control the src of the image too?
Why can't it work so that in the html I say here's an image, there's a version
of it at 150x150, and a version at 48x48, and then in the CSS I say that the
image is 25% of the width of the article it's in, which works out to 100px
wide, and then the browser can just decide that the 150x150 would be best, and
scale it down. If I change the CSS, I don't have to change the html too, the
images I provided are still only available at those sizes. With image/picture
sources set by viewport dimensions, even something as simple as adding more
padding around articles on a site could involve going through all the HTML and
adjusting the breakpoints in the tags. This way layout, units, and screen dpi,
don't matter when writing the HTML,
I've seen people get confused and think srcset work this way, instead of by
viewport size (unless I'm the confused one), and if they were right then srcset
would work well for this. It would be even nicer if there was something even
more CMS friendly, like:
<img src="/img/people.jpg" sizes="100x200 300x250 900x300"
pattern="/tools/resizer.php?img=people.jpg&width={w}&height={h}" alt="A picture of some
people.">
So src would be the fallback, then sizes would say which dimensions are available, in a fairly
common format, using spaces to separate options like class does. pattern (probably a bad name)
would be a template for the URL the browser can request the image from, replacing {w} and {h} with
the requested dimensions. There wouldn't need to be a token for the dpi/resoultion/whatever, the
browser could just request an image twice or three times or whatever the size. There's no point in
having sizes="100x100@1 100x100@2 200x200@1" when you can just have sizes="100x100
200x200"
This gives the designer/developer full control over the shape and size of the
image element (through CSS), while still allowing the browser to make decisions
based on bandwidth and whatnot.
I was actually writing a similar proposal and like the approach very
much. I have 3 inputs on the pattern syntax:
1. @pattern needs some more variables so authors can use it without a
server side handler, using distinct file names or directories or
whatever, such as:
- directory path
- file name
- file name without suffix
- suffix
So patterns for use with src="/img/people.jpg" could also be e.g.
(variable names are subject to optimisation...):
- /img/{filenameWithoutSuffix}_{w}x{h}.{suffix}
- /{dirname}/{w}x{h}/{filename}
2. It would be nice if @pattern defaulted to something that authors do
all the time anyway. From my practice I suggest:
- /{dirname}/{filenameWithoutSuffix}_{w}x{h}.{suffix}
It is very easy to tell authors or even CMS page admins to use image
file names such as people.jpg and people_200x300.jpg.
3. Variable syntax: Curly brackets are also used for variables by some
server side template engines, such as PEAR HTML_Template_IT and
HTML_Template_Sigma. These would replace or remove the @pattern
variables. Thus, some other kind of variable delimiter might be more
compatible.
