Re: [whatwg] Galleries revisited

2016-07-14 Thread Delfi Ramirez
On 2016-07-14 18:21, Domenic Denicola wrote:

>> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of 
>> i...@hansschmucker.de
> 
>> _The remaining issue for me seems that the interaction between this "viewer" 
>> and the page is completely unspecified and that items like descriptions and 
>> copyright notices which may be required to make sense of an image may or may 
>> not be shown._
>> 
>> _ Also, an image may represent an item of any kind or offer actions on it 
>> (for example "Download the PDF", "View the subgallery", "Show related 
>> images", "Go to full description"), which the page may be unable to perform 
>> if there is no standardized way to interact with the UA._
> 
> I don't think the below proposal is a good way to address this. I'd suggest 
> creating your own library to implement the desired functionality, possibly 
> using microformats for the semantic aspects, and seeing if it gets adoption. 
> If it becomes very popular, maybe we could consider asking implementers if 
> they are interested in adding it to the platform, like they have done with 
> aspects of other popular libraries such as jQuery. But I think you are still 
> too quick to jump to asking implementers to implement a new element.

agree 

---

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]
 

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


Re: [whatwg] Galleries revisited

2016-07-14 Thread Domenic Denicola
> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of 
> i...@hansschmucker.de

> The remaining issue for me seems that the interaction between this "viewer" 
> and the page is completely unspecified and that items like descriptions and 
> copyright notices which may be required to make sense of an image may or may 
> not be shown.
>
> Also, an image may represent an item of any kind or offer actions on it (for 
> example "Download the PDF", "View the subgallery", "Show related images", "Go 
> to full description"), which the page may be unable to perform if there is no 
> standardized way to interact with the UA.

I don't think the below proposal is a good way to address this. I'd suggest 
creating your own library to implement the desired functionality, possibly 
using microformats for the semantic aspects, and seeing if it gets adoption. If 
it becomes very popular, maybe we could consider asking implementers if they 
are interested in adding it to the platform, like they have done with aspects 
of other popular libraries such as jQuery. But I think you are still too quick 
to jump to asking implementers to implement a new element.



[whatwg] Galleries revisited

2016-07-14 Thread i
Thanks to the feedback from both the W3C and WHATWG lists I think that the
gallery element is not necessarily something we should focus on. At least
not in the sense that the inline presentation is of much importance.
Designing the overview and embedding it is something that can be handled by
using existing standards and there are other proposals like panelssets (
https://bkardell.github.io/common-panel/prototype/panelset-element.html )
which will make creating the overview even easier. I'm not saying this is
something that we should abandon entirely, but I think it's safe to spin
this off into a seperate issue.

So let's focus on the remaining issue:
While there is an easy method for showing individual images in a way that is
appropriate on both desktop and mobile (namely a simple link, which any UA
will display appropriately, along with a way to return to the current
document), there is no way to do the same for
-images with description 
-series of images (with or without description)
-items of any kind which can be rendered as an image

The only way people are able to render such data is by either including all
images in the gallery directly or as a series of links. The UA on the other
hand is unable to produce anything from this series of links without
guessing since there is no standardized format for determining if a series
of links form a gallery.

Microformats ARE able to describe this and in fact a UA could choose to
render a series of microformat-described figure elements in a desirable way.

The remaining issue for me seems that the interaction between this "viewer"
and the page is completely unspecified and that items like descriptions and
copyright notices which may be required to make sense of an image may or may
not be shown.

Also, an image may represent an item of any kind or offer actions on it (for
example "Download the PDF", "View the subgallery", "Show related images",
"Go to full description"), which the page may be unable to perform if there
is no standardized way to interact with the UA.


--


Proposal:

Standardize a way to declare a union of items which are represented by an
image, have (optional) essential descriptions, can be moved outside the
context of the page and can offer additional actions by interacting with the
page via url and script.

There are a couple of existing standards which already take care of some of
the issues, for example FIGURE, PICTURE and IMAGE. Whether other items like
VIDEO or CANVAS can adequately be represented is something I'm not entirely
sure about. While it is certainly desirable, the burden of implementing this
may be too big. There's a pretty good chance that we'll get inconsistent
results in that case.

For the interaction with the page we may want to take a page from FORMs,
with each action essentially being a form action which may be performed via
a FORM element or captured using appropriate event handlers. No need to
reinvent the wheel.

Invoking the gallery is actually a bit of a problem, since we have no
directly visible element which can be used for this purpose. I'd suggest
making the gallery handle all clicks, while reminding authors that they can
simply stop propagation.

One major issue that's still open is how we are going to differate between
the content meant for rendering the gallery as a whole and the one meant ot
be displayed full-size. A UA-rendered gallery overview would have avoided
the issue but with custom galleries, there's going to be a lot of content
that is really just styling. On the other hand, we don't want to punish
developers with clean CSS by forcing them to include the same content twice.
A single FIGURE element should be sufficient to describe thumbnail and
expanded view. I'd suggest simply making the gallery element very strict
about what it accepts as valid content, while still giving a defined
behavior for cases when there's "invalid" content. That way "invalid"
content can be used for presentation purposes.

Based on all this I'd suggest the following:

The gallery is a block element containing figure and/or other content. It
has no visible representation aside from its content.
Each figure which is a direct or indirect descendent of the gallery element
represents a frame.
The viewer is invoked when a click event that was triggered on a FIGURE
element bubbles up to the GALLERY.
The UA presents the frame to the by performing the following steps:

*The figure element gets a min-width of the full-screen area
*The figure element gets a min-height of the full-screen area
*The figcaption gets a display:none
*All form elements inside the figure element are set to display:none
*A focus event is fired on the figure element
*A fullscreen event is fired with the fullscreen element set to the figure
element
*A snapshot of the figure's DOM is taken
*The UA takes a snapshot of the figcaption's textContent
*The UA compiles a list of all input type=button and input type=submit
elements inside the