#CalliI have my own perspective on implied props: I'm afraid I'm not a fan overall and I haven't implemented them yet. Will be last thing I implement if at all.
#CalliOne reason for reluctance is that I'm looking at mem-constrained environment and I want to dump all unecessary data as soon as possible
#tantekCalli - they are part of the tradeoff of a huge simplification for many 90% plus simple cases for publishers with a little bit of work on the part of parsers
#Callithe Implied name property in particular looks like it could be pretty large since it will often be text content
#tantekit's simple economics math of lowering barriers for accuracy and work for publishers (across millions) vs. a bit of work for a handful of parser devs
#tantekCalli - if you have specific examples where implied name causes a problem, please share them!
#tantekwe are actively looking into documenting and solving any such problems
#tantekbut they must be based in real world examples
#CalliMust admit I have assumed this is from implied name - haven't researched to see if it's another issue
#CalliYou may well be right about the simplification, but I am still in process of convincing myself of that. It's clear that the markup is simplified. It's not yet clear to me that the mental model for authoring is simplified or that maintenance of markup is simplified. I don't have firm conclusions at this point.
#tantekthe simplification was driven specifically by web developer / designer feedback about classic mf1 markup which required explicit markup for names, urls, photos which were so common, and seemed to always require adding extra markup
#tantekand the response to the mf2 solutions from the web design / development community has been very positive
#tanteksome of that history has been documented on the wiki on the /microformats2 page
#CalliSounds good. It's definitely an alternative to microdata and json that don't have implied props.
#tantekindeed - the same web developers were very confused as to why microdata/rdfa/json would come up with even more wordy approaches than classic mf1
#tantekI mean unless you truly believe there is some ecosystem benefit to the microdata/rdfa/json approaches
#tantek(ecosystem, as in not just "it makes parsing easier")
#CalliI believe it's a trade-off. I like "easy-to-parse", but I like "easy to explain", "easy to understand", "easy to write", and "easy to read" way more.
#CalliThere's often trade-offs between easy-to-write and easy-to-read. It feels like microdata and microformats have different opinions about the relative importance of those.
gordonb and hober joined the channel
#CalliAnyway, it's probably clear, but I'm all for limiting the appearance of implied props so proposal to prevent an element that already has a use from contributing to implied prop sounds good. This change would mean that a different element could then provide the implied value though right?
#CalliThe change is not just that an implied prop would be suppressed in some additional cases, but that it could actually get a different value?
#tantekI'm not sure that's a good (easily predictable) result
#tantekI would prefer a more conservative approach, and that is that if the first element found (per the parsing spec) that could/should provide an implied property is suppressed by this new rule (by another explicit property of the same *- prefix on that element), then there is nothing implied for that property
#tantekrather than some sort of weird fallback to another element
#tantekand provides an obvious encouragement for the publisher to be explicit in those cases (which I expect to the be the rare exception, not the 90%, and thus it makes sense to ask the publisher to be explicit)
#CalliI might be wrong - maybe the only-of-type requirement prevents what I suggested