Fixup "Art direction" docs in README.md

[zerodevx]

Thanks! Could you just run npm run format on this so code indentation is normalised?

[leoj3n]

@zerodevx Ok think I have it correct hopefully you can squash the commits for merge.

[leoj3n]

@zerodevx I have a problem with calling this section "Art Direction". It is completely misleading, as it also tends to be in the MDN docs. This is a web feature that can be utilized regardless of art direction.

[zerodevx]

No worries, will squash before merge so commit away!

I have a problem with calling this section "Art Direction".

Hmm to me that's synonymous to "customised image selection" which is apt, but open to suggestions!

[leoj3n]

From https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture

Common use cases for <picture>:

• Art direction. Cropping or modifying images for different media conditions (for example, loading a simpler version of an image which has too many details, on smaller displays).
• Offering alternative image formats, for cases where certain formats are not supported. Note: For example, newer formats like AVIF or WEBP have many advantages, but might not be supported by the browser.
• Saving bandwidth and speeding page load times by loading the most appropriate image for the viewer's display.

It's for the later two of these three options that the <Img /> component is utilizing <picture> here.

The MDN guide about "Responsive images" is all over the place:

An improvement would be to display a cropped version of the image which displays the important details of the image when the site is viewed on a narrow screen. A second cropped image could be displayed for a medium-width screen device, like a tablet. The general problem whereby you want to serve different cropped images in that way, for various layouts, is commonly known as the art direction problem.

In addition, there is no need to embed such large images on the page if it is being viewed on a mobile screen. Doing so can waste bandwidth; in particular, mobile users don't want to waste bandwidth by downloading a large image intended for desktop users, when a small image would do for their device. Conversely, a small raster image starts to look grainy when displayed larger than its original size (a raster image is a set number of pixels wide and a set number of pixels tall, as we saw when we looked at vector graphics). Ideally, multiple resolutions would be made available to the user's web browser. The browser could then determine the optimal resolution to load based on the screen size of the user's device. This is called the resolution switching problem.

To make things more complicated, some devices have high resolution screens that need larger images than you might expect to display nicely. This is essentially the same problem, but in a slightly different context.

...CSS arguably has better tools for responsive design than HTML...

The contradictory word salad here was more confusing than helpful when I was first reading up on "responsive images".

The MDN HTML/Element/picture docs linked above are much more clear and precise regarding <picture>.

Regardless, it looks like the consensus is to call usage of <picture>/srcset/sizes "responsive images". So, probably change this section header from "Art direction" to "Responsive Image Sizes".

Where you have the comment:

<!-- If viewport is <=600px, use 480px as viewport width -->

This is a bit misleading. The "sizes" aren't the actual size of the viewport itself, the sizes are the size the <img /> will be at certain breakpoints, so I would maybe change that bit to read as:

<!-- When the viewport is <=600px, tell the browser's image preloader that once the CSS for our 
design has been parsed and applied, we expect the width of the image in our design to be 480px -->

Finally, I would remove the link to the confusing "Responsive images" guide, and instead link to the more clear HTML/Element/picture docs that are more in line with how "Responsive Images" are being utilized here.

[leoj3n]

Really even the MDN docs for <picture> are kind of lame... They just randomly launch into talking about sizes:

The sizes attribute is not mandatory when using srcset, but it is recommended to use it in order to provide additional information to the browser to help it select the best image source.

Without sizes, the browser will use the default size of the image as specified by its dimensions in pixels. This may not be the best fit for all devices, especially if the image is displayed on different screen sizes or in different contexts.

Please note that sizes will have its effect only if width dimension descriptors are provided with srcset instead of pixel ratio values (200w instead of 2x for example). For more information on using srcset, see the Responsive images documentation.

Without showing any example. They also aren't explicit in saying the sizes= should be on <source>.

There are docs for HTMLImageElement/sizes but they don't show any example of using sizes with <picture>/<source>.

I feel like they kind of dropped the ball on these docs.

EDIT: I see in the "Responsive images" guide, they do have the following line:

The srcset attributes contain the path to the image to display. Just as we saw with <img> above, <source> can take a srcset attribute with multiple images referenced, as well as a sizes attribute. So, you could offer multiple images via a <picture> element, but then also offer multiple resolutions of each one. Realistically, you probably won't want to do this kind of thing very often.

It's nice to see that at least here, buried in the depths of this guide, they are explicit about putting sizes on <source>.

However, saying "Realistically, you probably won't want to do this kind of thing very often" is on par with "CSS arguably has better tools for responsive design than HTML".

Isn't this advice all over the place and misguided or am I crazy? I'd say you would want to do this kind of thing for almost any/every website you build (hence the existence of svelte-img and others), and that loading images from CSS is objectively worse in every way and should be avoided when possible. Sorry for ranting but curious if you agree.

[zerodevx]

Isn't this advice all over the place and misguided or am I crazy?

Well, you know what they say - everyone has an opinion. 😆

People have different ideas on handling images and it's not made easier with browser differences, new formats, retina images and stuff.

svelte-img is really made to just use and forget IMO - it just comes with sensible enough defaults that are performant enough, yet easy enough to override; so consumers can quickly move on and spend time on the meaty stuff, like business logic.

Anyway, LGTM - will merge. Thanks so much for your contribution! 🙏