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 <picture>, 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 <img>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!
