Update the Definition of Draft Property u-photo

[dshanske]

The definition under which u-photo became a draft property was one or more photos that is/are considered the primary content of the entry, unless there is a p-location h-card, which is still considered a "checkin" (i.e. with a photo). Otherwise the presence of a u-photo means the name of the entry should be interpreted as a caption on the photo, and the summary/content should be interpreted as a description of the photo.

However, this definition is not precise enough and needs to be refreshed before this becomes a stable property. There must be two publishers and two consumers consistent with the refreshed definition.

This definition needs to define what a multiphoto post is, specifically what multiple u-photo properties in an entry indicate. Bridgy, for example, in consuming h-entry to POSSE to Twitter, includes only the first four u-photo properties it finds, as that is Twitter's limit.

The final issue that has to be covered, the relationship of u-photo and its ilk to e-content, is open for discussion in #23

[gRegorLove]

I'll take a crack at this:

u-photo: when the primary content of the entry is a still image or set of still images, add u-photo to the image element(s).

• if the entry has a name property, that should be used as the caption for the image(s)
• if the entry has a content property, that should be used as the description for the image(s)

Edit: Changed to "still image or set of still images"

[chee]

as @tantek mentioned on irc, this would be a great opportunity to say something like "still image or set of still images" so it's clear that "u-photo" is not just for literal photographs

[gRegorLove]

Re-reading this, I'm not sure I'm clear on the difference between "caption" and "description", so we should probably clarify that. The text "the presence of a u-photo means the name of the entry should be interpreted as a caption on the photo, and the summary/content should be interpreted as a description of the photo" originally came from 2014.

It made me curious how published photo posts use p-name and e-content. From the several examples I've reviewed, almost all use e-content for the caption. Some also duplicate the caption text in p-name. Only one appears like it might support additional description text in e-content, but I did not find an example of it.

Below is what I found from reviewing https://indieweb.org/photo#IndieWeb_Examples. Let me know any other examples and I can update this list.

e-content for caption, no p-name

• https://aaronparecki.com/2022/12/01/13/oauth
• https://www.ciccarello.me/photos/2021/06/21/initial-photo/
• https://www.kartikprabhu.com/notes/dusty-rhodes-watershed
• https://gregorlove.com/2022/11/moulin-rouge-is-one-of-my/
• https://martymcgui.re/2016/04/28/133049/

both e-content and p-name with same text

• https://adactio.com/notes/19722
• https://calumryan.com/notes/3655
• http://tantek.com/2022/289/t1/hot-skyline50k-ultra-finish
• https://sixtwothree.org/photos/256

other:

• https://mxd.codes/photos/cap-formentor-mallorca p-name and e-content, but latter is only an empty <div>. Speculating: That may be an optional extended description for the photos, but I couldn't find an example of that.

[calebhearth]

Has any consideration been given to how u-photo interacts with <picture> that would include multiple variations of the same photo (or potentially even animated vs non-animated in the case of <source media="(prefers-reduced-motion)">?

The semantics around <picture> allow many attributes to fall back to the child <img> element's attributes (alt, title, height, width, etc.) but if we follow that then we leave out the chance to benefit by supporting alternatives. We could suggest that the u-photo be added to <picture> (and <video> and <audio> for relevant classes) directly and somehow specify that several URLs point to the same content, perhaps also grabbing [srcset], [media], [type], and other useful values to help a consumer determine which URL to select.

[jgarber623]

@calebhearth There's been related conversation and work done over the last ~year or so in microformats/microformats2-parsing#7. Some of the official parsers have added srcset parsing but I don't think there's been a consensus on how to handle the <picture> element and its kinfolk.

Related:

• Parse srcset and return different image URLs (and do the same for [video] sources?) microformats2-parsing#53
• Support <picture> element microformats2-parsing#54