#microformats 2017-12-17

2017-12-17 UTC
gRegorLove, tantek, KartikPrabhu, [miklb], webchat8, [pfefferle], nitot, [mlopatka], [kevinmarks], tracya, ChanServ, webchat64 and [eddie] joined the channel; webchat8 and gadz00x left the channel
#
gRegorLove https://github.com/microformats/microformats2-parsing/issues/11#issuecomment-352281134 I also noticed when I run just the hfeed element through php-mf2 it parses the entry-title and entry-content without an intervening hentry class
#
Loqi [sknebel] We just encountered this difference in handling between `mf2py` and `php-mf2` while trying to help debug Bridgy on a WordPress site with the following structure: ```html <body class="h-entry"> <div id="page" class="hfeed site wrap"> <h1 cla...
#
gRegorLove https://php.microformats.io/?id=20171217210155122
#
sknebel oh, so it applies backcompat of *all* mf1 properties, even if they do not match the type?
#
sknebel (mf2py on the other hand adds mf2 properties to the mf1 root, which is also wrong (haven't filed it yet))
#
gRegorLove No, it shouldn't, in general. I don't think I've done much testing with hfeed in the (newer) backcompat in php-mf2 though.
#
gRegorLove But I did set up some tests for other mf1 properties inside mf2 (h-review, I think, aaronpk's examples) and ensured they weren't being upgraded.
chrisaldrich joined the channel
#
gRegorLove This test, for example: https://github.com/indieweb/php-mf2/blob/master/tests/Mf2/ClassicMicroformatsTest.php#L660
#
gRegorLove The assertions that follow that line
#
@ChrisAldrich @TracyAltheide Looks like maybe your microformats markup isn't quite right for use with Brid.gy publish I'm guessing? https://brid.gy/about#microformats (twitter.com/_/status/942505006518939648)
#
Zegnat Wasn’t there a repo with only tests? Does that have anything addressing the mf1 and mf2 mix?
#
sknebel if I remember right, that mostly supports our interpretation, and partly directly goes against the spec
#
sknebel (see case C in first post of #11)
#
Zegnat Does the spec list what the backcompat classes are anyway? I see a link to implementations but not to a list on the wiki
#
sknebel https://github.com/microformats/tests/tree/master/tests/microformats-mixed
#
gRegorLove backcompat classes are usually on the mf2 root class pages like /h-entry
#
gRegorLove They're listed in php-mf2 and mf2py as well
#
gRegorLove Hmm, this hfeed example maybe isn't great.
#
gRegorLove Seems it should basically have an empty 'properties' in the parsed results.
#
gRegorLove Because "Imply properties only on explicit h-x class name root microformat element (no backcompat roots)"
#
Zegnat http://microformats.org/wiki/microformats2#v2_vocabularies - seems to have the list per mf2 h-x root
#
Loqi microformats2
#
Zegnat gRegorLove, the hfeed in the new example in the issue? Yes, should be empty. It might not be a great example because of that, but it is also a real world example of code the parsers encountered today
#
gRegorLove Yeah, filing it currently
#
gRegorLove https://github.com/indieweb/php-mf2/issues/137
#
Loqi [gRegorLove] #137 Fix backcompat hfeed parsing
#
Zegnat The problem I see with no clear authoritative list of backcompat classes in the parsing spec is if parsers do not use the same list.
#
Zegnat <div class="h-entry"><div class="hwhome"><h1 class="p-name">Hi!</h1></div></div>
#
Zegnat If one parser has `hwhome` as backcompat class, p-name should be discarded. If another parser lacks `hwhome` as backcompat class, p-name will be applied to h-entry because there is no root in between.
#
Zegnat goes to make a note of that in a GitHub issue
#
gRegorLove I think they're clear, e.g. http://microformats.org/wiki/h-entry#Backward_Compatibility
#
Loqi [Tantek Çelik] h-entry is a simple, open format for episodic or datestamped content on the web. h-entry is often used with content intended to be syndicated, e.g. blog posts. h-entry is one of several open microformat standards suitable for embedding data in HTML. ...
#
gRegorLove I used that and http://microformats.org/wiki/h-review#Backward_Compatibility with the php-mf2 backcompat upgrades.
#
Loqi h-review
#
Zegnat Then you still need an official list somewhere of all h-*, right?
#
Zegnat From http://microformats.org/wiki/microformats2-parsing I can develop a complete parser, because vocab is not important for mf2. Except that it never tells me when I need to go into backcompat mode.
#
Loqi [Tantek Çelik] microformats2 parsing specification
#
sknebel Zegnat: http://microformats.org/wiki/microformats2#v2_vocabularies I'd assume. I believe they cover mf1, thus there so no new ones relevant to backcompat appearing
#
Loqi microformats2
#
sknebel (?)
#
Zegnat That’s my assumption sknebel. But I would like the parsing spec to refer to it
#
gRegorLove http://microformats.org/wiki/microformats2-parsing-faq#which_backcompat_root_classes
#
Loqi microformats2-parsing-faq
#
gRegorLove Agreed, it would probably be better in the spec. Easier to keep up to date, too.
#
Zegnat Aah, good catch on the FAQ. Adding to the issue I was writing up
#
Zegnat alright, I think this is clear https://github.com/microformats/microformats2-parsing/issues/13
#
Loqi [Zegnat] #13 Specify the authoritative list of backcompat classes within parsing spec.
#
Zegnat What is the actual policy for changing the microformats2-parsing page on the wiki? Is there voting? Is it all up to the spec editor?
#
gRegorLove http://microformats.org/wiki/microformats2-parsing#change_control
#
Loqi [Tantek Çelik] microformats2 parsing specification
KartikPrabhu joined the channel
#
Zegnat So basically get 2 implementations on board after filling the GitHub issue?
Loqi joined the channel
#
gRegorLove Fixing this hfeed example is going to be difficult. I think I ran into this during my backcompat upgrade and just punted on it. To do it properly, need to distinguish between mf1 properties being upgraded to mf2, and mf2 that was explicitly written inside an mf1 root.
#
gRegorLove If .hentry > .p-name is authored, I don't think it should be parsed
#
gRegorLove But .hentry > .entry-title, that should be upgraded to p-name and parsed as mf2
#
aaronpk I thought that's already how it was supposed to work, is it not?
#
gRegorLove That's the specification, yes. php-mf2 doesn't handle the first example
#
gRegorLove I don't think it causes many problems, so it's kind of lower priority.
#
sknebel has the reasoning behind allowing mf1 inside mf2 been documented? in both examples I cite in #11, completely ignoring the nested mf1 would have produced the result the author intended
[pfefferle] joined the channel
#
sknebel and I can personally see an argument of "if you upgrade to mf2, do it for the entire object please", but I wouldn't be surprised if there was a specific example where allowing it was useful too
#
gRegorLove Not sure where offhand, though probably some discussion in issues on http://microformats.org/wiki/microformats2-parsing-issues
#
Loqi microformats2-parsing-issues
#
sknebel didn't find any for this specifically
#
Zegnat Only thing I found was http://microformats.org/wiki/microformats2#backward_compatible - which was to support mf1 while work on mf2 was underway
#
Loqi microformats2
#
gRegorLove It does seem to make upgrading to mf2 an easier process, something you can do piecemeal.
#
sknebel -issues has a few about backcompat, but all about other aspects. and http://microformats.org/wiki/microformats2-parsing-issues#mixture_of_microformats2_and_classic_microformats_classnames_on_different_elements, but that does not have any clear consequence, only a note that the specific wp issue can be fixed
#
gRegorLove WordPress themes being a big exception, though, since they didn't all seem to apply mf1 correctly.
#
Loqi microformats2-parsing-issues
#
sknebel yeah, I haven't done any such upgrade
#
gRegorLove Might have found an easy fix
#
gRegorLove parseH() has a flag indicating if it's in backcompat and there's an object of upgraded elements, so should be able to add some conditional checks
#
gRegorLove Woo, works with the hfeed example. Now let's see if it passes the rest of the tests :)
#
sknebel so you think bringing the parsers to match the current spec makes more sense than changing it?
#
sknebel or for the property-mapping thing?
#
GWG I code specifically for the WordPress issue in my code. I felt I had to, for obvious reasons.
#
gRegorLove sknebel: I need to re-read #11. This is kind of related, but not sure it resolves that or not (in php-mf2)
#
gRegorLove Out of curiosity I took just the hfeed element from #11 to see how it parsed, then realized it wasn't correct.
#
sknebel ah, ok
#
gRegorLove I still think 1A for the first example in that issue
#
gRegorLove And yeah, 1A for the second example
#
sknebel from the spec yes, I'm starting to wonder if the spec should say B instead
#
sknebel no use investing time to bring the parsers to match a spec we're not convinced is good
#
gRegorLove Not opposed to that, but seems like a bit spec change. Not sure what all it would impact.
#
gRegorLove *big
#
gRegorLove One of the examples is under our control since it's indieweb, and the other seems to be a really messed up WP theme
#
sknebel yeah, that's why I've been asking for background info. it seems like a good idea, but big change as well
#
Zegnat You would need to take something like snarfed’s data and see how mf1 vs mf2 is used in the set, possibly. To get more real world examples.
#
Zegnat No matter how many edge cases we can think of, or how neat the mf2 is we all write, if you want to modify backcompat in the spec you don’t want to break the legacy sites it is currently supporting.