Thanks for the reply Jonathan.
> Jonathan Zuckerman <j.zucker...@gmail.com> hat am 13. Juli 2016 um 14:36
> Hi Hans, I'm not an important figure at all in the web world, but my
> intuition is this isn't a good candidate for a new feature in HTML. You've
> done a good job of abstracting the problem and exploring the edge cases but
> the feature is just too specific.
> I doubt site owners would want to use it. Most sites have a very distinct
> visual style and falling back to the platform's design patterns might not
> fit with that.
It's definitely a bit problematic. Web developers naturally crave control over
their design. You're probably right in that it's unrealistic to expect authors
to hand over too much control over their design to the UA. On the other hand,
the overview is something that's pretty similar across desktop and mobile
platforms... so maybe there's some common ground if the standard defines a
default style that is platform-dependent, but can be overridden via CSS. It may
have to be a little less abstract, but I think we could still come up with a
solution that will improve the experience for the user.
> I doubt browser vendors would want to implement it. As you stated, " the
> conventions for displaying a list of images are very different for
> practically every platform". Any browser that operates on different
> platforms (the most popular one operates on practically every platform
> there is) would have a difficult job indeed of making it function
> intuitively in all situations.
I don't think it's much of an issue for browser vendors though. Mobile platforms
usually have some sort of universal gallery routine readily available and the
only real convention on the desktop platform is "don't open another application
without asking", so a lightbox or something like that should be easy to
I've actually written a little example over at
in order to explore a couple of concepts. Desktop isn't really too complicated,
it's more about providing a consistent experience for mobile users.
> On Wed, Jul 13, 2016 at 8:12 AM, Hans Schmucker <i...@hansschmucker.de> wrote:
> > Note: I've already sent this to the W3C public-html list, and while there
> > hasn't
> > been any response so far, it is possible that issues will be raised on both
> > channels. The original message along with replies is available at
> > http://lists.w3.org/Archives/Public/public-html/2016Jul/0011.html .
> > Although
> > I'll do my best to transport raised issues between both lists.
> > Right now this is little more than a description of a problem with a rough
> > outline how a solution could work, so there are obviously a lot of issues
> > not
> > discussed in this proposal. What I'd like to discuss is whether this has
> > any
> > place in the HTML specification at all. My personal opinion is that it
> > would
> > lend meaning to something that today is mostly tag-soup, but your opinion
> > may
> > differ and that's what I'm most interested in hearing about.
> > IF there is consensus that this IS worth investigating, then I'd gladly
> > help
> > write up a few proposals and sample implementations.
> > Maybe I’m overlooking something, but I’m currently writing another JS
> > gallery
> > (there are some special requirements, but that’s beside the point) and
> > there’s
> > one thing that bothers me: There really is no way to write a perfect
> > gallery for
> > all platforms, for the simple reason that the conventions for displaying a
> > list
> > of images are very different for practically every platform.
> > Desktop users are used to menu-less thumbnail overviews with lightboxes for
> > full-size images, because zooming is not a huge priority. Mobile users
> > prefer
> > full-screen images without any controls, but with appropriate gestures in
> > place.
> > The specifics (like how annotations are presented, which options are
> > present and
> > which animations are expected) even differ between OS versions.
> > All that combined with the simple fact that there simply is no way to mark
> > up a
> > gallery correctly at this time, while the web is exploding with graphics,
> > makes
> > me think that we should consider adding gallery element.
> > A gallery should be a _a series of related pictures which have a combined
> > topic,
> > as well as an individual message._
> > Its content (one figure per item) should be shown to the user in a way
> > which is
> > _appropriate for the platform_, allowing him to _navigate among the
> > figures_
> > (giving an overview first and allowing him to drill down) as well as
> > showing the
> > content in a way which allows him to _inspect all its aspects_ (i.e.
> > zooming).
> > A full-screen gallery would be best from a user’s perspective, but webpages
> > would have big reservations about their gallery being displayed outside the
> > context of their page. So the gallery element should NOT function as a
> > link to a
> > full-screen application, but like a normal block element, displaying the
> > gallery
> > overview in the specified area (along with appropriate controls).
> > The user agent may choose an appropriate size for the individual pictures,
> > without any limitations. A _content attribute_ may be given to allow for
> > appropriate presentation. Values may (for example) include photo, icon,
> > art..
> > Each picture may have a title, which the user agent must show along with
> > each
> > image. The description on the other hand should be shown only when an
> > image is
> > inspected individually. The user agent may hide the caption after a brief
> > period, but it must initially be visible.
> > Example:
> > My photos
> > A beautiful night
> > OK, so it’s slightly blurry
> > A user agent may also provide appropriate actions for each image, for
> > example
> > download, share, print and so on. A gallery may indicate that its content
> > is
> > protected by specifying protected="true", in which case the user agent
> > should
> > restrict the use to pure viewing (however, actual protection is not
> > required,
> > the presence of protected="true" merely indicates the intended use).
> > Galleries may also be nested. If a gallery element contains another
> > gallery, the
> > first picture element is meant to describe the gallery as a whole. The user
> > agent is free to show the sub-gallery inside the initial rectangle or
> > full-screen at its own discretion.
> > Example
> > My photos
> > A beautiful night
> > A webpage may prevent the user-agent from opening any images in
> > full-screen view
> > by specifying embedded="true", in which case the user agent should render
> > the
> > image, with appropriate control inside the rectangle specified by the
> > gallery
> > element.
> > Presentation
> > Defining the behavior of a gallery isn’t easy for all platforms. For
> > example,
> > it’s not that easy to specify a universal size for thumbnails. A
> > photographer
> > may require a much bigger thumbnail image for identification of a specific
> > image
> > than an icon catalog designer.
> > The smallest reasonable size on a platform on the hand may require a larger
> > image for optimal navigation than what the designer intended. Or the
> > platform
> > may be unable to show more than an overview before entering a separate
> > mode for
> > navigation.
> > From a design standpoint, the number of rows is often as important as the
> > size
> > of the gallery. So how do we account for all these cases while giving
> > designers
> > a predictable result that they can incorporate into their design?
> > Basically, we’ll need an element that will either
> > a) Cover a specified area or
> > b) Fit into a column with an intrinsic height
> > Which additionally
> > Has a minimum specified size per element.
> > There’s also the issue to consider that not all images are the same.. Some
> > may
> > be suitable for cropping, others may be suitable for scaling and so on and
> > so
> > forth.
> > Getting the CSS right is obviously an issue, but a solvable one if there's
> > any
> > interest in doing this.
> > The basic question that I'm asking is whether this is something that is
> > worth
> > pursuing. The specifics are still very much in flux.
> > Hans Schmucker
> > i...@hansshmucker.de