#microformats 2015-11-25

2015-11-25 UTC
#
Calli !tell Tantek Is http://glennjones.net/tools/microformats/ a recommended tool to test with?
#
Loqi Calli: tantek left you a message 2 hours, 19 minutes ago: Try constructing some simple span class markup with the tree you gave "vcard" > "adr h-adr" > "p-locality" and using one of the live textarea entry parsers to check! http://microformats.org/wiki/microformats2#Parsers
#
Loqi Ok, I'll tell him that when I see him next
#
tantek indeed!
#
tantek Glennjones's mf2 parser is among the most compliant with the spec
#
Calli Great. Many others are broken or offline.
#
Calli https://pin13.net/mf2/ - Does not exclude new properties from compat items so can't test more advanced examples
#
Calli http://mf2.vendaria.net - Does not seem to support compat so can't test at all
#
Calli https://unrelenting.technology/mf2/ - - Does not seem to support compat so can't test at all
#
Calli http://any23-vm.apache.org/ - dead link
#
Calli So given this: <div class="vcard"><div class="adr h-adr"><div class="locality">MF1</div><div class="p-locality">MF2</div></div></div>
#
tantek Calli - yikes - which ones are broken or offline?
#
Calli Glennjones says: { "items": [{ "type": ["h-card"], "properties": { "adr": [{ "value": "MF1MF2", "type": ["h-adr"], "properties": { "locality": ["MF2"], "name": ["MF1MF2"] } }] } }], "rels": {}, "rel-urls": {} }
#
tantek oh I see
#
tantek aaronpk: re: pin13 - does that need to be updated to a newer version of phpmf2?
#
aaronpk let me check, i thought i had it up to date...
#
tantek hmm who is vendaria.net?
#
aaronpk nope it's got the latest
#
Calli vendaria is andyleap (Go)
#
Calli Try this on pin13: <div class="vcard"><div class="adr"><div class="locality">MF1</div><div class="p-locality">MF2</div></div></div>
#
Calli It picks up both locality and p-locality
#
aaronpk is that this issue? https://github.com/indieweb/php-mf2/issues/45
#
Calli Hard to tell with size of markup in that issue and title leaves room for interpretation. Maybe?
#
aaronpk that is a rather large chunk of markup.
#
aaronpk I *think* it's the same thing? could you add that small example to the issue? that would be helpful
#
Calli I can. Will need to do later (have to signup for Github first).
#
tantek aaronpk - looks realted but not the same - that issue looks like it is about having both *root* class names
#
aaronpk oh, hmm. well, new issue i guess!
#
tantek whereas Calli's example looks like it is bout having both *property* class names
#
tantek I *think* (that's upon quick reading of the issue and example)
#
Calli yes. This is a minimal test: <div class="vcard"><div class="given-name">MF1</div><div class="p-given-name">MF2</div></div>
#
Calli In that test, we expect only an MF1 property to appear in the output
#
Calli The next more complex example is: <div class="vcard"><div class="adr"><div class="locality">MF1</div><div class="p-locality">MF2</div></div></div>
#
Calli Where we've got an extra level of nesting. But still I think we expect only the MF1 property to appear in the output.
#
kevinmarks might be worth adding those to https://github.com/microformats/tests
#
Calli And then we get to the example where I'm not sure the spec is clear about what has to happen: <div class="vcard"><div class="adr h-adr"><div class="locality">MF1</div><div class="p-locality">MF2</div></div></div>
#
tantek kevinmarks - pretty sure that glennjones already has tests in there for those test cases
#
Calli In this case the question is whether the "adr h-adr" element has an MF1 compat context, and MF2 context, or both
#
tantek Calli - in the case of the presence of both roots, the mf2 roots take predence
#
Calli BTW my rejiggered implementation matches the glennjones result: MF2 context turns off the MF1 compat so you only get locality = MF2
#
Calli I don't know if that's right though - so that'smy question
#
tantek ah right - that's the detail of what to do with mf2 roots as properties of classic microformats properties!
#
tantek that is more subtle yes - you are correct to point that out separately
nitot joined the channel
#
Calli So is the feeling that for the "adr h-adr" example that we should only honor the MF2 context. I think it will make my implementation more complex if I need to honor both (while still maintaining the other rules).
#
tantek agreed that trying to honor both inside any object would be more complex
#
tantek and likely cause unexpected results
#
tantek hmm - let's check the microformats2-issues to see if we already captured this or not - thought we had but just to be sure
#
tantek looking at http://microformats.org/wiki/microformats2-parsing-issues
#
tantek Calli - this looks close to your adr h-adr example: http://microformats.org/wiki/microformats2-parsing-issues#uf2_children_inside_a_classic_microformats_root_class_name
#
Calli There is "any h- root class name overrides and stops backcompat root"
#
tantek yes, on that object
#
Calli But it's not clear that it applies when the backcompat is implied by a property rather than explicit
#
tantek Calli - the problem is that in your example, "adr" is BOTH a property for the parent "vcard" AND its own backcompat root
#
tantek that makes it a more interesting example
#
tantek ok I'm pretty sure you've found a case that existing issues have not covered
#
tantek well done!
#
tantek mf2 root directly on a backcompat property element
#
tantek hey kylewm I believe this to be a *different* issue than the one you originally found http://microformats.org/wiki/microformats2-parsing-issues#uf2_children_inside_a_classic_microformats_root_class_name
#
tantek and thus consideration of different treatment
#
tantek Calli, if I understand you correctly, you are proposing that in the "adr h-adr" example, the nested object is parsed as an mf2 h-adr, thus only looking at the p-location, and not the "location" class name
#
tantek that seems reasonable to me and I'd like to document that as a proposed resolution to this issue
#
tantek kylewm, aaronpk, tommorris, FYI ^^^
gordonb joined the channel
#
tantek kylewm: this example in particular: http://logs.glob.uno/?c=freenode%23microformats&s=today#c84632
#
tantek I'll capture it on the wiki
#
tantek Calli, kylewm new issue captured along with proposed resolution on the wiki: http://microformats.org/wiki/microformats2-parsing-issues#uf2_children_on_backcompat_properties
Calli joined the channel
#
kylewm I'm not quite understanding why it is not the same issue
#
kylewm adr gets replace with "p-adr h-adr" but the value is parsed as mf2 object without backcompat
#
kylewm oh i guess the difference is that it isn't just an unmoored child, it has a mf2 property
#
kylewm s/mf2 property/mf1 property
#
Loqi kylewm meant to say: oh i guess the difference is that it isn't just an unmoored child, it has a mf1 property
#
tantek exactly!
nitot joined the channel
#
tantek it does not end up in the children collection
#
kylewm cool
#
kylewm Calli++
#
Loqi Calli has 1 karma
#
tantek Calli++ looks like we have a pretty decent consensus with your proposal, Glenn Jones's implementation, and another implementer (kylewm works on the python mf2 parser)
#
Loqi Calli has 2 karma
#
tantek !tell tommorris, barnabywalters, kevinmarks please see new microformats2 parsing issue and propose resolution - we have a decent consensus, lacking objections I'm going to edit the spec accordingly in the next few days http://microformats.org/wiki/microformats2-parsing-issues#uf2_children_on_backcompat_properties
#
Loqi Ok, I'll tell them that when I see them next
tantek joined the channel
#
Calli I'm happy with the conclusion. thanks all.
#
tantek Calli - please confirm when you've implemented it that way and we can note that in the issue as well
#
tantek and thanks for raising the issue!
tantek joined the channel
#
@sideshowbarker @newtron For rel=preconnect, I think what’s needed is for somebody to move it to either the 1st or 3rd table at http://microformats.org/wiki/existing-rel-values ㏄ @t (twitter.com/_/status/669337257619255296)
Calli joined the channel
#
Calli New test case: <div class="vcard"><div class="adr h-custom"><div class="locality">MF1</div><div class="p-locality">MF2</div></div></div>
#
Calli Never mind.
#
Calli Oh I mean this is interesting
#
Calli Glenn says: "items": [{ "type": ["h-card"], "properties": { "adr": [{ "value": "MF1MF2", "type": ["h-adr", "h-custom"], "properties": { "locality": ["MF2"], "name": ["MF1MF2"] } }] } }]
#
Calli Note that type is h-adr here according to glenn (but not me)
#
tantek Calli I think you are correct per http://microformats.org/wiki/microformats2-parsing-issues#any_h-_root_class_name_overrides_and_stops_backcompat_root
#
tantek wow good catch
#
Calli I think we're saying that the general principle is that if an element has an h- it will never have a compat type no matter where the element appears right?
#
tantek yes that seems consistent, and most predictable
#
tantek Thanks Calli - I've added both second example and parsed results as I think you are concluding: http://microformats.org/wiki/microformats2-parsing-issues#uf2_children_on_backcompat_properties
tantek and nitot joined the channel
#
tantek that is an odd bit of partial REST verbism
#
tantek oops that was meant for #indiewebcamp
hober joined the channel
#
@Web4Panama Ultimate Guide to #Microformats: Reference and Examples http://sixrevisions.com/web-development/ultimate-guide-to-microformats-reference-and-examples/ #SEO #WebDev (twitter.com/_/status/669351573458427904)
#
@newtron @sideshowbarker done! (though i put it in the html5 link type extensions per the instructions) http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions (twitter.com/_/status/669351818674204672)
#
@i0ewx76 RT Web4Panama Ultimate Guide to #Microformats: Reference and Examples http://sixrevisions.com/web-development/ultimate-guide-to-microformats-reference-and-examples/ #SEO #WebDev (twitter.com/_/status/669352557760913408)
Calli joined the channel
#
@newtron Updated http://microformats.org/wiki/existing-rel-values to move preconnect from “brainstorming” to “HTML5 link type extensions”. Take that, https://t.co/9qwKDZt3df! (twitter.com/_/status/669354482023682048)
#
aaronpk Haha what
#
tantek hahah awesome!
#
tantek newtron++
#
Loqi newtron has 1 karma
nitot and Calli joined the channel
#
@mborn319 @newtron Hasn't HTML5 microdata pretty much supplanted microformats? (twitter.com/_/status/669378226368679936)
#
@Web4Panama xtending #HTML5 — #Microformats http://html5doctor.com/microformats/ #WebDev #SEO #Search #SEM (twitter.com/_/status/669379662141906944)
#
@sideshowbarker RT @newtron: Updated http://microformats.org/wiki/existing-rel-values to move preconnect from “brainstorming” to “HTML5 link type extensions”. Take that, https://t.… (twitter.com/_/status/669380293011206144)
#
@graydonald57 RT Web4Panama xtending #HTML5 — #Microformats http://html5doctor.com/microformats/ #WebDev #SEO #Search #SEM (twitter.com/_/status/669383391775744000)
Calli joined the channel
#
Calli Taken from real-world data and condensed: <div class="vcard"><a href="url-value" class="url n">name-value</a></div>
eschnou and nitot joined the channel
#
@jongalloway @kevinmarks @jden415 @t Awesome. I got into microformats in 2006 (a little late to the party), big fan. http://weblogs.asp.net/jongalloway/441290 (twitter.com/_/status/669439014773071872)
hober, nitot, eschnou, Erkan_Yilmaz, andicascadesf, KartikPrabhu, elf-pavlik and TallTed joined the channel
#
@helengregory @hreview Steve Jobs **** An interesting view of this very driven and focused man. Well filmed. Great casting. (twitter.com/_/status/669555009038770184)
tantek, andicascadesf, gRegorLove and Calli joined the channel
#
Calli Going to write a summary of MF2 compat parsing concepts based on yesterdays discussion:
#
Calli Defns: "Compatibility Map" contains all possible mappings from MF1 classes to MF2 classes. It doesn't change.
#
Calli "Compatibility Class Map" maps from MF1 type classes to MF2 type classes. It doesn't change. It's the subset of the Compatibility Map that deals with mapping types.
#
Calli "Compatibility Context" maps from MF1 property classes to MF2 property and type classes. It can be different for each HTML element. It's the relevant subset of the Compatibility Map.
#
Calli "MF1 type classes" are: vcard, hentry, hrecipe, hresume, vevent, hreview, hproduct, hreview-aggregate, hgeo, hadr
#
Calli Every HTML element in the source document _defines_ a Compatibility Context:
#
Calli If the HTML element contains an MF2 type class (prefix h-), it defines an empty Compatibility Context
#
Calli Else if the HTML element contains any MF1 type classes, it defines a Compatibility Context that consists of the union of the compatibility mappings for those types.
#
Calli Otherwise it defines a Compatibility Context that is the same as its parent Compatibility Context.
#
Calli The Compatibility Context is _used_ when examining child elements:
#
Calli The active properties on an element are defined this way:
#
Calli If the Compatibility Context is empty, the properties of the element are the MF2 property classes on that element
#
Calli Otherwise the properties of that element are obtained by mapping the MF1 property classes through the Compatibility Context to obtain MF2 property classes. (In this case, MF2 property classes on the element itself are ignored)
#
Calli The active types on an element are defined this way:
#
Calli If the HTML element contains any MF2 type classes (prefix h-), the active types are exactly those types
#
Calli Otherwise the active types are a union of:
#
Calli 1. MF1 type classes on the element mapped to MF2 type classes through the Compatibility Class Map
#
Calli 2. MF1 property classes on the element mapped to MF2 type classes through the Compatibility Context
#
Calli ...
#
Calli I think that gives results that match the intentions of the spec and covers the cases discussed yesterday
#
Calli The microformats 2 parsing page needs a prominent place for the "Compatibility Map" - it's not possible to produce interoperable MF2 parsers without this map
#
Calli I borrowed mine from another parser and adjusted it to my programming language (C++) and preferences, but it needs to be part of the spec
#
tantek I'm not sure more terminology would help the parsing spec be more understandable
#
tantek I'd prefer to keep the parsing spec very direct in terms of what to do with what inputs
#
tantek rather than introduce more abstractions
#
tantek which tends to *increase* the cognitive load necessary to understand and implement
#
Calli That's OK - I'm not intending my description to be part of the spec; only the compatibility mapping data
#
tantek That being said, I do think you make good points about better documentation about backcompat parsing details
#
Calli Right now spec says have to do backcompat and if you look closely you can find a link to the root class names that apply
#
Calli But need those and the property mappings for the parser to work
#
tantek Calli could you review this? (just added) http://microformats.org/wiki/microformats2-parsing#note_backward_compatibility_details
#
Calli taking a look
#
Calli I believe that to be both correct and helpful
#
Calli To see why mapping matters, can compare this: <div class="hreview"><div class="reviewer"></div></div>
#
Calli on glennjones and pin13
#
tantek ah - are you referring to needing an explicit list of backcompat roots for example?
#
Calli pin13 mapping creates 2 props for reviewer (reviewer and author) glennjones only has reviewer
#
tantek thanks for the review!
#
Calli Yes, explicit list of backcompat roots and explicit list of properties within those roots and how they should be mapped
#
Calli something like https://github.com/tommorris/mf2py/blob/master/mf2py/backcompat.py but without the code
#
Calli and whatever the concensus is on what the actual data should be
#
tantek ok that makes sense. I'm thinking a summary of the backcompat roots would be sufficient for the parsing spec, linked to each of the backcompat properties sections for each root - rather than duplicating
#
Calli I guess the info can be pieced together from http://microformats.org/wiki/microformats2 but that page has a certain amount of discussion and options and inconsistent use of new vs old types
#
tantek agreed - it can be made simpler / easier for implementers
#
Calli Yes, if you want better consistency across implementations and to make life easier for implementers a simple data file would be better
#
tantek thanks for pointing this out - really helps to have a fresh pair of eyes look at it
#
tantek I'm thinking a summary list to start with, and then maybe links to data files of existing parser implementations
#
Calli Glenn's maps can be found by searching for -> modules.maps[' <-- in https://github.com/glennjones/microformat-shiv/blob/master/microformat-shiv.js
#
Calli But they're less explicit than the mf2py one
#
kevinmarks I found the mf2py mapping very clarifying too, I agree we should capture that in a language independent way
#
Loqi kevinmarks: tantek left you a message 17 hours, 10 minutes ago: please see new microformats2 parsing issue and propose resolution - we have a decent consensus, lacking objections I'm going to edit the spec accordingly in the next few days http://microformats.org/wiki/microformats2-parsing-issues#uf2_children_on_backcompat_properties
eschnou joined the channel
#
Calli There's another one if you search --> $classicPropertyMap <-- in https://github.com/indieweb/php-mf2/blob/master/Mf2/Parser.php
#
tantek this is excellent - this way we can hopefully submit pull requests to fix all these to be consistent
#
Calli There aren't that many language-specific extras on the PHP and Python maps so I'd be OK if the spec included a map that actually compiles as code in some language as the core data (rather than language-independent)
#
Calli BTW the https://github.com/G5/microformats2 is no longer maintained according to their GitHub
#
Calli The overall hit-rate on working online MF2 parsers and actively maintained repos for parsers on the wiki isn't super high right now - if you have some preferred implementations and/or parsers that you know are being actively worked on, I'd suggested moving them to the top of the list
#
tantek That's a good point
#
tantek microformatshiv is very active, and mf2py and phpmf2 after that
#
tantek I think the others are more in a "development" phase
#
tantek whereas the first three are all used in production on various sites
#
Calli yeah those three seem good. My rec would be to put links to the most reliable sites with textarea input right at the top of the list, followed by active repos by language, followed by others
#
tantek that's a good reclustering
tantek joined the channel