#microformats 2014-12-30

2014-12-30 UTC
KartikPrabhu, gRegor` and tantek joined the channel
#
tantek edited /microformats2-parsing-issues (+1066) "/* issues */ resolve one implied property issue, and add another about implied properties on backcompat parsing unlikely to be intended" (view diff)
#
tantek !tell KartikPrabhu, kylewm, barnabywalters, tommorris I've added/resolved a couple of microformats2 parsing issues, please review and comment so I can close and update parsing spec accordingly: http://microformats.org/wiki/microformats2-parsing-issues#implied_properties_on_backcompat_parsing_unlikely_to_be_intended
#
Loqi Ok, I'll tell them that when I see them next
#
KartikPrabhu tantek: examples of such unintended implied property parsing would be good, to see what we are dealing with
#
Loqi KartikPrabhu: tantek left you a message 1 minute ago: I've added/resolved a couple of microformats2 parsing issues, please review and comment so I can close and update parsing spec accordingly: http://microformats.org/wiki/microformats2-parsing-issues#implied_properties_on_backcompat_parsing_unlikely_to_be_intended
#
tantek KartikPrabhu: ah - I should link to the indiewebcamp h-entry page
#
tantek edited /microformats2-parsing-issues (+90) "/* implied properties on backcompat parsing unlikely to be intended */ add examples citation" (view diff)
#
tantek KartikPrabhu: done
#
tantek I presumed you were following the discussion in #indiewebcamp about aaronpk complaining about all the "fixing" his code has to do for bad h-entrys which turned out to be bad hentrys
KartikPrabhu joined the channel
#
tantek KartikPrabhu: ^^^
#
kylewm I wonder if there is code out there that assume the implied properties are always available
#
Loqi kylewm: tantek left you a message 17 minutes ago: I've added/resolved a couple of microformats2 parsing issues, please review and comment so I can close and update parsing spec accordingly: http://microformats.org/wiki/microformats2-parsing-issues#implied_properties_on_backcompat_parsing_unlikely_to_be_intended
#
kylewm I think I have written some actually
#
tantek that seems like an easy patch
#
kylewm definitely, actually the implied properties make a lot more sense to me now
#
kylewm they're there for the convenience of the publisher, not the consumer
#
tantek right
#
kylewm i thought it was the other way around originally
#
kylewm tantek: is it valuable to comment on the wiki if i am just +1'ing your proposal?
#
tantek it is absolutely. readings/reviews are greatly valuable.
#
KartikPrabhu oh interesting the implied name seems to be the main culprit so far... would be interesting to tackle this
#
tantek precisely - and I'm not seeing any value from the implied URL or photo for classic microformats, and since such implying didn't originally exist for classic microformats, it seems the conservative (lease surprise) thing to do is to not imply anything for any classic microformats
#
tantek that is the burden of proof is demonstrate use-cases / real world examples of *existing* classic microformats markup that benefits from implying anything - as any *new* markup would simply be done with microformats2
#
tantek thus the default path (lack evidence either way) would be to drop implying for classic microformats
Atamido_ joined the channel
#
kylewm edited /microformats2-parsing-issues (+238) "/* implied properties on backcompat parsing unlikely to be intended */" (view diff)
Garbee joined the channel
#
tantek thanks kylewm. hoping for confirmation from at least one more parser developer and then I'm happy to make the change (but be open to others raising exceptions if they think of any)
#
KartikPrabhu tantek: I am assuming it is better to have consumers not get an implied property and do their own fallbacks instead of giving "false positives"?
#
tantek rather, the occurance of implied property false positivies is likely to approach 100% for classic microformats
#
KartikPrabhu yes
#
kylewm the second proposal is a little more radical isn't it? http://microformats.org/wiki/microformats2-parsing-issues#implied_properties_when_an_explicit_class_is_provided
#
kylewm I'm thinking like <a class="h-card" href="http://example.com"><img class="u-photo" src="http://example.com/logo.png"/> Example User</a>
#
kylewm oh wait, I get it
#
kylewm tantek: could you change "elements that have explicit class property names" to "nested elements ..." so there is no confusion about e.g. <a class="p-author h-card" href="http://example.com">Example User</a>
#
tantek ah, would "child elements" be enough to cover this?
#
kylewm oh, yes? I don't know the semantic difference between nested and child in this case
#
tantek child implies one level of depth
#
tantek either way it's going to be a summary of what the parsing algorithm specifically says
#
tantek which currently uses CSS selector syntax to illustrate how to find elements to imply properties from
#
tantek I plan to add to those some form of :not(.p-*,.u-*,.dt-*,.e-*) to indicate that none of those class name matches may occur on elements used to imply properties
#
tantek edited /microformats2-parsing-issues (+56) "/* implied properties when an explicit class is provided */ clarify inside root element" (view diff)
reidab, kez_, eschnou, kez__, KevinMarks_ and KartikPrabhu joined the channel
#
@GulzarHedworth hreview Rich Snippets for your WordPress theme - Yoast (twitter.com/_/status/549862240514363392)
myfreeweb, kez_, KartikPrabhu, eschnou, kez__, TallTed and gRegor` joined the channel
#
@Xclusive_pikin Add Google Rich Snippets to WordPress with Author hReview http://kevineze.com/add-google-rich-snippets-wordpress-author-hreview/?utm_source=ReviveOldPost (twitter.com/_/status/549961144769597440)
#
Phyks how should I consume a h-feed with missing properties ?
#
Phyks for instance if it has no title, is it correct to assume the feed's title is the page title ?
#
Phyks generally speaking, is their an "algorithm" to parse h-feeds / h-entries with not all the properties filled ?
#
Phyks tantek: for instance, your h-feed has an empty p-name on this page http://tantek.com
#
tantek phyks I thought I'd fixed that
#
tantek oh right - empty - deliberately
#
tantek <span class="p-name"></span>
#
Phyks why ?
#
tantek because I didn't think it needed one
#
Phyks but in this case, if I import your feed in a reader, it won't have any title associated
#
Phyks then, the user will have to manually add one
#
Phyks am I wrong ?
#
tantek don't know - depends on the reader
#
tantek so many legacy readers are so broken in so many ways that I've mostly given up on them
#
tantek these days people's actual "feeds" that people "use" have no feed name
#
tantek e.g. your Twitter profile has no feed name
#
tantek your Facebook profile has no feed name
#
tantek the whole notion of "requiring" a feed name is obsolete
#
tantek and antiquated
#
Phyks but a standard RSS / ATOM feed has one
#
tantek right, antiquated legacy
#
Phyks I'm thinking of h-feeds more like rss feeds than new silos' feeds
#
tantek popular "feeds" from a UI perspective no longer have any name
#
tantek new silo UI matters more than old plumbing requirements
#
Phyks in fact, I'm wondering how to consume properly feeds in my reader
#
tantek people certainly care more about new silo UI than old plumbing
#
tantek by their usage patterns
#
Phyks the user should be able to identify which entry comes from which feed, no ?
#
tantek no - because the notion of a "feed" is now irrelevant. it's just people.
#
tantek from the UI perspective, the separate notion of a "feed" is dead
#
tantek you follow people, not feeds
#
Phyks true…
#
tantek hence drop the RSS / Atom assumptions
#
tantek they're obsolete
#
Phyks so you think I should present the feed via an associated author and not an associated title ?
#
tantek right
#
Phyks but same thing for author, it is not always associated to feed, I think
#
tantek that would be following the successful UI model that silos have paved
#
Phyks (because AFAIK no properties are mandatory in h-feeds)
#
tantek correct - no properties are mandatory
#
tantek by design
#
tantek you can't require publishers to publish something they don't want to
#
tantek the entire methodology of requiring any properties is flawed
#
Phyks but one should be able to rely on some properties for consumption, no ?
#
tantek no - it's an unreasonable expectation of a publisher to *rely* on any property.
#
tantek corrolary - consuming code MUST handle any missing property in some intelligent way for its user interface.
KartikPrabhu, KevinMarks_, Erkan_Yilmaz, eschnou, TallTed and tantek joined the channel