#microformats 2018-03-16

2018-03-16 UTC
[kevinmarks] joined the channel
#
[kevinmarks] I like that idea
#
[kevinmarks] Also possibly making this something you could add to, do I could do things like the BBC recipes conversion
#
KartikPrabhu [kevinmarks]: I was thinking this to be strictly spec conformant
#
KartikPrabhu [kevinmarks]: are you thinking that there could be some external rules like your BBC conversion that can be passed to the parser as additional transformations?
#
KartikPrabhu that could work
#
KartikPrabhu I think if we broadly agree on the file format and if the phpmf2 guys are up for this then it might be owrth doing
tantek joined the channel
#
tantek edited /code-tools (+1) "Reverted edits by [[Special:Contributions/Imran87h|Imran87h]] ([[User talk:Imran87h|Talk]]) to last version by [[User:Tantek|Tantek]]" (view diff)
#
tantek edited /Special:Log/block () "blocked [[User:Imran87h]] with an expiry time of infinite (account creation disabled): spam in edit summary" (view diff)
tantek, [cleverdevil] and [eddie] joined the channel
#
@cbfishes OK here is one last test before I finally go to sleep. Learning about #microformats, #indieweb, and #webmentions Sometimes I wonder how I end up way down these rabbit holes https://chrisbeckstrom.com/feed/2018/03/15/32/ (twitter.com/_/status/974496449894416384)
[miklb], tantek, [eddie], [cleverdevil], nitot, barpthewire, webchat373, [kevinmarks], Garbee, irlbd and webchat121 joined the channel
#
webchat121 hello
barpthewire, [eddie], nitot and [cleverdevil] joined the channel
#
KartikPrabhu here is how backcompat rules in json would look https://github.com/kartikprabhu/backcompat-rules
#
Loqi [kartikprabhu] backcompat-rules
nitot and [tantek] joined the channel
#
aaronpk are the parser prefixes actually necessary there?
#
KartikPrabhu aaronpk: parser prefixes?
#
aaronpk p- dt- e-
#
aaronpk those aren't part of the parsed mf2 json, so I don't see why they're in the mapping
#
aaronpk "entry-title" turns into "name" in the mf2 JSON
#
KartikPrabhu yes I think, because you are supposed to parser them as such
#
KartikPrabhu so entry-title is parsed as p-name not u-name for instance
#
aaronpk I thought mf1 required more knowledge of the vocab in order to parse
#
KartikPrabhu yes, which is why these rules are vocab specific
#
aaronpk p-name vs u-name tells the mf2 parser where to get the value from
#
aaronpk but I thought those rules dont apply to mf1 because they are even more specific per property
#
KartikPrabhu yes and while backcompat parsing hentry the entry-title is parsed as a p-* into the value "name"
#
aaronpk oh, I see what's going on. at least the php parser actually replaces the class name with the mf2 class name.
#
KartikPrabhu yes so does the mf2py parser
#
KartikPrabhu but according to these rules
#
aaronpk I thought it was doing that differently for some reason
#
aaronpk so yeah you need the prefixes if it's doing that
#
KartikPrabhu yup
#
KartikPrabhu this is the easiest way we could come up with
#
KartikPrabhu so the idea is to have a common repo with such rules so any parser can use them
#
aaronpk looks easy to plug into the php parser: https://github.com/indieweb/php-mf2/blob/master/Mf2/Parser.php#L1715
#
KartikPrabhu yeah, I think the mf2py rules were largely borrowed from the phpmf2 ones
#
KartikPrabhu yup https://github.com/microformats/mf2py/blob/master/mf2py/backcompat.py#L3
#
KartikPrabhu :P
#
KartikPrabhu might work this into mf2py this weekend
[eddie] and [kim_landwehr] joined the channel
#
KartikPrabhu I have no idea how to incorporate the rel-bookmark to u-url rule in hentry for this
nitot, bear_, Zegnet, MeanderingCode_, [eddie], [miklb], aaronpk, [cleverdevil] and [kevinmarks] joined the channel
#
[kevinmarks] isn't that done with special case code?
#
[kevinmarks] in unmung, I added an extra mapping specifically for the BBC recipe website: https://github.com/kevinmarks/unmung/blob/master/mf2py/backcompat.py#L97
#
[kevinmarks] I like the idea of being able to pass in a mapping like that, for site specific translation
#
KartikPrabhu [kevinmarks]: yes that could be done as an additional argument
#
[kevinmarks] that would be cleaner than me bodging it
#
[kevinmarks] I suppose you could have a domain match
KartikPrabhu, [eddie] and nitot joined the channel
#
KartikPrabhu mf2py can now use JSON backcompat rules https://github.com/kartikprabhu/mf2py
#
Loqi [kartikprabhu] mf2py: mf2 parser in python (this is an experimental fork)
[cleverdevil] and nitot joined the channel
#
aaronpk ohno
#
aaronpk another regression
#
Zegnat BTW, aaronpk, I filed an issue on Micropub about the nested mf example not including value properties. I am still not sure if it needs adressing or not though :/
#
aaronpk I saw
#
aaronpk so we lost the ability for mf2 properties to contain hyphens
#
KartikPrabhu what regression?
#
aaronpk I remember an issue about ignoring invalid class names
#
Zegnat Huh? But properties with hyphens are valid?
#
aaronpk I thought so, and I was using that
#
aaronpk to namespace p3k vocabs
#
Zegnat It is valid
#
Zegnat “The "*" for root (and property) class names consists only of lowercase a-z and '-' characters.”
#
Zegnat "*" as in "p-*". So hyphens are fine.
#
Zegnat Where did you spot this regression?
#
aaronpk when I tried to consume my site's microformats :)
#
aaronpk notice the property p3k-drank here https://php.microformats.io/?url=https%3A%2F%2Faaronparecki.com%2Fdrank but not here https://pin13.net/mf2/?url=https%3A%2F%2Faaronparecki.com%2Fdrank
#
Zegnat Actually, the 3 is the invalid character there ;)
#
aaronpk ohhh
#
Zegnat Not the hyphen
#
aaronpk you're right
#
aaronpk well then
#
aaronpk crap
#
KartikPrabhu oh no aaronpk has to rename p3k
#
Zegnat I wonder what the reason for excluding numbers is. Forcing readable vocabs?
#
aaronpk i'm using that in Teacup for micropub requests too
#
aaronpk heh the python parser handles the 3 fine
#
KartikPrabhu forcing the * to follow some rules is weird from the point of view of experimental/custom properties
#
aaronpk ruby skips it
#
KartikPrabhu aaronpk: yeah mf2py does not check for those yet
#
aaronpk well crap what should I do
#
KartikPrabhu my initial reaction is to remove that rule
#
KartikPrabhu it is weird that h-MyProject-article
#
KartikPrabhu is not valid
#
KartikPrabhu or p3k for that matter
#
Zegnat parsers support (or supported in past) your -p3k- usage, and it is out in the wild, so you could definitely argue for changing the spec
#
aaronpk I think one of the reasons it was added was specifically to skip properties with capital letters since they were starting to be used by css frameworks
#
aaronpk and I think the numbers were part of that too, things like u-span3 or whatever
#
KartikPrabhu css frameworks also use u-* for utility classes so <shrug>
#
gRegorLove pthreek? :)
#
gRegorLove The strictness of that cleans up a lot of utility CSS that was getting picked up by parsers.
#
KartikPrabhu no one consumes random classes through mf2 so I don't see the issue
#
aaronpk there's a test in the parser to make sure it skips a class called "u-column1"
#
aaronpk :sigh:
#
gRegorLove It was a spec update resolved at IWS 2016
#
aaronpk I guess i'll change my markup?
#
aaronpk i'm not gonna change my internal class name just yet tho, cause that's a lot more work to sync that between teacup and my site and whoever else is using teacup
#
gRegorLove http://microformats.org/wiki/microformats2-parsing-issues#ignore_u-camelCase_properties
#
Loqi microformats2-parsing-issues
#
gRegorLove Sorry. That does suck. Not sure what to suggest :/
#
aaronpk oof a whole bunch of my internal tools use the p3k- namespace for stuff
#
aaronpk at least the external change is relatively easy and I don't think I have anything that depends on that markup (yet) until just now
#
gRegorLove Perhaps an exception to that spec for anything before the second hyphen?
#
aaronpk oh like to specifically allow numbers in namespaced properties?
#
gRegorLove Yeah
#
KartikPrabhu so h-p3k-Bumble is still invalid?
#
aaronpk u-col1 would not be allowed, but u-p3k-foo would be allowed
#
KartikPrabhu this is going to get messy and regexy
#
gRegorLove Naw, it's a really simple regex
#
Zegnat I am not sure if it is a good idea to introduce special rules for a “namespace” part ... we usually don’t want those
#
gRegorLove Good point
#
Zegnat Is anyone making use of -x-? I am a little against that, but if you want to loosen the rules maybe do it only for classes that contain the -x- prefix?
#
aaronpk I used p3k instead of x
#
KartikPrabhu i think -x- was for experimental properties
#
KartikPrabhu not for namespacing
#
Zegnat p-x-p3k-drank might be a bit big ...
#
Zegnat I don’t think the microformats philosophy of semantic class names wants any namespacing at all, KartikPrabhu. http://microformats.org/wiki/namespaces-considered-harmful
#
Loqi namespaces considered harmful
#
KartikPrabhu i don't think these are namespacing in the XML sense
#
KartikPrabhu more like custom properties
#
KartikPrabhu no one needs to look up a namespace spec for u-p3k-drank
#
KartikPrabhu if we are going to be that strict then we should have h-* where * is only a-z
#
KartikPrabhu that does kill h-review-aggregate
#
Zegnat I am fine with expending * to accept more (e.g. digits, I am not sure why those got banned in the first place), I would be against special ruling to only loosen * between the first two hyphens as that smells too much of separate rules for a namespace part.
#
Zegnat If that makes sense..?
#
aaronpk they were disallowed to avoid all the classes from css frameworks showing up as mf2 properties
#
aaronpk like u-col1
#
KartikPrabhu yeah but who consumes col1 through mf2 anyway!?
#
KartikPrabhu as in what's the harm if they do show up?
#
Zegnat switches to Python parser just to consume -p3k- properties
#
KartikPrabhu lol
#
Zegnat So does the Python one treat * as a true wildcard? h-💩 is possible?
#
aaronpk oh no
#
KartikPrabhu Zegnat: yeah I tihnk so
#
gRegorLove KartikPrabhu: It's messy. Why parse things that were clearly not authored to be parsed as mf2?
#
gRegorLove Present p3k discussion being the exception, of course
#
gRegorLove http://www.kevinmarks.com/twitterutils.html
[snarfed], tantek and KartikPrabhu joined the channel
#
KartikPrabhu gRegorLove: not sure what you mean by messy. Who cares if the parsed JSON is messy. Consumers will only use properties that they care about
#
gRegorLove I think a better question is "why parse them?" The CSS in kevinmarks post is clearly design related and not something consumers will use.
#
tantek lots of logs today too!
#
tantek KartikPrabhu, yes, rel value usage in mf1 is one of the things that makes backcompat more challenging. you may want to take a look at how microformatsnode handles it
#
tantek pretty sure microformatsnode had a bunch of backcompat tables
#
tantek re: *-p3k-* - hmm how did we miss that in 2016 aaronpk?
#
tantek just goes to show why we need parser implementation of suggested changes even if we're all agreed to understand the ramifications better
#
tantek btw prefix != namespace
#
tantek just to be clear
#
gRegorLove We had that implemented in Go at 2016. I don't think aaronpk was in the room when we went through open spec issues.
#
tantek there's no magic "first thing after the dash is a namespace" processing going on so it's not a namespace
#
tantek it's just a string prefix convention
#
tantek "namespace" means a lot more formality and semantics
#
tantek so do we relax the number requirement?
#
tantek and allow a-z0-9 ?
#
tantek this is worth considering: https://chat.indieweb.org/microformats/2018-03-16/1521228053175200
#
Loqi [gRegorLove] Perhaps an exception to that spec for anything before the second hyphen?
#
tantek I would be ok with that
#
tantek feels like a fairly conservative change
#
tantek and the intent is clear - for vendor prefixes http://microformats.org/wiki/microformats2#VENDOR_EXTENSIONS
#
Loqi microformats2
#
tantek that should still avoid the class names like p-column1
#
tantek or whatever they were using
#
Zegnat What is the difference between a vendor prefix and a namespace in this case? They feel extremely similar to me.
#
tantek Zegnat, namespaces have a ton more baggage
#
KartikPrabhu tantek: yeah I meant prefix not namespace in the sense you are saying
#
tantek which makes it seem like they work better in theory, but in practice, you carry around a lot of baggage for no practical benefit
#
Zegnat But surely the -p3k- one isn’t really any different? Having a specific content as defined by aaronpk’s tools?
#
KartikPrabhu tantek: mf2py does rel to property conversion but it is hard to put it into my JSON format
#
tantek Zegnat you're just repeating yourself "surely the -p3k- one isn’t really any different? " yes that's an example of a string prefix
#
Zegnat concedes to then not at all understanding when a prefix is a namespace and when it isn’t
#
tantek look at any programming language that has a concept of a "namespace" to better understand there's a lot more formalism and semantics and functionality to what a "namespace" is beyond a string (prefix or otherwise)
#
KartikPrabhu Zegnat: the point is mf2 does not have any "namespace" in the sense of XML
#
tantek or in the sense of any programming languages
#
KartikPrabhu I agree with tantek here
#
tantek there's more about this difference on the namespaces page
#
tantek specifically there's the mistaken example given of hAtom's entry-* properties as if that's a namespace, which it is not
#
KartikPrabhu riht
#
Zegnat Yes, I read that page, and I felt like the -p3k- was very close to the bound prefixes anti-pattern (http://microformats.org/wiki/namespaces-considered-harmful#bound_prefixes_are_an_anti-pattern).
#
Zegnat Either just `drank` would have worked as the mf2 property. If that doesn’t work because aaronpk needs a separation between random all drank properties and his specific p3k-tool outputed properties, it feels very much to me like there is some implied format and the -p3k- implies some sort of namespace.
#
Loqi namespaces considered harmful
#
Zegnat But it is late and I’ll have another read in the morning :)
#
Zegnat As I said, I am not against losening the restrictions on what * is allowed to match, neither am I against aaronpk’s use of -p3k-
#
Zegnat Have a good night all
#
KartikPrabhu night
#
tantek Zegnat, implied does not equal actual
#
tantek go look at the CSS vendor prefixes example
#
tantek mf2 vendor prefixes are pretty much the same
#
tantek note that CSS *separately* has an @namespace directive and actual "namespaces" support
#
tantek which have NOTHING to do with vendor prefixes
#
tantek "-p3k- was very close to the bound prefixes anti-pattern " <-- no, because using the prefix -p3k- does not *bound* / bind it to anything
#
tantek so it is not close at all
#
tantek it only appears so in terms of being a string prefix, which is all it is, nothing more
#
KartikPrabhu moving on from the namespace stuff, what is the prefered solution to the -p3k- problem?
#
KartikPrabhu p3k-bug like the y2k-bug
#
tantek KartikPrabhu:I already gave my suggestion above
#
KartikPrabhu right this should be an issue on the parsing issues repo
#
tantek before we got into trying to explain the conceptual confusion which is tantamount to being confused as to why aren't all rectangles squares?
#
tantek (much worse actually, but that's the simplest summary)
#
KartikPrabhu lol
#
tantek no seriously, it happens all too often in webdev type stuff, why isn't x just y?
#
KartikPrabhu i know
#
KartikPrabhu i usually walk away. this time I did use the wrong terminology
#
tantek well maybe look at the definitions and try to understand instead of asking everyone to teach you?
#
tantek if someone kept saying "square" when they meant "regular polygon" it would sound just as dumb
#
tantek or vice versa
#
KartikPrabhu reorganised mf2py code to do VCP in a separate code file for future sanity
#
gRegorLove tantek: later today I can start a microformats2-parsing issue re: allowing numbers in the vendor prefix, unless you're already working on that.
#
tantek gRegorLove: go for it
[cleverdevil], echarlie, globbot, CaseD[m], vivus, [kevinmarks], sebsel, gRegorLove and tantek joined the channel