#microformats 2018-07-06

2018-07-06 UTC
[cleverdevil], [manton], tantek__, [miklb], [snarfed], [aaronpk], cheim and barpthewire joined the channel
#
@Sebsel ↩️ Oeps, ik ben dus overgestapt van de Twitter-reader naar een Indie-reader, en nu krijg ik dus dit soort notificaties niet meer. Tijd om de e-mails weer aan te zetten. (twitter.com/_/status/1015137420981960704)
#
@Sebsel ↩️ Maar inhoudelijk: het lijkt me inderdaad wat Martijn al zei: de Microformats van Ton's blog zijn wel aanwezig, maar niet goed aangebracht, waardoor Frank's weergave van slag is. Dat vind ik zelf het zwakste punt van de hele flow: dat Microformats zo kwetsbaar zijn in CMS'en. (twitter.com/_/status/1015138444941590528)
#
@frankmeeuwsen ↩️ Kunnen webmentions opnieuw worden verzonden als microformats eenmaal op orde zijn? Zoals Ton naderhand heeft gedaan. Zie ook mijn vragen op http://diggingthedigital.com//Waar-te-beginnen-met-Webmentions/ (twitter.com/_/status/1015140467510513664)
#
@ton_zylstra ↩️ als ik het goed begrijp wel (via handmatig form iig), ook voor verwijdering stuur je het nog een keer. De ontvanger checkt dan de gegevens en past aan. (twitter.com/_/status/1015150592916967424)
#
@ton_zylstra ↩️ De vraag is wat ik daar zelf aan kan sleutelen. Die microformats worden door Webmention en Semantic Backlinks plugins in WP aangebracht. (twitter.com/_/status/1015151050175799301)
#
@frankmeeuwsen ↩️ WP plugins zijn veelal open source dus je zou zelf wat in de PHP kunnen wroeten (succes...). Wellicht is via hooks in functions.php nog wat te tweaken? (twitter.com/_/status/1015153778285268992)
#
@ton_zylstra ↩️ ongetwijfeld maar de eerstvolgende plugin of thema update overschrijft dat waarschijnlijk. (twitter.com/_/status/1015157622595518464)
#
@ton_zylstra ↩️ al ben ik op zich prima bereid de code in te duiken. vanochtend zitten speuren nav eem handmatige trackback van jou. blog ik zo wel even. (twitter.com/_/status/1015160546923110400)
#
@asxasay As orientated as a microformats (twitter.com/_/status/1015161307782402050)
adactio, [jgmac1106], [eddie] and [jgarber] joined the channel
#
sknebel reading through https://www.zylstra.org/blog/2018/07/wrapping-my-head-around-webmentions/ and looking at the example where pages are shown as "u-url" news.indieweb.org: IMPLIED U-URL parsing...
#
sknebel full article, no explicit u-url, only one top-level <a> tag, with <a href="https://news.indieweb.org/nl" class="u-syndication"></a>
#
sknebel triggers what I assume is the second rule for implied u-urls, "else if .h-x>a[href]:only-of-type:not[.h-*], then use that [href] for url"
#
sknebel *sigh*
#
sknebel I really wish there was documention about the *intent* behind each of the implied rules
#
aaronpk oh wow
#
aaronpk that's a sneaky one
#
aaronpk my understanding is that the intent of them is to enable super compact code like <a href="http://example.com" class="h-card">Name</a>
#
sknebel yeah, but there is little documentation how that results in each of the specific rules
#
sknebel I have a hard time understanding why they exist like they are
#
aaronpk yeah
#
sknebel which in turn makes it hard to evaluate if they are good or not
#
sknebel they *seem* way to open to me, but chestertons fence and all that
#
[jgarber] Today I learned! https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
#
[jgarber] ☝ A principle I’d do well to take to heart more often. Thanks for mentioning that one, sknebel!
nitot and [cjwillcock] joined the channel
#
[cjwillcock] sknebel++ ^^^
#
Loqi sknebel has 13 karma in this channel (109 overall)
tantek__, [manton], [cleverdevil], jackjamieson, [eddie] and [dgold] joined the channel
#
sknebel Oh, I was wrong with what rule triggered it, misread the page source. still, seems like an errorounous implied url, investigating...
#
sknebel ... no, I was right the first time, misread the html hierachy
#
sknebel filed https://github.com/microformats/microformats2-parsing/issues/36
#
Loqi [sknebel] #36 Falsely implied u-url
#
aaronpk seems like the presence of u-syndication should break the implied u-url
#
aaronpk oh you said that in the issue :)
#
tantek__ yeah
#
sknebel that'd be a start, yes. I'd personally think maybe the presence of multiple links should break it, regardless of nesting level, but can't say if that's good or not due to the complained-about lack of documentation
#
aaronpk agreed. it seems like a good idea at first glance but without documentation on why these exist it's hard to tell
#
tantek__ sknebel: a lot of the reasons for the implied design is in the experience of classic microformats and using them to mark-up things on a page, and optimizing for common cases found
#
sknebel I get the idea
#
tantek__ some of it is in the historical microformats2 documentation
#
sknebel but I can't tell if I'm breaking any of what you want to optimize with them, if I don't know what cases those are
#
sknebel if you have links of discussions I'd love to read them and start a list somewhere
#
tantek__ start with microformats.org/wiki/microformats2 and click through to the historical pages it links to
#
gRegorLove Re: implied p-name http://microformats.org/wiki/microformats-2-implied-properties##Thus+if+a+microformat
#
gRegorLove Backs up the suggestion to restrict implied p-name to any other property, not just p-*
#
sknebel that page is the only one I've found discussing implied properties apart from the "one <a> h-card", and it doesn't explain the majority of rules. I would not have asked before searching myself
#
gRegorLove "and no properties" appears to apply to implied name, url, and photo based on that page.
[schmarty] and [cleverdevil] joined the channel
#
sknebel gRegorLove++ thanks for looking up the details of the discussion for #35 for me!
#
Loqi gregorlove has 32 karma in this channel (253 overall)
#
sknebel was there a specific case why people wanted to only revert the src, but not the alt addition?
#
tantek__ I don't know when / why the src addition even happened sknebel
#
sknebel in the same change as "alt"
#
sknebel that's why I'm asking why we are reverting only one of them
#
tantek__ alt has specific use-cases documented in examples, the obvious one is images of a person with no visible text adjacent and instead their name in the alt text. very common in facepile displays and on various social network UIs
#
tantek__ also I don't understand what you mean by revert
#
sknebel we only very recently added this, and snarfed complained that it didn't work for his use cases
#
sknebel and as discussed in #35, it seems like it was more or less added by mistake, with over-aligning rules further than initially proposed in #17
#
sknebel and the obivous one of images in h-cards is covered by specific implied p-name rules, as discussed in #35 after Zegnat proposed the two options
#
gRegorLove Was this the img src alt update, or was it newer? http://microformats.org/wiki/microformats2-parsing-issues#img_fallback_in_p-
#
gRegorLove Ah, #17. nvm
#
sknebel http://microformats.org/wiki/index.php?title=microformats2-parsing&diff=prev&oldid=66660
#
Loqi [Tantek Çelik] microformats2 parsing specification
#
gRegorLove Blame me: https://github.com/microformats/microformats2-parsing/issues/17#issuecomment-357462463 :/
#
Loqi [gRegorLove] Proposed updates, which I believe are in line with the resolution: **parsing a p- property** No content change, just splitting out whitespace trimming into a separate bullet point: Original: > * else return the textContent of the element afte...
#
sknebel I blame myself too, one comment earlier
#
sknebel says the same, just not spelled out
#
sknebel and we didn't catch this
#
sknebel expanding the change further than initially proposed. sounded good
#
sknebel which is why I treat #35 as partial revert of #17, and wonder if the entire "eplacing any nested <img> elements with their alt attribute, if present; otherwise their src attribute..." line that was added there shouldn't be removed again, and not just the src part of it
sketchess joined the channel
#
gRegorLove That reasoning sounds good to me
jackjamieson joined the channel
#
sknebel which is why I'd like to know if there is a specific reasoning behind not doing so, or if people might have missed the context - since it's really new it's unlikely anyone is relying on it, and it's different from removing a long-standing rule, so I'd advocate for removing the line entirely. bit unlucky I didn't have time to call into the IWS session :/
#
sknebel that said, I don't want to delay fixes for this, so since it's clear what was voted on I can live with that if. Been trying to find time to finish reviewing Kartiks mf2py PR containing this, but it's a big one with many changes
#
gRegorLove I lean towards removing the line entirely since it's such a young change
#
gRegorLove I didn't understand the context of #17 at IWS and I don't think others did; it was just a quick, conservative update.
#
gRegorLove Ohh, yeah I forgot Kartik has this in a PR already
#
sknebel updating that PR would be quick, happy to do it
#
@neauoire Does Firefox still support microformats? Has it been replaced with something else? (twitter.com/_/status/1015329222854770688)
#
tantek__ yes and even with a microformats2 parser that web extensions can use
KartikPrabhu joined the channel
#
aaronpk they probably won't see your reply in IRC :)
KartikPrabhu and cheim joined the channel
#
tantek__ aaronpk, can you link to the ruby microformats parser bug you're referring to here? https://github.com/tootsuite/mastodon/issues/7926#issuecomment-402888936
#
Loqi [aaronpk] That would work 😃 The only downside to this change is until the rest of the mf2 parsers are updated they'll be getting bad parse results from Mastodon permalinks. Could be good incentive to hurry up on updating those parsers tho 😂
#
tantek__ and perhaps cc jgarber?
#
tantek__ hmm not sure that's the right jgarber
#
aaronpk updated that comment
#
tantek__ thanks!
#
sknebel gRegorLove: so, do you want to do a (hopefully quick) vote again for the larger change?
#
tantek__ we shouldn't be voting for changes, we should be reasoning about them until we have a thoughtful consensus
#
KartikPrabhu everyone not in the channel raise your hands!
#
gRegorLove I think if we don't have any objections, and KartikPrabhu and tantek__ agree with the above reasoning, we'll have consensus
#
KartikPrabhu lol
#
gRegorLove Or other implementers :)
[eddie] joined the channel
#
sknebel ok, replace my question with "stick with the result from IWS or continue discussing" ;)
#
gRegorLove In the change control process we're at "Iterate to resolve objections if any"
#
KartikPrabhu wait I thought implied name didn't have src replacement only alt replacement
#
KartikPrabhu hmm where the lastest link to this discussion?
#
gRegorLove https://github.com/microformats/microformats2-parsing/issues/35
#
Loqi [snarfed] #35 proposal: drop img src (and alt) from implied p-name
#
gRegorLove But also see today's chat logs with sknebel and I digging into it. We believe it was a mistake to add that to implied p-name parsing in #17
#
KartikPrabhu mistake as in never substiture images at all?
#
gRegorLove No, scope of the conversation is implied p-name
#
KartikPrabhu yeah I am in the same scope
#
KartikPrabhu so no image subsitution for implied name?
#
gRegorLove https://chat.indieweb.org/microformats/2018-07-06#t1530902913907400
#
Loqi [gRegorLove] Blame me: https://github.com/microformats/microformats2-parsing/issues/17#issuecomment-357462463 :/
#
KartikPrabhu yeah I saw that. But is the final resolution to never replace imgs with anything or replace with alt but not src (for implied name)
#
gRegorLove implied p-name final rule would become: "else return the textContent of the .h-x after: 1) dropping any nested <script> & <style> elements; 2) removing all leading/trailing whitespace."
#
gRegorLove textContent will get the alt, afaik
#
KartikPrabhu not sure. textContent rules are not defined anywhere in the wiki
#
gRegorLove Oops, I misspoke about textContent. Earlier rule will get the alt.
#
KartikPrabhu yeah already implemented in mf2py latest
#
KartikPrabhu unreleased (waiting for review from kevinmarks)
#
gRegorLove step 3, `.h-x>img:only-child[alt]:not([alt=""]):not[.h-*]`
#
KartikPrabhu eh! now I am lost
#
gRegorLove The final fallback rule would do nothing special with <img>. No replacement.
#
KartikPrabhu I thought we are talking about the final step
#
gRegorLove (if this counter-proposal is accepted)
#
gRegorLove Hah, sorry
#
sknebel https://github.com/microformats/microformats2-parsing/issues/35#issuecomment-393615508
#
KartikPrabhu I am so confusedn
#
Loqi [Zegnat] To summarise the previous change: we normalised text parsing to use the exact same wording for `p-*`, `e-*`’s `value`, and implied name. Originally to make sure `<script>` and `<style>` tags would get correctly dropped everywhere, but in the end al...
#
sknebel I am in favor of option 1 proposed there
#
gRegorLove KartikPrabhu, Check the implied p-name update here: what it was before and what was accepted: https://github.com/microformats/microformats2-parsing/issues/17#issuecomment-357462463
#
Loqi [gRegorLove] Proposed updates, which I believe are in line with the resolution: **parsing a p- property** No content change, just splitting out whitespace trimming into a separate bullet point: Original: > * else return the textContent of the element afte...
#
KartikPrabhu it isn't option 1 that is the whole proposal
#
sknebel IWS apparently discussed option 2 and decided that's way to go
#
gRegorLove sknebel and I are proposing dropping the second bullet "replacing any nested..."
#
KartikPrabhu gRegorLove: yeah, the point is I don't know what textContent is supposed to do with the image
#
gRegorLove What does it do currently?
#
KartikPrabhu you mean mf2py?
#
gRegorLove Yeah
#
KartikPrabhu I can make it do anything. Right now it replaces img with the alt but never with the src (for implied name)
#
gRegorLove That gets into #15 as well
#
gRegorLove Which I haven't followed very closely
#
KartikPrabhu can we decide a fix for one issue first :P
#
gRegorLove I don't know if it's "right" or not, I'm just saying that I think falling back to the parser's current implementation of textContent is ok.
#
gRegorLove "else use the textContent..." has been in the spec for a while, so mf2py has done something to that effect previously
#
KartikPrabhu I just want to know what to do with <img>. replace with stuff or just drop it
#
sknebel http://microformats.org/wiki/index.php?title=microformats2-parsing&diff=prev&oldid=66660 (#17 initially only proposed to add the language about script/style tags, and then "accidentially" got expanded)
#
KartikPrabhu if you say use "textContent" I have no idea what that means
#
gRegorLove Where was Zegnat's textContent web thingy...
#
Loqi [Tantek Çelik] microformats2 parsing specification
#
gRegorLove KartikPrabhu, What was mf2py doing previously? This spec change was only in January.
#
KartikPrabhu dropping all images
#
gRegorLove Ah, interesting.
#
gRegorLove checks what php-mf2 did / does
#
KartikPrabhu just like dropping <script> and <style> is specified, I'd be ok with any explicit specification of what to do with <img>
#
KartikPrabhu but saying textContent is meaningless for me
#
gRegorLove Well, that's #15 (as much as you don't want me to mention another issue ;)
#
tantek__ perhaps fix #15 first, in order to deal with one issue at a time
#
aaronpk is not looking forward to catching up on all this discussion
#
aaronpk wasn't even there at the IWS session
#
gRegorLove Hehe
#
KartikPrabhu yeah ok then lets do 15 or something
#
KartikPrabhu but that is more whitespace oriented
#
gRegorLove Found Zegnat's proposed spec and tool: https://wiki.zegnat.net/media/textparsing.html
#
sknebel that includes the alt and src
#
KartikPrabhu right
#
KartikPrabhu mf2py right now does <img> subsitution differently in differnt contexts
#
tantek__ sknebel: are you able to find reasoning behind the decisions in Zegnat's proposed spec?
#
tantek__ like you were asking for in existing spec?
#
sknebel that part was based on #17/the existing replacement rules, since the focus was mainly whitespace,
#
sknebel so I don't think Zegnat intended to add anything there
#
sknebel KartikPrabhu's "well,what do I do then" is a good point though for #35, against reverting fully since that's an also kind-of undefined state
#
gRegorLove Kind of, but the spec still says "use textcontent"
#
sknebel it's a bit of a weird coincidence that mf2py apparently did it not per spec beforehand, and in implementing #17 kartik fixed the img handling everywhere
#
sknebel which totally surprised snarfed and wasn't acceptable for him(?)
#
KartikPrabhu right. subsituting <img> with src in implied name had strange bridgy effects
#
KartikPrabhu so now it is replace by alt but not src, only in implied name everywhere else it is replace by alt or src
#
sknebel if we use textContent as in DOM, then it does not include alt, but completely ignores images
#
KartikPrabhu yup
#
sknebel which makes sense in that it then is necessary to spell out alt/src replacement where it is required
#
KartikPrabhu exactly my point!
#
sknebel I thought your point was that you do not know if textContent includes images or not?
#
KartikPrabhu yeah because mf2py spec does not say use textContent as defined in the DOM
#
KartikPrabhu it just say textCOntent
#
sknebel ok
#
KartikPrabhu in that sense we don't need to say drop <style> and <script> either
#
sknebel we do if we assume DOM textContent
#
KartikPrabhu DOM textContent implicitly drops <script> no?
#
sknebel no
#
KartikPrabhu hmm weird
#
sknebel gRegorLove: does that match what php-mf2 assumes?
#
gRegorLove Latest 0.4.4-alpha uses Zegnat's algorithm
#
gRegorLove https://github.com/indieweb/php-mf2/pull/168
#
Loqi [Zegnat] #168 New algorithm for plain text values
#
sknebel okay, that includes alt/src replacement, but I believe only because the microformats spec says it
#
gRegorLove Right
#
sknebel which if we change it for implied p-names fallback it wouldn't everywhere
#
sknebel If we agree that the goal is to exclude images in this case, we can of course also write that explicitly into the spec
#
gRegorLove I haven't dived into the code of it, but the previous plaintext functions in php-mf2 did have a context of whether it was implied parsing or not, and handled them slightly differently
#
gRegorLove I presume it still does similar
#
KartikPrabhu instead of randomly deciding this we should ask aaronpk and snarfed since Xray and Bridgy are the biggest consumers
#
aaronpk uhoh what
#
aaronpk I can't followall this. someone write up a summary plz
#
gRegorLove snarfed is already on record, definitely doesn't want src
#
gRegorLove and probably doesn't want alt
[jgmac1106] joined the channel
#
KartikPrabhu aaronpk: when parsing for impled name should <img> be replaced by 1) alt or src or 2) only alt never src 3) dropped completely
#
KartikPrabhu one sentence summary ^
#
sknebel KartikPrabhu++
#
Loqi kartikprabhu has 27 karma in this channel (208 overall)
#
aaronpk i'm having a hard time imagining any situation in which a URL is an acceptable value to display to people as the "name" of anything
#
KartikPrabhu yes. agreed what about "alt"
#
gRegorLove At IWS we agreed to #2 btw
#
KartikPrabhu I know which is why I added it to mf2py
#
aaronpk I think i've seen enough examples of alt being used well to support that
#
gRegorLove Just context for aaronpk
#
KartikPrabhu ok good. so aaronpk is with #2, snarfed is ok with #2, I already implemented #2 ;)
#
sknebel note that it's only the last fallback case for implied p-name, where it tries to turn textcontent of the h-* into a p-name
#
sknebel not the "designed" implied p-names, e.g. for the micro-h-cards
#
aaronpk oh I did think of one case where a URL is a good name for something... on nametags at indiewebcamp
#
KartikPrabhu aaronpk: yes. but more in-the-wild uses for mf2 parsing
#
aaronpk my humor is not coming through IRC today apparently
#
KartikPrabhu aaronpk: or I am being a bit thick since had long meetings :P
#
gRegorLove It's 100 here today, so my brain might be frying a bit ;)
#
KartikPrabhu to conclude my take: replace <img> with 'alt' sounds fine for now
#
KartikPrabhu if some cases come up where this is not desired then we can change the spec accordingly instead of just anticipating it now
#
sknebel (checking if [snarfed] is around)
#
gRegorLove Say bridgy three times
snarfed joined the channel
#
KartikPrabhu oh hey!
#
snarfed hi!
#
KartikPrabhu snarfed: when parsing for impled name from textContent should <img> be replaced by 1) alt or src or 2) only alt never src 3) dropped completely
#
snarfed hah
#
KartikPrabhu I know you don't like #1 but which of #2 or #3
#
snarfed i won't try to answer that broadly
#
snarfed but i can describe examples where alt and src give poor results for me
#
KartikPrabhu of course. But from bridgy experience which one would be more suitable
#
snarfed looking
#
snarfed definitely not src
#
snarfed usually not alt either
#
KartikPrabhu cool. so you would prefer #3 drop img completely
#
snarfed in general i want minimal, highly constrained implied name, if even at all
#
KartikPrabhu :thumbsup:
#
snarfed i mean i guess...but zegnat, tantek, etc have a much clearer and broader view of the whole ecosystem than me, so i don't really want to vote overall
#
snarfed mostly i defer to people like them
#
KartikPrabhu no. just asking the biggest user of mf2py :)
#
snarfed heh ok
#
snarfed for my small number of narrow use cases, that's my experience
#
KartikPrabhu cool. so gRegorLove sknebel maybe instead of resolving #15 now, we can resolve #35 with either option #2 (as suggested by Zegnat) or #3 drop img completely
#
gRegorLove #2 was agreed to at IWS. Today's discussion is basically: should we do #3?
#
KartikPrabhu yes
#
KartikPrabhu I can implement any of those
#
gRegorLove With any decision though, you still have the question "what does textContent mean", right?
#
KartikPrabhu yes. but that is a separate issue if the <img> replacement is explicitly specified
#
snarfed out of curiosity...the conclusion at IWS was explicitly #2 and not #3, and had many of the right people involved. is there a reason we're revisiting that conclusion?
#
gRegorLove Oh, for #3 you want it to say "drop the image" before doing textContent. Ok
#
KartikPrabhu also what snarfed asked :P
#
gRegorLove snarfed, short version: a previous spec change in January added the img src alt text to implied p-name
#
sknebel snarfed: because I asked why #2 and not #3 and there wasn't any answer outside "we talked only about #2", and I felt (maybe wrongly, given the textcontent context) that #3 was the more logical one
#
gRegorLove Before that it was just "else use the textContent of the .h-x for name"
#
KartikPrabhu no #3 was also talked about
#
snarfed gRegorLove: right. by zegnat. he was in the iws discussion too, and agreed to #2
#
snarfed sknebel: thanks! yeah we explicitly discussed and #3 and settled on #2, at least for now. we were open to #3, but it was more complex and aggressive, so we wanted more time and thought before doing it.
#
sknebel that's the thing, given that #3 only removes things introduced in january in the change you objected to, I didn't feel it to be "agressive", but the rightly scoped fix of introducing it
#
sknebel especially since we didn't discuss introducing it much, and it flew under the radar of another change
#
snarfed sure!
#
snarfed i' defer to zegnat, tantek, et al. specs and mf2 parsing are above my pay grade.
#
KartikPrabhu maybe we shouldn't worry too much about what was/wasn't done in January and update the spec according to recent discussion
#
sknebel after todays discussion (your textContent argument, snarfed being ok with it and not having a good example against alt(?)), sure.
#
KartikPrabhu cool. count mf2py as implemented
#
sknebel (I kind of consider it my fault we did the mistake in january, so I wanted to be sure it's fixed *right* and view it from that perspective)
#
aaronpk lols at the idea of a pay grade for this
#
KartikPrabhu yeah, where's my cheque ;)
#
sknebel KartikPrabhu: I'm trying to get to reviewing your PR too, but reviewing these large ones is always tricky. hopefully next week!
#
KartikPrabhu sknebel: yeah no worries. I'll in fact add you as reviewer
#
sknebel I always feel bad when code is lying around so long
#
KartikPrabhu oh no! I can't officially add you on the repo. But please leave comments
#
sknebel heh, didn't we have the group membership discussion like yesterday? who remembers who can add people?
#
KartikPrabhu owners on the microformats repo
#
KartikPrabhu also only "owners" can review it seems
#
gRegorLove Can someone capture on github #35 what the new proposal is?
#
KartikPrabhu gRegorLove: already there https://github.com/microformats/microformats2-parsing/issues/35#issuecomment-393615508
#
Loqi [Zegnat] To summarise the previous change: we normalised text parsing to use the exact same wording for `p-*`, `e-*`’s `value`, and implied name. Originally to make sure `<script>` and `<style>` tags would get correctly dropped everywhere, but in the end al...
#
sknebel https://github.com/microformats/microformats2-parsing/issues/35#issuecomment-403114249
#
KartikPrabhu or your latest comment
#
Loqi [gRegorLove] Oops, I should have linked the video earlier. I've transcribed some of it below for easier reference. We discussed and agreed on the second proposal. Topic starts https://youtu.be/0OUy7jjUN5k?t=2h1m20s, then at 2:02:23: > Tantek: so we're just go...
#
gRegorLove Hah. Which one.
#
KartikPrabhu they are the same (?!)
#
gRegorLove Zegnat's has two proposals.
#
sknebel KartikPrabhu: Zegnat's comment proposes TWO options to chose from
#
gRegorLove "No change" is what we're landing with? I'm just confirming.
#
gRegorLove No change from my last comment, I mean.
#
sknebel yes
#
KartikPrabhu yes
#
sknebel and thanks everyone for spending the time to discuss this with me now, even if it doesn't change the outcome :)
#
sknebel gRegorLove++
#
Loqi gregorlove has 33 karma in this channel (254 overall)
#
sknebel KartikPrabhu++
#
sknebel snarfed++
#
Loqi snarfed has 1 karma in this channel (394 overall)
#
KartikPrabhu hey where's my karma Loqi
#
sknebel I ++ed you less then an hour ago, seems like Loqi thinks I should be a bit more stingy?
#
KartikPrabhu gives Loqi cake
#
KartikPrabhu oh well
snarfed left the channel
#
gRegorLove KartikPrabhu++
#
Loqi kartikprabhu has 28 karma in this channel (209 overall)
#
gRegorLove sknebel++
#
Loqi sknebel has 14 karma in this channel (110 overall)
#
gRegorLove cake++
#
Loqi cake has 1 karma
#
gregorlove edited /microformats2-parsing (-135) "/* parsing for implied properties */ update implied p-name <img> processing per https://github.com/microformats/microformats2-parsing/issues/35" (view diff)