Initially this was about an issue raised on the whatwg and w3c public mailing lists. So if you want to read the full discussion you can find it here:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2016Jul/thread.html ( Gallery element & Galleries revisited ) and here: http://lists.w3.org/Archives/Public/public-html/2016Jul/thread.html ( Gallery element & Galleries revisited )
(There’s not really much point repeating everything here)
The point is that displaying one or more related images with an optional description in a matter which is appropriate for ALL platforms is far too difficult on the web. So difficult in fact that even big players have pretty much given up on doing it on all platforms and usually direct you to their mobile app. I’m not saying it is impossible, but it is hard work and the result if you fail to do it is extraordinarily unpleasant to use.
While displaying the overview is something that can be solved with acceptable effort, displaying the images and reacting appropriately to gestures that are standard on the platform (swipe, buttons, zoom gestures), while technically possible, is so much effort that nobody can expect an average web designer (I’m not talking about people working at Facebook or Google, I’m talking about the guys who make sure your plumber has a homepage) to succeed here. Of course, this could be done as a service or with a third party library, but the simple fact that this hasn’t happened so far is telling of how difficult this is.
While developers are always free to implement a custom solution if they think can do better, what we’re missing is a basic solution that will just work with minimal effort. Something like the controls attribute for video.
Proposal:
Standardize a way to declare a union of items which are represented by an image, have (optional) essential descriptions, can be moved outside the context of the page and can offer additional actions by interacting with the page via url and script.
There are a couple of existing standards which already take care of some of the issues, for example FIGURE, PICTURE and IMAGE. Whether other items like VIDEO or CANVAS can adequately be represented is something I’m not entirely sure about. While it is certainly desirable, the burden of implementing this may be too big. There’s a pretty good chance that we’ll get inconsistent results in that case.
For the interaction with the page we may want to take a page from FORMs, with each action essentially being a form action which may be performed via a FORM element or captured using appropriate event handlers. No need to reinvent the wheel.
Invoking the gallery is actually a bit of a problem, since we have no directly visible element which can be used for this purpose. I’d suggest making the gallery handle all clicks, while reminding authors that they can simply stop propagation.
One major issue that’s still open is how we are going to differate between the content meant for rendering the gallery as a whole and the one meant to be displayed full-size. A UA-rendered gallery overview would have avoided the issue but with custom galleries, there’s going to be a lot of content that is really just styling. On the other hand, we don’t want to punish developers with clean CSS by forcing them to include the same content twice. A single FIGURE element should be sufficient to describe thumbnail and expanded view. I’d suggest simply making the gallery element very strict about what it accepts as valid content, while still giving a defined behavior for cases when there’s “invalid” content. That way “invalid” content can be used for presentation purposes.
Based on all this I’d suggest the following:
The gallery is a block element containing figure and/or other content. It has no visible representation aside from its content. Each figure which is a direct or indirect descendent of the gallery element represents a frame. Frames can not be nested. The viewer is invoked when a click event that was triggered on a FIGURE element bubbles up to the GALLERY. The UA presents the frame to the user by performing the following steps:
- The figure element gets a min-width of the full-screen area
- The figure element gets a min-height of the full-screen area
- The figcaption gets a display:none
- All form elements inside the figure element are set to display:none
- A focus event is fired on the figure element
- A fullscreen event is fired with the fullscreen element set to the figure element
- A snapshot of the figure’s DOM is taken
- The UA takes a snapshot of the figcaption’s textContent
- The UA compiles a list of all input type=button and input type=submit elements inside the figure
- The UA may slow down rendering of the page at this point
- The snapshot is rendered to an image (the UA SHOULD choose an appropriate density, at least 2x the display density)
- The UA MAY prerender other frames inside the galleries according to the same rules (except it doesn’t raise another fullscreen event, but sets the fullscreen element)
- The UA MUST update the rendering when new resources become available, for example if a picture has been loaded at a higher resolution
- The UA displays the image with platform-appropriate controls, it SHOULD display controls for navigating among the images and MUST display controls for exiting the viewer mode
- The UA MUST present the figcaption textContent along with the rendered content (however it may hide it after a brief period)
- The UA MUST display the list of INPUT elements. Activating one of these INPUT element closes the viewer and raises the appropriate event on the INPUT element (it MAY however hide the list behind a menu)
- When the user navigates to a different figure, the UA MUST raise a focus event on that element before rendering it
- On close, a full screen exit event is fired
Example HTML
<gallery>
<div>
<figure>
<picture><img src="..." /></picture>
<figcaption>...</figcaption>
<figure>
<div>
Additional controls
<div>
</div>
<figure>
<form action="download.php" method="GET">
<input type="hidden" name="pic" value="..." />
<input type="submit" value="Download" />
</form>
<picture><img src="..." /></picture>
<figcaption>..</figcaption>
</figure>
</gallery>
Still pretty broad strokes, but I think we’re getting there. I’ll try to write up an implementation for Firefox desktop and mobile during the weekend, so we can play around with it a little more.
So, are there any issues you can think off? Any reason why implementors may be opposed to this? Anything that will make you think this won’t be accepted by web developers?
