W3C home > Mailing lists > Public > public-html@w3.org > July 2016

Galleries revisited

From: <i@hansschmucker.de>
Date: Thu, 14 Jul 2016 14:10:13 +0200
To: <public-html@w3c.org>
Message-ID: <00c001d1ddc8$ad93b030$08bb1090$@hansschmucker.de>
Thanks to the feedback from both the W3C and WHATWG lists I think that the
gallery element is not necessarily something we should focus on. At least
not in the sense that the inline presentation is of much importance.
Designing the overview and embedding it is something that can be handled by
using existing standards and there are other proposals like panelssets (
https://bkardell.github.io/common-panel/prototype/panelset-element.html )
which will make creating the overview even easier. I'm not saying this is
something that we should abandon entirely, but I think it's safe to spin
this off into a seperate issue.

So let's focus on the remaining issue:
While there is an easy method for showing individual images in a way that is
appropriate on both desktop and mobile (namely a simple link, which any UA
will display appropriately, along with a way to return to the current
document), there is no way to do the same for
-images with description 
-series of images (with or without description)
-items of any kind which can be rendered as an image

The only way people are able to render such data is by either including all
images in the gallery directly or as a series of links. The UA on the other
hand is unable to produce anything from this series of links without
guessing since there is no standardized format for determining if a series
of links form a gallery.

Microformats ARE able to describe this and in fact a UA could choose to
render a series of microformat-described figure elements in a desirable way.

The remaining issue for me seems that the interaction between this "viewer"
and the page is completely unspecified and that items like descriptions and
copyright notices which may be required to make sense of an image may or may
not be shown.

Also, an image may represent an item of any kind or offer actions on it (for
example "Download the PDF", "View the subgallery", "Show related images",
"Go to full description"), which the page may be unable to perform if there
is no standardized way to interact with the UA.


--------------------------


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 ot
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.
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 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.
Received on Thursday, 14 July 2016 12:10:51 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 14 July 2016 12:10:51 UTC