W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2016

Re: [whatwg] [proposal] Gallery element

From: Hans Schmucker <i@hansschmucker.de>
Date: Wed, 13 Jul 2016 16:35:32 +0200 (CEST)
To: Domenic Denicola <d@domenic.me>, whatwg@whatwg.org
Message-ID: <1457192780.196127.5ea3ddc5-55ea-43b0-9a1b-22ebb1dcafd2.open-xchange@email.1und1.de>

> Domenic Denicola <d@domenic.me> hat am 13. Juli 2016 um 15:14 geschrieben:
> Thanks for the thoughtful description of the problem! If you haven't seen it
> before,
> https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
> has a description of how we try to approach situations like this. In that
> spirit, I'll try to respond to what I perceive as the use cases and underlying
> problems you're experiencing.

Thanks for the pointers Domenic, I had not seen this particular document and
there are a lot of valid issues raised in there... specifically a different
approach that puts the actual issue front and center instead of one possible

> The first problem you describe is trying to add meaning to convey that
> something is a gallery. The idea, presumably, being that you have some
> software in mind that might benefit from knowing about galleries across the
> web as it scrapes web sites. Could you describe this software in more detail,
> and the ways in which it currently tries to search for and present galleries?

> In general the best way to add extended semantics to HTML for these kind of
> less-common use cases is to use something like https://schema.org/. Have you
> considered if there are any structured data vocabularies you could use
> alongside existing markup?

You are correct in that this could be solved via micro-formats. The only real
issue here is that galleries are a very common feature, but this is an edge case
and you are quite correct in that we could and probably should ignore this for

The real issue for me is usability and ease of access for developers. The simple
truth is that most galleries available on the web are a pain to use on mobile
devices. And providing a near-native experience is so much work that even big
players often prefer leaving their web-page in an unsatisfactory state and
encouraging users to install an app instead.

> It sounds like you are hoping to be able to customize the presentation of your
> photo galleries according to who views it. Are existing responsive design
> features (such as , srcset, @media, @viewport, and so on) not meeting your
> needs in some way? Can you describe how you have tried to use them but run
> into cases where they fail?

It's not so much that I wish to customize it. The technology available to do
that is entirely sufficient and with enough time a perfect gallery which detects
the OS and emulates the convention of each platform could be implemented.

What we're missing is a reasonable fallback behavior for when the developer
doesn't possess the skills to implement an acceptable solution. And I feel that
with galleries we currently don't live up to these standards. 

A major platform for perfect gallery hosting could theoretically emerge and fill
this void, much like YouTube did for video, but web pages should at least
function reasonably well on their own and currently that's not really the case
from a mobile user's perspective
when it comes to galleries. 

So, the abstract problem that I was trying to solve would be:
"Make implementing image browsing on mobile platforms so easy to implement that
even smaller players (I'm talking about restaurants or plumbers) can provide an
acceptable experience to their users".

> One thing you describe is customizing according to OS versions. This is
> generally somewhat against the design grain of the web, which tries to present
> a single experience that is responsive to different devices, instead of a
> per-device custom experience. Is there something that makes you think that
> picture galleries should be an exception from that?

You are correct in that it is a relatively uncommon behavior. The video element
is pretty much the only example of an element that (if the developer desires so)
handles its behavior on its own (it's also a pretty bad example in that the
native controls are rarely used as they were not implemented by all major
players for quite some time... also, videos are rarely self-hosted). The main
reason I was thinking about it is the simple experience that images are very
difficult to present in an intuitive format on mobile. But this should probably
take a backseat to implementing a reasonable behavior, whatever that may be.

Thanks VERY much for your feedback Domenic.
Received on Wednesday, 13 July 2016 14:36:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:38 UTC