#microformats 2015-04-22

2015-04-22 UTC
KartikPrabhu, KevinMarks, KevinMarks__ and eschnou joined the channel
#
@ReviewsSatCom 1 star #hughesnet-gen4 review: 8-2p.m.& 2-8a.m. BULL http://satellitecomplaints.com/hughesnet-gen4-internet-reviews/?wpcrp=1#hreview-763 Slow connection. Want allow but one device to connect at a timew (twitter.com/_/status/590758872169771008)
#
@ReviewsSatCom 1 star #hughesnet-gen4 review: WORST Internet ever http://satellitecomplaints.com/hughesnet-gen4-internet-reviews/?wpcrp=1#hreview-762 This has to be the worst internet service on the planet. It's so s (twitter.com/_/status/590758876519276544)
#
@ReviewsSatCom 1 star #exede review: Too expensive for little usage http://satellitecomplaints.com/exede-reviews/?wpcrp=1#hreview-760 my internet service through Excede started horribly on day 1. I (twitter.com/_/status/590758880726122496)
KevinMarks, kez, eschnou, kez_, KevinMarks__, KevinMarks___, chiui, Soopaman, elux, KartikPrabhu, TallTed and AcidNerd joined the channel
#
@ReviewsSatCom 1 star #exede review: No service http://satellitecomplaints.com/exede-reviews/?wpcrp=1#hreview-764 Our service worked fine for the first 3 months and then our modem just stopped worki (twitter.com/_/status/590903932718817281)
#
@ReviewsSatCom 1 star #exede review: Poor Customer Support http://satellitecomplaints.com/exede-reviews/?wpcrp=1#hreview-757 I called "technical support" because I received a warning email, notifyin (twitter.com/_/status/590903936963448833)
KevinMarks, tantek, Soopaman, dariusdunlap_, KevinMarks__, kez, eschnou and KartikPrabhu joined the channel
#
tantek edited /alternates-brainstorming (+131) "put warning out of date" (view diff)
eschnou, KevinMarks, gRegorLove, chiui, KevinMarks__ and tantek joined the channel
#
KevinMarks so, back to the rel parsing thing. It seems like we have 2 thinsg going on at the moment:
#
KevinMarks raw rel-only parsing by default
#
KevinMarks magic parsing for alternate
#
KevinMarks so should I add magic parsing for the ones I am interested in at the moment (enclosure, tag, xfn rels)
#
KevinMarks or should I add capture of the other metadata to the general case?
#
KevinMarks hm, another way to model this would be to add the extra attrs to URLs found in rel parsing
#
KevinMarks so keep the rels to url mapping, but add a urls to extra properties mapping for the alternates etc
#
kevin marks edited /microformats2-parsing-brainstorming (+435) "/* rel-tag */ alternative output idea" (view diff)
#
tantek KevinMarks: why is alternates a problem?
#
KevinMarks because the parsers as written look for known hard-coded values
#
KevinMarks and so miss other values that can be there
#
tantek alternate has specific greater functionality than others per spec
#
tantek so that makes sense
#
tantek goal was to minimize the work and output needed for use-cases
#
KevinMarks content not being parsed, title not being parsed etc
#
KevinMarks so you would suggets adding magic parsed output for tag, xfn etc too?
#
tantek e.g. for XFN rel values, the point was that the destination should be used for the canonical name etc.
#
tantek not the linktext
#
tantek it was a way of avoiding having the consuming code assume too much
#
tantek rel=tag is different in that way, because the linktext is canonical
#
KevinMarks rel=enclosure also has attrs, as does rel=alternate
#
KevinMarks so 3 alternatives:
#
KevinMarks 1. magic parsing for each special rel case like alternates now
#
KevinMarks 2. replace the rels with a list of dicts not bare urls that preserve attrs
#
KevinMarks 3. add a "urls" that has the extra attrs for the urls so you can look up in there if you care about the ones in rels
#
KevinMarks 1 seems a bit mf1 and likely to cause a lot of extra code per parser
#
tantek indeed
#
KevinMarks 2 would be simpler but break current users
#
KevinMarks 3 may be a good compromise
#
KevinMarks and would help stop rel="friend met crush" causing the data to explode
#
tantek in practice that hasn't been a problem
#
aaronpk i haven't seen many occurrences of more than 2 rel values other than webmention and http://webmention.org/
#
gRegorLove I like the sound of 3, though I'm not consuming this type of information currently, so it's just in theory for me.
#
KevinMarks xfn is the one where we have many
#
KevinMarks though that may be a declining use case
#
tantek the many aspect may be declining yes
#
tantek I think that data is just too invisible
#
kylewm I think #2 would be fine with a semantic version increment
#
tantek I disagree because it makes the common case of rel for discovery take more steps
#
kylewm and that seems like the better solution architecturally?
#
tantek that's the whole reason we designed it this way in the first place
#
kylewm ah, ok
#
tantek nevermind architecture, it's the 90% use-case that matters
#
aaronpk most of the rel values i'm consuming are rel=me and rel=webmention and rel=hub
#
tantek making it easy for
#
tantek right
#
tantek most rel consumptions are just give me the URL
#
aaronpk and in all those cases, i already know what the other end is gonna do, so i just need the URL
#
tantek and doesn't care about collections of rels on a URL
#
KevinMarks right
#
tantek I think that's the best use of rel
#
tantek and that's what we should encourage moving forward
#
KevinMarks so adding "urls" for extra url info is a safer change
#
tantek the extra attributes on the <link> tend to be fragile / wrong
#
tantek because it requires the author to duplicate information from the server
#
aaronpk alternates is what doesn't work right now, because all I see is a URL, but I need to know what type of alternat it is
#
tantek s/server/destination
#
Loqi tantek meant to say: because it requires the author to duplicate information from the destination
KartikPrabhu joined the channel
#
KevinMarks and alternates has magic values code now
#
aaronpk the "type" attribute on the rel=alternate disappears in mf2 parsing right now
#
tantek that's a bug
#
tantek parser says it should go through
#
aaronpk what's it supposed to look like?
#
tantek "type": the value of the "type" attribute
#
tantek from http://microformats.org/wiki/microformats2-parsing#parse_a_hyperlink_element_for_rel_microformats
#
KevinMarks python parser preserves type
#
tantek second to last step, right before last end if
#
aaronpk oh yeah and hreflang would be useful too
#
tantek right, precisely the attributes that matter are specified, and nothing more
#
tantek it's a deliberate minimialist scoping of the feature
#
tantek s/minimialist/minimalist
#
Loqi tantek meant to say: it's a deliberate minimalist scoping of the feature
#
aaronpk but that's counter to how the rest of the mf2 parsing works, which is purely structural rather than semantic
#
KevinMarks except that leads to hard-coded implementation
#
tantek we're not adding attributes
#
tantek the number and names of attributes on <link> are static and fixed in HTML5
#
tantek and <a> / <area> for that matter
#
aaronpk i'd rather it worked more like h-entry, where the mf2 parser doesn't care about what the property names are
#
tantek if no one is using the "alternates" array, I'm ok with dropping it frankly
#
aaronpk that's why mf2 all of a sudden became way easier to use
#
tantek only because we're growing mf2 vocabs
#
tantek we're not growing html5 vocabs (elements and attributes)
#
tantek and frankly I think generalizing that would lead to bad behavior
#
tantek people starting to use "data-*" attributes for data exchange across implementations - which is forbidden by HTML5
#
KevinMarks so, you're arguing for 1 in my alternatives?
#
KevinMarks add special cases for rel-based mf's we need?
#
tantek I'm giving you the background for design considerations
#
tantek no need to generalize a static fixed set of things (names of HTML5 attributes)
#
tantek may need to generalize a variable set of things (rel values)
#
KevinMarks the "name" of a rel is useful too
#
tantek wat
#
aaronpk what is the name of a rel?
#
kylewm e.g.
#
kylewm <a rel="author" href="http://example.com/b">author b</a>
#
kylewm name = "author b"
#
KevinMarks yes
#
KevinMarks for XFN
#
tantek that's a horrible overloading of "name"
#
KevinMarks no it isn't
#
tantek it's just the text
#
tantek don't ascribe any more semantics to it - because you can't
#
KevinMarks it's a natural extension of implied name
#
KevinMarks you want it for alternate, for xfn and for tag
#
tantek it's not because it's used differently in all three
#
tantek alternate - the inner text is ignored (or non-existent, e.g. on <link>)
#
tantek xfn - the inner text is *informative* name of the person
#
tantek tag - the inner text is the *canonical* tag label from the author
#
tantek the semantics are completely different
#
tantek hence bad to generalize on that, certainly bad to call it a "name"
#
KevinMarks__ Alternate the link name is the title attr
dariusdunlap joined the channel
#
tantek that's my point - I'd rather a parser not be smart and just hand back the attributes
#
tantek rather than have it attempt to infer where the "name" comes from
#
tantek better to have "title" if there is a title attribute
#
tantek and "text" if there is any inner text in the element (no markup)
#
KevinMarks__ That was my #2 suggestion
#
tantek and then let the consuming code decide what to do with them
#
tantek no your suggestions mix many things
#
tantek which is ok, but it's imprecise to say "that was my #n"
#
KevinMarks__ You just argued that we should not take all attrs
#
tantek no
#
tantek there is the explicit list attrs in the HTML5 spec
#
tantek and then there is the potential list of attrs that an author can put on an element
#
tantek they are two different "all attrs"
#
tantek and yes, I think it's been useful to only add attrs as needed for use-cases from the HTML5 spec for link
#
tantek rather than get all of them https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#Attributes
#
tantek because that just gunks up the parsed result with stuff that no one has a use-case for
#
tantek the desire to keep the parsed result minimal / friendly / useful
#
KevinMarks__ I am adding these because I have use cases
#
aaronpk lol at the little trash can next to "rev" on that page: "Also this attribute doesn't mean revision and must not be used with a version number, which is unfortunately the case on numerous sites."
#
KevinMarks__ The "name" is useful
#
tantek KevinMarks I think you need to document your use-cases more explicitly
#
aaronpk oh another one that is actually used is "sizes"
#
tantek the enclosure one I get - for podcasting
#
aaronpk for rel=icon
#
tantek this is not about whether people publish them or not
#
tantek this is about is there a *use-case* for when you would use an mf2 parser to get this data about a page to then do something for the user
#
tantek e.g. IndieAuth -> rel=me
#
tantek Podcasting -> rel=enclosure
#
tantek I kept alternate only for feed discovery
#
aaronpk monocle and woodwind both consume alternate right now
#
tantek and do you check the "type"?
#
aaronpk i can't cause the php parser doesn't return it, so i just assume rss right now
#
tantek aaronpk - are you using the mf2 parser to get the alternates?
#
tantek lack of "type" is a big - that's already in the existing mf2 spec
#
tantek please file that as an issue on phpmf2
#
aaronpk just did
#
tantek s/big/bug
#
aaronpk the lack of the parser giving me type (plus i was in a hurry) is the reason monocle only supports microformat feeds right now
#
tantek but I want to pushback on *both* any sense of "just add all the attribute" or any sense of replicating an HTML DOM
#
tantek aaronpk - but that's a parser bug, not a spec bug
#
aaronpk i show it, but grey it out http://aaronparecki.com/uploads/monocle-feed-discovery-20150422-145956.png
#
aaronpk right
#
tantek and does not justify any spec changes
#
aaronpk well that'll be nice to have fixed
#
kylewm tantek: woodwind doesn't use mf2 for the rel=alternate parsing, probably just because i didn't think to
#
tantek kylewm: it would be interesting to see if you could, and then find any holes
#
aaronpk so what about "sizes"? that seems like it should be added to the parsed result too
#
tantek why?
#
tantek what's the use-case?
#
aaronpk since literally millions of phones consume it
#
aaronpk icons for home screen bookmarks
#
tantek more specifically, what are you going to code that needs it and produces a user visible result?
#
aaronpk well for one, the authorization screen when signing in to apps like monocle
#
tantek it's not needed for icons for home screen bookmarks
#
aaronpk but "not needed" != "not used"
#
tantek e.g. http://tantek.com/ gets a nice icon on home screen - does not use "sizes"
#
aaronpk your icon is a photo, which is usually scaled just fine by consumers
#
aaronpk but if your icon has line art, you'd want to specify a different image for smaller sizes
#
tantek aaronpk, a-ha this is more interesting: "the authorization screen when signing in to apps like monocle"
#
tantek look like I need to write up a "iconship" algorithm similar to "authorship"
#
tantek because the first place you should be getting that from is … the representative h-card photo
#
tantek just like rel=author is not the first thing you should check, neither is rel=icon
#
aaronpk the representative h-card photo doesn't have the ability to specify sizes
#
tantek why does the "authorization screen when signing in to apps like monocle" need sizes? what are you doing with that information?
#
aaronpk right now i'm taking the u-logo from the h-x-app and putting it in an image tag. that gets us by for now
#
tantek u-logo from top level h-* object
#
tantek that works
#
aaronpk what I would like to do, is show a larger icon, like 48px-ish, on the authorization screen, but then also have a screen that lists every app you've authorized (like this page https://github.com/settings/applications) and show smaller icons there
#
tantek would you fallback to a u-photo?
#
kylewm tantek: OK! I changed woodwind to use the alternates list from the mf2 json, works great and is a little simpler than before
#
tantek nice!
#
tantek that was the goal! less work for the consuming code
#
tantek one fewer parsing pass right?
#
KevinMarks__ So that is an argument for magic
#
kylewm yep, much less html parsing
#
aaronpk magic?
#
KevinMarks__ Well, using the parsing in mf2py
#
kylewm KevinMarks__: yep, which I was already doing once. no need to parse again later
#
tantek kevinmarks - it's not magic, it's following a spec
#
kylewm when you say magic, you mean, a special sanctioned list of rels that we care about enough to add special handling?
#
KevinMarks__ Me adding "enclosures", "tags" and "xfn" for my use cases
#
KevinMarks__ Yes
#
tantek right, I think generalizing the rel values aspect makes sense, whereas generalizing for all possible attributes does not
#
tantek because they have very different expansion / use behaviors
#
KevinMarks__ It's the classic microformats model
#
tantek it's not
#
tantek well, having a fixed set of rel values is, yes
#
tantek but not attributes
#
tantek because we're expanding the set of rel values
#
tantek per the registry
#
tantek but we are NOT expanding the set of attributes
#
kylewm one question -- why does the map have "url" instead of "href" for the href property?
#
tantek because they're specified in the HTML5 spec
#
tantek url is href made absolute
#
tantek that's probably worthy of an FAQ
#
tantek a bit of processing it has to do
#
kylewm :lightbulb:
#
KevinMarks__ "url" and "name" are similar in that way imo
KevinMarks and KevinMarks_ joined the channel
#
tantek I disagree about "url" vs "name" in that way, since the construction of an absolute URL is both well defined in an existing spec, and global to all uses of that URL
#
tantek whereas KevinMarks, your introduction of the concept of "name" does not have an existing well defined construction in a spec, nor is it global to all uses
#
tantek so while at a 10000 ft level they may seem similar in that the parse does (or could) do some extra processing, they are quite different in the details
tantek and KartikPrabhu joined the channel