[tantek]In some ways it is better to *not* have a broken out of date parser out there that someone might try using and see fail on current published microformats2
[tantek]It's perhaps a good example/lesson about projects that only have a single primary contributor, who isn't personally dependent on the project themselves (selfdogfooding).
[tantek]Including the question Zegnat implied about is it callable from within modern webextensions
j12t, jgmac1106_, [cleverdevil], jackjamieson, [adamprocter], metbril, gRegorLove, [jgmac1106], [pfefferle], [chrisaldrich] and barnabywalters joined the channel
sknebelI have a question about backcompat wording: on /h-card it says " author - including compat root vcard in the absence of h-card" - does that mean the parser should treat it as if there was a vcard, even if there isn't?
sknebelbut if it weren't and there's only the name (e.g. <span class="author">name lastname</span>), pretending there is a vcard class too makes the output worse
gRegorLoveInteresting. Looks like both PHP and Python parsers treat it as if adding an explicit h-card to the classes, then parse it, so they get the implied name.
sknebelI guess in edge cases one might be able to find a url too when implying, but since it was intentionally choosen to not do implied properties for backcompat there's also good reasons not to
[tantek], [Vincent], [eddie], [jgmac1106], [cleverdevil], jgmac1106 and [matpacker] joined the channel
[tantek]"compat root vcard in the absence of h-card" means if there is no h-card, then explicitly look for the presence of "vcard" for backcompat parsing of a nested hCard
[tantek]sknebel it sounds like this (https://github.com/microformats/h-entry/issues/13) is an editorial issue. It appears you found a way to misinterpret the current spec text, so we should change it to avoid that misinterpretation. Nowhere in there does it say anything about implying a vcard
[kevinmarks]In mf1 we did define explicit embedded formats in a few places (which was part of the single vocabulary idea, and mirrored existing nesting in some of the older fonts we were basing them on)
sknebelso just to be 100%: <div class="hentry"><span class="author">Max Mustermann</span></div> should return an author property with the value ["Max Mustermann"], not a nested object?
sknebelhm, from a quick skim of the translation lists there's a few more instances: hreview reviewer, hresume contact and hresume education (with vevent instead of vcard) - I guess they can all follow that principle, if the latter two even have any practical relevance still
sknebelfor general wording, I'll reread the spec and my GH issue again when I'm fully awake and see if I can come up with a short clarification note to add somewhere, given that 3 parsers are adding roots where they shouldn't
@FirefoxCommit Mark Banner - Remove unused microformats code. r=Gijs - https://bugzilla.mozilla.org/1503674... http://deb.li/zDv0 (twitter.com/_/status/1074600218266607616)
sknebel oh, I already had opened an issue for that :D https://github.com/microformats/h-entry/issues/13
gRegorLove Interesting. Looks like both PHP and Python parsers treat it as if adding an explicit h-card to the classes, then parse it, so they get the implied name.
[tantek] sknebel it sounds like this (https://github.com/microformats/h-entry/issues/13) is an editorial issue. It appears you found a way to misinterpret the current spec text, so we should change it to avoid that misinterpretation. Nowhere in there does it say anything about implying a vcard
[kevinmarks] In mf1 we did define explicit embedded formats in a few places (which was part of the single vocabulary idea, and mirrored existing nesting in some of the older fonts we were basing them on)