#aaronpkhas this really not come up before? anyone using granary who's publishing photos as a separate mf2 property and not including the image inside the html content would be hitting this case
KartikPrabhu joined the channel
#snarfedi guess it hasn't? honestly that's pretty specific
#snarfedagain, i'm happy to make any change we decide on. it just sounded like consensus was still kinda weak
#aaronpkwell i'm struggling to find a case when including the img inside the atom content is the wrong thing to do
#aaronpki mean unless it's in the content already obviously
[miklb] joined the channel
#aaronpkRSS an Atom consumers don't currently look for a separate property for the image, so they will not show the image unless it's in the content
#aaronpki also remember dealing with this issue when writing Monocle
#aaronpkmy alternate solution is looking really grim, which is to move the e-content class to encompass everything in the post including a lot of the metadata
#aaronpki guess i have another solution which is to move the photo in my posts inside the div with e-content. although i'm not sure if that's going to have any effects on how my CSS is applied
#snarfedi'll look into how easily it would be to de-dupe
#aaronpkin related news, my HWC project tonight was a complete fail ?
#KartikPrabhuI put my u-photos inside <content> for Atom
#aaronpkthis was a huge annoyance when I was writing monocle
#aaronpkif the photo is in the content, then there shouldn't be a need to mark it up with u-photo, cause if you do then the photo appears twice in the h-entry
#[tantek]This "appears twice" makes lots of implementation assumptions
#[tantek]That was back before post type discovery was as advanced as it is now
#[tantek]Now there are more options for readers to be smarter in a predictable way
#aaronpki mean it's literally duplicated in the parsed mf2
#aaronpki don't think it's a good idea to require HTML parsing in order to consume mf2 data since the HTML should have all been converted to a data structure during the parsing stage
#[tantek]I don't understand that conclusion either
#[tantek]I think you need to write up what the actual problem is. This is getting super abstract with lots of implementation assumptions.
#[tantek]Actual problem meaning user facing problem
#[tantek]I have a feeling one possible actual problem is trying to present photo plus caption consistently in a reader
#[tantek]For which we could look at combinations of prior art, e.g. Flickr atom feed plus rss/atom reader - how do they make that work?
#[tantek](Why discussing / documenting "actual" user facing problems are a more effective way to solve this kind of thing, the specifics allow us to look for existing attempts to solve similar problems analyze them)
#[tantek](From a UX / publishing & consuming user flow perspective, instead of being limited by reasoning about plumbing details)
snarfed, jjuran, loicm and j12t joined the channel
barpthewire, jjuran, j12t, [tantek], jeremycherfas, davidmead, [kevinmarks] and mblaney joined the channel
#mblaneyaaronpk if it helps with your reasoning, you don't need to parse the HTML in this case, just check for the existence of the u-photo string in the e-content... not much of a loophole but maybe enough...
j12t joined the channel
#mblaneyand I agree that u-photo should be 'flattened' into the content for RSS/Atom, my thinking is that microformats provides the richer vocabulary, and moving to older formats requires simplification. I have the same problem trying to fit h-card into available author fields in SimplePie.
#sebselI have the same problem as aaronpk with u-photo's in e-content and CSS... But I am not going to put my u-photo inside the e-content for now. I agree that it feels wrong.
j12t joined the channel
#mblaneysebsel yes I agree but that's why RSS/Atom should be converting it.
#petermolnarmblaney u-photo should not be flattened that way
#mblaneypetermolnar that's the question I guess, do you try and keep semantics somehow related or just simplify it. The answer might also depend on how well enclosures are supported.
#petermolnarunless you're on some truly ancient feed reader, you shouldn't worry about that
#sknebeldisplays differently though, at least in some readers
#sknebel(and I'Ve even have examples of the exact same duplication issue: image added to post content and as an enclosure -> shows up twice)
#mblaneyyou might have to worry about the media type in the enclosure? I haven't heard of images in enclosures.
#mblaneypetermolnar I think that's a great way to go for converting u-photo to Atom then. (I notice RSS won't work as it requires one enclosure per item, but that's ok.)
#Zegnatmblaney where is it specified that you can only have 1 enclosure per item?
#ZegnatIs it assumed that you can only have 1 if they don’t specify it?
#ZegnatAsking mostly because I seem to recall back in the day Google Reader had no problems with RSS with multiple enclosures
eli_oat joined the channel
#mblaneyyeah even that link says it's common to have more than one, then goes on to not recommend it...
#mblaneyso I think it's more just dealing with history and providing minimal support.
#ZegnatUpon further reading, yeah, it seems enclosure is for just 1 thing. If you really MUST adhere to that, you can always go with something like http://www.rssboard.org/media-rss to have multiple images included
Defenestrate joined the channel
#mblaneythis has given me a lot to think about. I'm now wondering how most readers would display images in an enclosure.
#mblaneyI subscribed to your photo feed in feedly petermolnar, it put the photo at the top of the entry, looked fine. wouldn't know it wasn't part of the content.
#sknebelin inoreader it puts it below, but still fine