Provide a simplified UI to support current responsive image standards

Follow-up to #2334387: UI changes to support current responsive image standards

Problem/Motivation

Alternative approach: what is we provide 2 edit screens, a basic to define the sizes and an advanced one as outlined above.

Basic one can be something like this:

1/ If your theme has a max width, enter the max width and enter the width of the image in px, so the browser will not try to download images that are too big.
The output will be: (min-width: 80em) 424px
2/ A table with 2 input fields per row: one for the MQ, one for the width
"Start with the widest (when using min-width MQs)
If my page is 43em wide, my image is 40 % wide
The row will get translated into (min-width: Column 1) Column 2 vw
The output will be: (min-width: 43em) 40vw
3/ On mobile my image will be 90% wide
The output will be: 90vw

Output in the browser will be: (min-width: 80em) 424px, (min-width: 43em) 40vw, 100vw

At the top of this page we can instruct the user when they might want to use the advanced edit mode:
In case you want to support the art-direction case or you want to support multiple image formats simultaneously, you can use the advanced edit mode.

Proposed resolution

Build the new UI

Remaining tasks

User interface changes

Described above.

API changes

There are no API changes: those have already been taken care of in other issues. This would just improve the ability to make use of those API changes through a UI.

Background information

Selecting the right source file for an image is greatly simplified with the new sizes attribute, which is available for either the img element or for source elements within the picture element, in conjunction with a corresponding srcset attribute.

The sizes attribute lists a series of potential sizes for an image, along with possible media conditions associated with those sizes. For example:

sizes="(min-width: 50em) 25%; (min-width: 30em) 50%; 100vw"

This means that if a viewport has a minimum width of 50em (in most cases 800px), an image takes up 25% of the width of the viewport. Below that, if a viewport is at least 30em (typically 480px), the image is 50% of the viewport width. Below that, the image takes up the full width of the viewport.

This can then be paired with a srcset attribute that contains a list of image files and the width of each image file. The browser can then do the hard work of calculating at any given viewport size which source file best fits the available space given the resolution of the device. The browser can also take into consideration bandwidth, delivering a lower-quality image if bandwidth is shoddy, so the page loads faster.

For a lot of use cases, an img element plus sizes and srcset attributes provides a great responsive image solution that is much easier to implement than a full picture element.

There are definitely use cases for the full picture element, particularly if you are providing different types of image files (webp for browsers that can handle it, jpg for those that can't) or if you're going to do art direction (cropping an image more closely at smaller sizes, so the main subject is easier to view). We don't have a good way to do art direction in core, but that will likely be possible through contrib. Yoav Weiss, who has been implementing the picture element in Chrome and Safari, has a great writeup of the various use cases: https://dev.opera.com/articles/native-responsive-images/

Beta phase evaluation