jmacI find that if I expand that attribute to e.g. class="u-in-reply-to h-cite p-name p-foo p-bar p-baz", then this parser happily creates and files an identical h-cite item under each of those p- and u- property names
[tantek]the *only* use for putting a property class name and a root class name on the same element is to *embed* that root class name microformat as a nested object value on that property which itself is inside its own microformat root class name higher up the document hierarchy
[tantek]the example code you gave, class="u-in-reply-to h-cite p-name p-foo p-bar p-baz", illustrates this distinction (properties applying to ancestor root elements vs erroneous attempt by author to make properties apply to the element itself
[tantek]the rest of the properties are clearly intended by the author to apply to the h-cite itself and thus MUST be on an element *inside*, not on the same element
jmac[tantek]: I get it, and thank you! My question is purely mechanical: What should my parser do when confronted with some likely-erroneous garbage like that.
jmacAnd because it's so weird, it's both not in the official MF2 test docs (as of last summer), and had never come up for me in the wild before yesterday
jmacSo I'm currently aiming to have it replicate what the official PHP parser does (https://php.microformats.io/?id=20190606030911222), just rubber-stamping the same h-format item repeatedly under different property names
sknebelwhat would be less stupid in your opinion? it applies the same rule for nested objects than for plain properties, that feels consistent to me, even if it doesn't come up often
jmacI just meant that the input is probably erroneous but of course it's the parser's job to handle it gracefully and consistently even if the output is a bit strange. :) That's my only goal
jmacTo be clear, I'm not running these tests through PHPUnit or whatnot; I've been using them strictly as HTML/JSON textfiles that my own parser uses for input & expected output, respectively
jmacAnd when I was building my parser last year, I *did* find a number of inconsistencies in some tests, and I worked em out with y'all! This included my pushing up at least one or two pull requests of my own, if I recall correctly. (Which got merged.)
[tantek]I think I want to introduce a class of backcompat changes to parsers that I think will help ignore lots of authoring errors (that otherwise produce noise) in the wild
[tantek]if when / after backcompat parsing a mf1 root, if no properties have been found, uplevel any children microformats, and throw away the mf1 compat structure without any properties
[tantek]so if there was an hentry with no properties except an h-entry inside, the outer hentry would be thrown away, and the nested h-entry would become a top level object
[tantek]if there was an hentry without properties, with an hfeed inside without properties, and then an h-entry inside, the outer hentry and hfeed empty wrappers would get removed, moving the h-entry to the root
ZegnatThis proposal probably would not fix the problem aaronpk is seeing. The backcompat parsed hentry in the theme may very will have a correct mf1 entry-title.
[aaronpk]Zegnat is right, more often I see entry-title and such, but when it's mf1 when there is also mf2 on the page I pretty much want to ignore all mf1 content
ZegnatThat permalink is especially interesting because it does not really have an mf1 hentry at all. The only mention of that class that I see is on an element that also has the mf2 h-entry class, so the hentry will never be parsed
ZegnatYeah. I can’t think of a usecase right away, but need to think a bit. If the author did not mark any explicit properties, and the parser did not find any implied properties, why keep the object at all?
[kevinmarks786]warning about empty objects is good; objects with children but no properties is a bit tricky. In practice we tend to infer an h-feed from multiple h-entry. We do have some empirical backcompat for hfeed that may be tense
[tantek]also what's the downside to a property-less h-feed root collapsing out of existence and leaving the page with a bunch of h-entry objects at the root?
ZegnatMultiple h-feeds could be a problem then, but I guess we’d expect a name/url/uid on the different h-feeds if you have multiple of them on the page, which makes sure they are not collapsed
[schmarty]buuuuut, if an h-feed is defined on (or inside of) an element with an addressable fragment ID on the page, then it *does* have an implied URL.
Zegnatmore specifically, jacky: an h-feed that has no properties but has children would “collapse” in that its children will become children of the object one level higher. Thus if you have two h-feeds without properties on the same level, their respective children will end up as one list of children
ZegnatI for some reason thought root as in root class names (e.g. the “root” as mentioned in current parsing spec), and therefor didn’t understand what you said.
ZegnatBut that would still merge propertyless h-feeds though, right? If the mf2 document has 2 propertyless h-feed objects, both will be collapsed and see their nested objects all move to the same level?
ZegnatThis would be able to fix the empty h-entry > empty hfeed > real h-entry problem that was linked in #indieweb-wordpress; I guess. It would not fix the anomalily rsvp problem as linked by aaronpk.
[tantek]and yet, as you point out, existing mf1 consuming *is* useful, and if those folks started also consuming mf2, they would be greatly surprised to stop seeing even *some* of the mf1 they used to be consuming
[tantek]given the widespread existence / utility of mf1 consuming, I don't want upgrading to mf2 consuming to break that, and the presence of a single h-card (like in a footer) should not break the consuming of a perfectly fine hCalendar vevent for example
[tantek]while that's a theoretical description, it's based on practical data (tons of vevent out there), and a very reasonable change a new person would make to a site (h-card in footer)
[tantek]certainly it would be a *very bad surprise* to the person adding the h-card contact in the footer if it all of a sudden invalidated the vevent on the page
gRegorLove Their reply-context there should probably also be all in one h-cite, instead of one h-cite on the `a` and another on the `div`
jmac Experimenting more with this: https://php.microformats.io/?id=20190606030911222
[tantek] jmac, properties for a microformat must always be *inside* the root class for the microformat http://microformats.org/wiki/faq#Can_you_mix_properties_and_the_root_class_name
Zegnat jmac: how do you handle tests being wrong? E.g. https://github.com/microformats/php-mf2/pull/163#issuecomment-376114735
@cpan_new Web-Microformats2-0.501 by JMAC https://metacpan.org/release/JMAC/Web-Microformats2-0.501 (twitter.com/_/status/1136671244336582656)
@perlnews CPAN: Web-Microformats2-0.501 (JMAC) - https://metacpan.org/release/JMAC/Web-Microformats2-0.501 (twitter.com/_/status/1136671349525499904)
[kevinmarks786] warning about empty objects is good; objects with children but no properties is a bit tricky. In practice we tend to infer an h-feed from multiple h-entry. We do have some empirical backcompat for hfeed that may be tense
jacky because then I would have pointed at https://help.github.com/en/articles/transferring-an-issue-to-another-repository
[schmarty] i think it only becomes an issue when h-feed collapses because it has no properties