Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change the syntax of srcset 'w' #161

Closed
zcorpan opened this issue Apr 23, 2014 · 15 comments
Closed

Change the syntax of srcset 'w' #161

zcorpan opened this issue Apr 23, 2014 · 15 comments

Comments

@zcorpan
Copy link

zcorpan commented Apr 23, 2014

The srcset 'w' feature isn't obviously clear what it refers to, if it's the image width in image pixels or the image with in CSS pixels or min/max-width of the viewport (like old srcset) or something else.

It may be clearer to switch to 100x50 syntax instead, which is also used by <link sizes>. It would mean authors have to give the height of the image, but maybe that's not an undue burden (it's probably always known if the image's width is known) and it allows us to set the intrinsic dimensions before the image is loaded (#85). It's also slightly shorter than 100w 50h.

We don't have to support height-based selection with sizes (#86) at the same time as introducing height information in srcset since height-based selection with sizes would make syntax changes to sizes which should be feature-detectable if we do it right. sizes parsing now is forward compatible with both detecting and falling back to later entries in the value, so I think we're good there.

More discussion in http://ircbot.responsiveimages.org/bot/log/respimg/2014-04-22#T66654 onward

@zcorpan
Copy link
Author

zcorpan commented Apr 23, 2014

@yoavweiss
Copy link
Member

What worries me about the AxB syntax is that we're using 'x' there.

Authoring errors such as 100x50.jpg 100x 50, 200x100.jpg 200x 100 will result in an outcome that's very different from what they intended.

I agree that 'w' invokes confusion (especially with the old spec still around). Maybe a A*B syntax? Or an 'rw' descriptor?

@nwtn
Copy link
Member

nwtn commented Apr 23, 2014

What about a coordinate-y notation, e.g. (w, h)?

@zcorpan
Copy link
Author

zcorpan commented Apr 23, 2014

Yes, that's also a valid concern @yoavweiss

A*B or (w, h) doesn't seem to address @eeeps concern.

@yoavweiss
Copy link
Member

A*B or (w, h) doesn't seem to address @eeeps concern.

True

@nwtn
Copy link
Member

nwtn commented Apr 23, 2014

Since coordinate sets are always (x, y), I thought it might be sufficient to address @eeeps (valid) concern. What do you think @eeeps?

@zcorpan
Copy link
Author

zcorpan commented Apr 23, 2014

I think (x, y) is not a good syntax because it looks like a coordinate but isn't one.

@zcorpan
Copy link
Author

zcorpan commented Apr 23, 2014

The only suggestion left is @yoavweiss' rw descriptor.

It looks a bit weird and it's not obvious what it expands to, but maybe that's a good thing because it makes it more likely that you'd look it up rather than assuming what it means. It makes it a bit longer though.

<img src="pic400.jpg" alt="The president giving an award." sizes="100vw"
    srcset="pic400.jpg 400rw, pic800.jpg 800rw, pic1600.jpg 1600rw">

with rh added:

<img src="pic400.jpg" alt="The president giving an award." sizes="100vw"
    srcset="pic400.jpg 400rw 300rh, pic800.jpg 800rw 600rh, pic1600.jpg 1600rw 1200rh">

Seems OK to me. Another alternative could be iw and ih (image width, image height).

Thoughts? Other ideas?

@zcorpan
Copy link
Author

zcorpan commented Apr 23, 2014

It occurred to me now that the in the rem unit the r refers to "the root element".

@eeeps
Copy link

eeeps commented Apr 23, 2014

I like how iw/ih echo the vw/vh we'll often find in sizes. Though it might be confusing that vw is a percentage and iw is a pixel count?

I considered my AxB concerns a little more and they might be unfounded. It's a marvelously concise syntax which strongly connotes a pixel area / image size. In the digital world the order is almost always WxH. I've never heard anyone complain about the OS X “Get Info...” panel.

Anybody that can learn/remember the ordering of, e.g. margin: 1em auto 3em auto can remember WxH.

(Yoav's concerns about stray spaces and "x" re-use seem valid. Maybe we could require unicode MULTIPLICATION SIGN ×? [I kid! I kid!])

Similarly, while it's impossible to intuit which of the many possible widths w refers to when first encountering it, it's easy enough to learn.

So I guess at the end of the day I don't think any of these are horrible options.

Just to throw a couple more out there:

srcset="foo.jpg (800w x 600h)"
srcset="foo.jpg 800w600h"

@Wilto
Copy link
Member

Wilto commented Apr 25, 2014

Not to swoop in, but I haven’t seen many people voice confusion around the w/h syntax, for all the speaking and tweeting and writing and whatnot I’ve been doing about it. Agreed that the lines seem a little blurry for those of us that are familiar with the old syntax, but it’s worth remembering that it never caught on enough for people to be confused about it in the first place. I honestly don’t know that we’d be solving much by switching this syntax up.

@yoavweiss
Copy link
Member

Anecdotal, but I have received bug reports from people expecting srcset to behave like what the WHATWG spec says, and have 'w' relate to the viewport. (they were glad to hear that it no longer does that though :) )

@Wilto
Copy link
Member

Wilto commented Apr 26, 2014

I’ve seen a couple too, but they’ve been from folks that go out of their way to study up on the subject—if this is much of an issue with run-of-the-mill authors, I gotta imagine it’ll be a short-lived one.

Maybe we should gather some feedback on this one, early next week?

@zcorpan
Copy link
Author

zcorpan commented Apr 30, 2014

Should we resolve this to keep the status quo? It seems we haven't come up with anything obviously better yet.

@yoavweiss
Copy link
Member

@zcorpan - I think so, since there's no significantly better alternative.
If anyone has a bright idea, feel free to re-open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants