microformats
E-Content Overlaps with u-photo and similar properties
This issue is being opened to deal with the conflict between e-content and the draft u-photo property as well as the u-video/u-audio properties as all three have this similar issue. A proposed solution must be derived prior to any of the three reaching stable status.
Summary of Issue: u-audio, u-video, and u-photo all reflect that one of more audio, video, or photo urls is the primary content of the entry. Separately, it is a not uncommon scenario that img, video, or audio tags are present in the e-content, either marked up with microformats or not. This creates a possible duplication issue for those consuming parser output.
Some of this issue was previously discussed in https://github.com/aaronpk/XRay/issues/52, specifically how parsers will consider an img tag inside e-content as an implied photo. This is a problem for resolving this. Currently, the parsing specification does not do the same for implied video or implied audio properties.
To address publishing examples of how people use u-photo vs. e-content:
- u-photo(s) inside e-content e.g. @kartikprabhu @tantek
- u-photo(s) as a sibling to e-content - with separate img tags for each
- u-photo(s) as a sibling to e-content - only img tag for u-photo, no img tag in e-content e.g. @dshanske
- u-photo(s) mixing with an article (non-empty p-name) <-- we consider this an erroneous use of u-photo as this is a pattern often used by people who believe u-photo is to be placed on all img tags. (In this case, the question was raised of whether or not this would reflect a photo with a name, e.g. like a flickr photo?)
The questions raised by this is whether these versions are meant to be interpreted differently and how to interpret them, what should be the recommended way, if any, to address this.
I’ve been posting img.u-photo inside .e-content for years for a variety of reasons:
- I want e-content to contain the entire content of my posts, so that consumers which don’t have special support for .u-photo, any of the other “primary content” u-* properties (video, audio etc) don’t just show a meaningless caption
- I don’t want to build a separate posting UI for photos, with the additional complication of adding caption content and alt text to each individual photo.
- I use bridgy for POSSE syndication, and it looks for .u-photo when determining which image(s) to attach to the POSSEd copy, even when .u-featured (a proposed property) might be more appropriate
Personally I feel like the first reason alone is compelling enough to support .u-photo inside .e-content.
(Also relevant to #24)
@barnabywalters just fyi Bridgy Publish supports u-featured! Not documented right now, but I should add it. Thanks for the nudge.
@snarfed thanks! For my usage so far, u-photo has been more appropriate anyway, but good to know that it would also work for e.g. an article with a representative photo