#microformats 2014-07-09

2014-07-09 UTC
KevinMarks joined the channel
#
tantek KartikPrabhu: good to know
emmak, robmorrissey, tantek, KevinMarks2, paintedbicycle and gRegor` joined the channel
#
@prettysam509 I hCard. nt tht I really care. (twitter.com/_/status/486733043580014593)
#
KartikPrabhu what ^
#
tantek as in I hCard therefore I am?
#
kylewm https://twitter.com/prettysam509/status/486733097527148545
#
@prettysam509 i mean heard. (twitter.com/_/status/486733097527148545)
#
tantek wait - did autocorrect type that "hCard" then?!?
robmorrissey, eschnou, KevinMarks2, Soopaman, chiui, Garbee, pfefferle, KartikPrabhu, Atamido and pfefferle_ joined the channel
#
tommorris tantek: I’m not sure there are any use cases for using link elements as u- properties. but we should probably have a formalised discussion on the wiki about it.
#
Loqi tommorris: tantek left you a message 10 hours, 9 minutes ago: what do you think of changing http://microformats.org/wiki/microformats2-parsing##a.u-x[href]%20or%20area.u-x[href] to "a.u-x[href] or area.u-x[href] or link.u-x[href]" ?
#
tantek tommorris - the use-case so far is http://adactio.com/about/myself/ which only contains a logo for adactio in a link element, which could work with u-photo if we put class=h-card on <html>
#
tommorris but in the case of parsing, if it makes sense within the semantics of HTML, I’m not too bothered about there not being strong use cases, so long as one could plausibly use it that way and not break things.
#
tantek "makes sense within the semantics of HTML" is necessary but not sufficient
#
tantek as we deliberately avoid encouraging invisible metadata
#
tantek so for example, microformats2 parsing ignores <meta> elements
#
tommorris so, allow invisible metadata iff compelling use cases can be presented?
#
tantek well, allow *semi*visible data
#
tantek iff etc.
#
tantek the link icon is semi-visible because it shows up in browser UI sometimes, and when a user chooses "Add to Home Page" on a mobile device
#
tantek as opposed to <meta> tags in general which are invisible always or nearly always
#
tommorris my issue is I can’t imagine a scenario where someone would write, say, an hCard that intermixes link elements amongst other properties
#
tantek tommorris <html class="h-card">
#
tommorris HTML LS says that you can use the link element in three context: “where metadata content is expected” (which is?), in a noscript element that is the child of a head element, or something involving microdata/itemprop
#
tommorris tantek: that makes sense
#
tantek someone writes an h-card that *re-uses* not intermixes link elements that already have the content or infomation
#
tommorris so, the use of the <link> element to point to PGP public keys that indieauth is encouraging
#
tommorris <html class="h-card”><head><title class="p-name”>Tom Morris</title><link rel="u-x-gpg-public-key" href=“…" /> etc.
#
tommorris edited /invisible-data-is-considered-harmful (+0) "fix redir" (view diff)
#
tantek right
#
tommorris writes it up for the wiki
#
tantek tommorris - the other aspect that makes me want to fix this (as proposed in the !tell to you above) is that we are already parsing <link> elements for rel values
#
tantek so it's odd to ignore them for properties inside h-* microformats
#
tommorris I think mf2py is just parsing for *[@rel] rather than any particular elements with rels
#
tommorris which is what the spec says.
#
tantek really?
#
tommorris edited /microformats2-parsing-issues (+932) "link elements and u- parsing question" (view diff)
#
tantek spec says "to parse a hyperlink element for rel microformats:"
#
tantek not "all" elements
#
tantek http://microformats.org/wiki/microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats
#
tommorris well, the Talmudic scholar will respond: what counts as a hyperlink element?
#
tommorris just <a> or <area> and <link>? ;-)
#
tantek tommorris: you added a new issue to the resolved section
#
tantek :P
#
tommorris heh, not enough caffeine.
#
tantek serves the Talmudic scholar appropriately
#
tantek ;)
#
tommorris edited /microformats2-parsing-issues (+1) "moved from resolved to issues" (view diff)
#
tommorris and, yes, the Wikipedia administrator sucks at using wikis.
#
tantek ;)
KevinMarks joined the channel
#
tantek so basically there's the (weak) consistency argument (<link> is parsed for rel, so should also be parsed for u-* properties), and there's the *potential* (strong) real world use case argument (if adactio goes the <html class="h-card"> path and uses <link class=u-logo rel="shortcut icon …" href="…"/> )
#
tantek edited /microformats2-parsing-issues (+485) "/* link elements and u- parsing */ note semi-visible rel=icon link, use code instead of kbd for markup" (view diff)
#
tantek !tell barnabywalters,KartikPrabhu update for your consideration: http://microformats.org/wiki/microformats2-parsing-issues#link_elements_and_u-_parsing
#
Loqi Ok, I'll tell them that when I see them next
#
tantek edited /microformats2-parsing-issues (+69) "/* link elements and u- parsing */ link to specific uf2 rel parsing" (view diff)
adactio and RCheesley_ joined the channel
#
tommorris edited /microformats2-parsing-issues (+143) "/* link elements and u- parsing */ comment" (view diff)
ChiefRA, Soopaman, pfefferle_, adactio_, TallTed, ivc\zz, tobyink, MMN-o, KevinMarks, elux, globbot, danielfilho and edsu joined the channel
#
tommorris mf2py 0.2.1 has been released - https://pypi.python.org/pypi/mf2py/0.2.1
#
tommorris KartikPrabhu et al. ^^
#
@legacypython mf2py 0.2.1: Python Microformats2 parser (twitter.com/_/status/486874797586907137)
#
tommorris "legacy". :)
#
@artwisanggeni #python mf2py 0.2.1: Python Microformats2 parser https://pypi.python.org/pypi/mf2py/0.2.1 (twitter.com/_/status/486875457782951936)
#
tommorris Now worrying about all the other craziness that lurks inside the HTML spec.
paintedbicycle, jgarber, KevinMarks, gRegor`, tantek, Soopaman1, caseorganic, Rastus_Vernon and Exploter joined the channel
#
@rbekgy2y49g6ek @r7L HCalendar (twitter.com/_/status/486932016143679489)
caseorganic, eschnou, jgarber, KevinMarks, robmorrissey, KevinMarks_, Garbee and KartikPrabhu joined the channel
#
Loqi KartikPrabhu: tantek left you a message 9 hours, 48 minutes ago: update for your consideration: http://microformats.org/wiki/microformats2-parsing-issues#link_elements_and_u-_parsing
Soopaman, dwayhs, paintedbicycle, KevinMarks and robmorrissey joined the channel
#
@tezgu8j_kf6cd1 @r7L HCalendar (twitter.com/_/status/486987646447542272)
Rastus_Vernon, KartikPrabhu and tantek joined the channel
#
kp edited /microformats2-parsing-issues (+153) "/* link elements and u- parsing */" (view diff)
#
KartikPrabhu tantek: re link elements question: http://microformats.org/wiki/microformats2-parsing-issues#link_elements_and_u-_parsing
#
tantek KartikPrabhu: re: should the door be opened to hidden mf data? note that the door is *already* open to <link> via rel parsing, and the <link>s we're talking about are all semi-visible, not completely hidden
#
tantek (some of that is in the issue text)
#
KartikPrabhu yes... but nothing stops people from using it for any <link>
#
KartikPrabhu best practice would be to restrict to semi-visible ones
#
KartikPrabhu in any case my point being, that if there are enough use-cases then it can easily be added
#
tantek KartikPrabhu: when you say " from using it for any <link> " - can you give specific examples that you're concerned about?
#
tantek I'd rather not add any special casing - to keep the model simpler / more predictable (to authors and parser developers)
#
KartikPrabhu agreed
#
tantek in fact, that desire for a simpler model is what's driving the "weak" argument of consistency with "rel" parsing
#
tantek why should <link> *only* be parsed for "rel"?
#
KartikPrabhu hmm fair enough
#
tantek why should <link rel="in-reply-to"> work but not <link class="u-in-reply-to"> (presumably inside an <html class="h-entry"> on a post permalink page) ?
#
KartikPrabhu it is true that if people want to put hidden data they can already do so
#
tantek again - can you provide a specific real world <link> hidden data example that you're concerned about?
#
KartikPrabhu tantek: it seems any example I can think of can use a rel instead of u-* so it won't be a valid example
#
KartikPrabhu so now I agree that <link rel> and <link class=u-*> should be on the same footing
KevinMarks joined the channel
#
tantek ok just waiting on barnabywalters' opinion then
#
tantek KartikPrabhu: perhaps update your comment on the issue then
#
KartikPrabhu aah yes. on it
#
kp edited /microformats2-parsing-issues (+266) "/* link elements and u- parsing */ added in favour" (view diff)
#
tantek KevinMarks: would appreciate your feedback and analysis of this too: http://microformats.org/wiki/microformats2-parsing-issues#link_elements_and_u-_parsing
#
KevinMarks hm. That is tricky as it is a tension between DRY and invisible metadata
#
tantek KevinMarks: see detail about semi-visible rather than invisible
#
tantek <link rel=icon> is not truly invisible - it's semi-visible
#
KevinMarks historically we've eschewed link-rel form some things (tags) and not others. If you allow link-rel allowing u-* on a link makes sense, though there may be containment issues wiht parsers
#
KevinMarks do you put the h-* on the <head>? or the <html>?
#
KartikPrabhu KevinMarks: that just decides the scope of the h-*
#
tantek KevinMarks: we don't disallow h-* on <head> or <html> right now - it's just that no one is doing it. (as in current parsers support it on both)
#
KartikPrabhu tantek: i think barnabywalters uses h-* on html
#
tantek I see <html class="h-*"> applying to currently published markup use-cases
#
tantek I don't see <head class="h-*"> applying to any currently real world markup use-cases.