Re: [whatwg] [proposal] Gallery element

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
 delfin@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 _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
 

Links:
------
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20delfin@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info

Received on Wednesday, 13 July 2016 17:32:23 UTC