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

Re: [whatwg] [proposal] Gallery element

From: Jonathan Zuckerman <j.zuckerman@gmail.com>
Date: Wed, 13 Jul 2016 08:36:34 -0400
Message-ID: <CAPP4rD8RG=Q=ygTbRoZUekUaMXOe02NKAHO--CXE0-EFTCW0ng@mail.gmail.com>
To: Hans Schmucker <i@hansschmucker.de>
Cc: whatwg@whatwg.org
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 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 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.

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:
> <h2>My photos</h2>
> <gallery content="photo" protected="true">
>     <figure>
>         <picture><img title="Test photo 1" alt="The first test, showing
> Mannheim
> at night" srcset="test1s.png"/></picture>
>         <figcaption>A beautiful night</figcaption>
>     </figure>
>     <figure>
>         <picture><img title="Test photo 2" alt="The first test, showing a
> street
> at night" srcset="test1s.png"/></picture>
>         <figcaption>OK, so it’s slightly blurry</figcaption>
>     </figure>
> </gallery>
> 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
> <h2>My photos</h2>
> <gallery content="photo" protected="true" embedded="false">
>     <picture><img title="Mannheim" alt="Pictures of Mannheim"
> srcset="test1s.png"/></picture>
>     <gallery content="photo" protected="true">
>         <figure>
>             <picture><img title="Test photo 1" alt="The first test, showing
> Mannheim at night" srcset="test1s.png"/></picture>
>             <figcaption>A beautiful night</figcaption>
>         </figure>
>     </gallery>
> </gallery>
> 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
Received on Wednesday, 13 July 2016 12:37:29 UTC

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