#microformats 2017-06-12

2017-06-12 UTC
davidmead, tantek and [shaners] joined the channel
#
[shaners]
@zegnat: which microformats.io link are you talking about?
#
aaronpk
it was a php.microformats.io one in a github issue
[miklb], KartikPrabhu and gRegorLove joined the channel
#
gRegorLove
aaronpk: Wouldn't regex [ap] allow "ap", not just "a" or "p"?
#
gRegorLove
Oh, not without a + after. Nevermind.
#
aaronpk
[] is a character class, and by itself matches just one character
#
@KmbBowman1
@maccath @dmi @choult http://microformats.org/wiki/vcard-implementations https www facebook com pages 740674ce2123a969547455725720873232238379132 1677807529149780
(twitter.com/_/status/874105735835025408)
#
gRegorLove
Found some other edge cases where the regex could be tightened up. the am/pm check should be case-insensitive and optionally allow periods between.
#
gRegorLove
I'll push updates and some more tests
#
gRegorLove
I think the ^$ delimiters will make that more explicit, too. It's technically "working" for those cases now because the first regex in the or condition catches it regardless of the am/pm suffix
#
aaronpk
!spammer KmbBowman1
#
aaronpk
!block KmbBowman1
tantek, barpthewire, pfefferle and gRegorLove joined the channel
#
@pro4marketing
Mam nowy film na playliście w @YouTube: Mikroformaty adresu - wizytówka hCard - Microformats – https://www.youtube.com/watch?v=vTmYym3Qgkg&feature=youtu.be&a=
(twitter.com/_/status/874172331719053312)
adactio joined the channel
#
ben_thatmustbeme
!tell gRegorLove, tantek, aaronpk the parsing spec says a.m. and p.m must be case sensative, but the test suite disagrees with that, and actually so do I. I wrote ruby to be case incensative. what is the reasoning there?
#
Loqi
Ok, I'll tell them that when I see them next
#
Zegnat
ben_thatmustbeme, where in the spec?
#
Zegnat
“ Case insensitive { }"am"|{ }"a.m." suffix to treat an HH value of 12 as 00, or a case-insensitive { }"pm"|{ }"p.m." suffix to add 12 to HH value less than 12”
#
Zegnat
Specifies insensitive specifically
#
ben_thatmustbeme
!tell gRegorLove, tantek, aaronpk nevermind, i misread it at the time and remembered that
#
Loqi
Ok, I'll tell them that when I see them next
#
Loqi
zegnat has 3 karma in this channel (60 overall)
#
Zegnat
spent too much time on the vcp page
#
ben_thatmustbeme
i *thought* i had as well
#
Zegnat
I still feel like that date parsing should not be vcp related, and should be abstracted to dt-* parsing. But no matter how I write it up, it just gets more convoluted :( That might be something I spent time on during IWS
#
ben_thatmustbeme
i think its because mf2 uses datetime attribute, vcp is all backcompat
#
Zegnat
mf2 only uses the datetime attribute if dt-* is applied to a time element. It is not a requirement.
#
Zegnat
With vcp you can get implied datetime parts, validation of datetime. When you move away from vcp all that is lost.
nitot_ joined the channel
#
ben_thatmustbeme
well, yes, that sounds right to me, datetime field must be a valid 8601 according to html5, so i'm not so worried about that, and parsing a validating a timestamp when there is only one value, is sort of fruitless, it should be passed back as-is
#
ben_thatmustbeme
and let person do with what they will
#
ben_thatmustbeme
i think the whole vcp stuff is a little bit silly
#
ben_thatmustbeme
it gets really complex on the parser honestly and the gains are pretty minor.
#
Zegnat
<span class="dt-start">this monday</span> - is parsed as "this monday".
#
Zegnat
<span class="dt-start"><span class="value">this monday</span></span> - is parsed as "".
#
Zegnat
Feels. Weird.
Garbee joined the channel
#
ben_thatmustbeme
i don't actually see on http://microformats.org/wiki/value-class-pattern#Date_and_time_parsing where it says to change it to '' if its not valid
#
ben_thatmustbeme
both would return "this monday" by my reading
#
Zegnat
It might just be current implementations then. Or an interpretation of “If by parsing the "value" element(s), at least a specific date has been found, then the "value" is overall valid,” where all other results are labelled invalid.
#
Zegnat
Though testing that bit of HTML against the other microformats.io parsers it looks like parsers do not like to agree on what the outcome of that should be :p
nitot, tantek and [sebsel] joined the channel
#
@pro4marketing
Mam nowy film na playliście w @YouTube: Jak umieścić mikroformaty na logo strony - Schema, microformats – https://www.youtube.com/watch?v=9gGcvA4oVis&feature=youtu.be&a=
(twitter.com/_/status/874248143285751808)
#
@pro4marketing
Mam nowy film na playliście w @YouTube: Mikroformaty adresu, a SEO? Wizytówka hCard - Microformats – https://www.youtube.com/watch?v=vTmYym3Qgkg&feature=youtu.be&a=
(twitter.com/_/status/874248270666706944)
#
@pro4marketing
#Mikroformaty #i #mikrodane #w #wielkiej #pigułce :) https://projektmarketing.pl/mikroformaty-i-mikrodane/ #microformats #google #serp
(twitter.com/_/status/874250545795616768)
#
ben_thatmustbeme
Zegnat: agreed it should be clarified so parsers agree at least
nitot, nitot_, [miklb], [aaronpk], [sebsel], barpthewire, [kevinmarks], rodolfojcj, [chrisaldrich], tantek, gRegorLove and AngeloGladding joined the channel
#
Loqi
gRegorLove: ben_thatmustbeme left you a message 7 hours, 40 minutes ago: the parsing spec says a.m. and p.m must be case sensative, but the test suite disagrees with that, and actually so do I. I wrote ruby to be case incensative. what is the reasoning there?
#
Loqi
gRegorLove: ben_thatmustbeme left you a message 7 hours, 33 minutes ago: nevermind, i misread it at the time and remembered that
#
Loqi
[Zegnat] <span class="dt-start"><span class="value">this monday</span></span> - is parsed as "".
#
gRegorLove
Once this dt- parsing PR is updated and merged, it won't return empty string. It won't have a "start" property in the parsed results.
#
gRegorLove
That's my understanding of the valid vs invalid distinction
tantek joined the channel
#
gRegorLove
^ PR for php-mf2, to be clear
#
gRegorLove
o/ tantek
cheim, [miklb], [pfefferle], pfefferl_, [chrisaldrich], rodolfojcj, tantek and [cleverdevil] joined the channel