Re: [whatwg] [proposal] Gallery element

[Delfi Ramirez]

Hi Hans, et al. 

_IF there is consensus that this IS worth investigating, then I'd gladly
help_
_write up a few proposals and sample implementations._ 

agree. 

_A gallery should be a _a series of related pictures which have a
combined topic,_
_as well as an individual message.__ 

agree. 

I would suggest  "a series of related _frames_". 

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. 

agree with the assertion and the objective need of gestures: _"but with
appropriate gestures in place."_ 

Desktop users are used to menu-less thumbnail overviews with lightboxes
for
full-size images, because zooming is not a huge priority 

Please, take in consideration, r_elated frames_ from a Gallery may
concern collections of objects which are not necessarily _photos._ 

_Suggested: if Desktop users hold a deep knowledge or an expertise in
the field of Fine Arts , these users may find zooming a priority. 
Consider to what it serves and for what is useful the act of zooming._ 

_Suggested:_ There is still in our days, both in web design as in web
code, to failure to develop and treat  "thumbnails" ( an object or
frame)  like "buttons". Pretty 1997-esque. A mistake in behaviour and
DOM interaction. 

_A gallery should be a _a series of related pictures which have a
combined topic,_
_as well as an individual message.__ 

agree

_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__

agree 

_(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)._ 

uhm. disagree.

_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)._ 

agree.

_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.._ 

completely agree, refer above. 

Cheers

---

Delfi Ramirez -- At Work

My digital signature [1]

0034 633 589231
 del...@segonquart.net [2] 

twitter: @delfinramirez [3]
 IRC: segonquart
 Skype: segonquart [4]

http://segonquart.net

http://delfiramirez.info
 [5]

On 2016-07-13 14:12, Hans Schmucker 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 

Re: [whatwg] [proposal] Gallery element

[Hans Schmucker]

> Domenic Denicola  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
solution.

> 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
now.

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.

Re: [whatwg] [proposal] Gallery element

[Hans Schmucker]

Thanks for the reply Jonathan.

> Jonathan Zuckerman  hat am 13. Juli 2016 um 14:36
> geschrieben:
> 
> 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
implement.

I've actually written a little example over at
http://hansschmucker.de/GalleryElement/
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  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 

Re: [whatwg] [proposal] Gallery element

[Domenic Denicola]

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Hans 
Schmucker

> 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.

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.

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?

> 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.

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?

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?

> 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).

We discussed the platform-appropriateness above. Are there things preventing 
you from implementing navigation among figures and inspection of a figure (e.g. 
zooming) in today's HTML, JavaScript, and CSS?

> 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).

This sounds more like a user agent feature request that would apply equally to 
all s, and not to galleries in particular. In my experience existing user 
agents are pretty good at providing these features already. Have you noticed 
gaps? If so, that might be better filed as bugs on the user agents, as it is 
generally outside the realm of specs.

> 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.

As you say, it sounds like it's solvable to do this with existing CSS, in which 
case we don't need to add anything to specs.


Anyway, hope this helps!

Re: [whatwg] [proposal] Gallery element

[Jonathan Zuckerman]

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  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 

[whatwg] [proposal] Gallery element

[Hans Schmucker]

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