#microformats 2015-12-01
2015-12-01 UTC
# 
Calli OK. Need to think about it a bit. Did you consider a broader restriction:
# Calli Presence of any explicitly marked up p- property on the item (not element) prevents implied p- properties Presence of any explicitly marked up u- property on the item (not element) prevents implied u- properties
# Calli These are relevant test cases for whether the implied URL property would get a value from a different element or not:
# Calli ok
# Calli I don't have any uses for area for my interests, I picked a test with A and AREA because of how the spec deals with only-of-type - needed an element that could be used forimplied URL prop that wasn't of the same type as A
# 
kevinmarks the implied name there is from hfeed not h-feed
# kevinmarks so that is a 1->2 mapping bug
gordonb and Calli joined the channel
# Calli oh right - yeah parser bug then
# Calli so i guess I don't know if I'll encounter h-feeds without names in the wild, but if I do...
# kylewm edited /microformats2-parsing-issues (+790) "/* implied properties when an explicit class is provided */ suggestion: split these out per property. I suspect it only affects u-url." (view diff)
# kevinmarks I wonder if implied name should include children or not
# kevinmarks tricky as with h-feed you probably don't want that, but with h-review of an h-card, you may
# kylewm edited /microformats2-parsing-issues (-5) "/* implied properties when an explicit class is provided */ simplify suggested modification to implied url prasing" (view diff)
gordonb and Calli joined the channel
# Calli kylewm makes good points about name and photo in his edit (namely that suggested changes won't really affect name because of the fallback to textContent and changes are possibly counterproductive for photo where it feels like presence of an image even if it's marked with another property is still strong enough evidence that the image is appropriate for the implied photo property)
# Calli which leaves just implied URL
# Calli which then makes me think that for simplicity sticking with existing spec is good enough
# Calli Is it better to provide an incorrect URL or no URL at all? How would an author detect either case? Do any of the parsers focus on authoring scenarios? Do any of them highlight implied properties or missing properties?
# Calli So having considered it, I think I'm in the camp of leave the spec as it is
# Calli I agree - but then my solution would be not to imply URL (or name or photo)
# Calli Seems like you're concerned with the authoring side of things and that's why you've gone for implied properties right? But how would an author be made aware that either they are missing a value for URL where it might be expected or they are getting a value that they might not expect?
# Calli yeah - that is a good rule.
# kevinmarks that is a good rule
# kevinmarks the nesting issue is trickier
# Calli On a related note: When considering parsing spec changes, do you (the community) have a large body of MF2 data that you don't want to change the meaning of? Or are changes still acceptable? If you're trying to avoid radical reinterpretations of existing data, do you have a crawler or some other means of getting hold of it?
Calli joined the channel
# Calli More random thoughts about implied properties: Why doesn't implied name generate text content like an explicit p- property (which does converts imgs to their alt/src attributes insertion)? Is that difference intentional?
# 
@fjdekermadec Nobody cares, but I finally implemented #microformats on the sites of all our clients. 2010 @Google called and they want their index back! (twitter.com/_/status/671525766564347904)
KartikPrabhu and tantek joined the channel
# kevinmarks the large body is probably in brid.gy/webmention.*
andicascadesf, tantek, KartikPrabhu1, nitot, tantek_, adactio, KartikPrabhu, Erkan_Yilmaz, eschnou, TallTed, KevinMarks_, MeanderingCode, KevinMarks, Left_Turn, kevinmarks_, gRegorLove, Calli, KevinMarks__ and kevinmarks joined the channel