Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

u-photo draft->core bc way more than 3+ pub and consuming impls/sites #4

Open
tantek opened this issue Feb 16, 2017 · 7 comments
Open
Assignees

Comments

@tantek
Copy link
Member

tantek commented Feb 16, 2017

It appears from http://indieweb.org/photo#IndieWeb_Examples that there are way more than 3+ publishing sites that support u-photo

  • Need to verify proper markup on those examples!

For consuming, known implementations include:

    1. Woodwind.xyz
  • photo-comment consumers https://indieweb.org/photo_comment#IndieWeb_Examples that then display those photo comments
    1. Redwind
  • WordPress through a plugin?
  • Would be nice to to verify how @snarfed is implementing photo-comments
  • Other consuming code:
    1. Bridgy Publish consumes u-photo for purposes of POSSEing that photo to various destinations specifically as a photo. (update per @snarfed comment below)
  • Would be nice to determine what other kinds of u-photo consuming code / libraries / applications there may be

This issue is for tracking the maturity of u-photo to transition it to a core property.

Once all the "Need to" items above have been processed and resolved successfully, we should be able to move forward.

cc: @kylewm @snarfed @aaronpk @benwerd

Update: confirmed 3 consuming sites/implementations. See Above.

@snarfed
Copy link
Member

snarfed commented Feb 16, 2017

bridgy supports u-photo for publish (POSSE): https://brid.gy/about#picture

and backfeed: https://brid.gy/post/twitter/schnarfed/831552681210556416 . simplified markup snippet:

<article class="h-entry">
  <span class="p-author h-card">
    <a class="p-name u-url" href="https://snarfed.org/">Ryan Barrett</a>
    <img class="u-photo" src="https://pbs.twimg.com/profile_images/459041662707060736/Kb9Ex4X8.jpeg" alt="" />
  </span>
  <div class="e-content p-name">
  💯💯💯 (by <a href="https://twitter.com/itsmaeril">@itsmaeril</a>)
  </div>
  <img class="u-photo" src="http://pbs.twimg.com/media/C4pEu77UkAAVy9l.jpg" alt="attachment" />
  ...

@pfefferle
Copy link

pfefferle commented Feb 16, 2017

The WordPress Semantic-Linkbacks Plugin (webmention) is supporting u-photo in h-cards for avatars. The h-entry photo is not handled by a WordPress plugin yet.

@aaronpk
Copy link
Member

aaronpk commented Mar 7, 2018

Aperture consumes the u-photo property on posts. All 3 current Microsub clients (Monocle, Together, and Indigenous) also consume the property to display photos in the reader interfaces.

@tantek tantek self-assigned this Jun 27, 2018
@dshanske
Copy link
Member

We need to, for the sake of this proposal, define u-photo. The wiki's draft definition is:

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

The statement about p-location h-card needs to be clarified? Should this be part of the definition of the property or should it read, "One or more photos that is/are considered the primary content of the entry. 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." When other properties change interpretation seems a matter for Post Type Discovery.

@dshanske
Copy link
Member

At the Microformats session today, it was decided by consensus that there were additional items that needed to be addressed, #23 and #24 prior to moving this property to core.

@btrem
Copy link

btrem commented Dec 1, 2022

It seems to me that u-photo is inconsistently defined. For h-recipe, it is merely "an accompanying image," whereas for h-entry it is "one or more photos that is/are considered the primary content of the entry...."

I suppose the thinking is that if an h-entry is not primarily a photo, there's no need to add a specific class name to a photo. But why is there such a need for h-recipe? It appears that the point is to specify a featured image. Yet for h-entry, the author specifies a featured image with u-featured, which indicate "a representative photo or image for the entry...."

I think this inconsistency could be confusing for authors.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants