#microformats 2018-04-03

2018-04-03 UTC
[kevinmarks], vit_, [miklb], j12t, j12t_, KartikPrabhu, tantek, barpthewire and sebsel joined the channel
#
Zegnat (And that is with 3 todos still standing.)
#
Zegnat (This is why I do not want to require WHATWG innerText for the parsers, code required just to do the very first check in the algo: https://gist.github.com/Zegnat/4fcfff20741a5f78a73bc7b717fd8396/58f8c7f3dfa6987c52f3cd35a3dc0247076bc935#file-pleaseno-php-L33-L68)
j12t, [jgmac1106], [mrkrndvs], [kevinmarks], tantek and [manton] joined the channel
#
aaronpk hm, first example here is not a good example http://microformats.org/wiki/microformats-2#VENDOR_EXTENSIONS
#
KartikPrabhu Zegnat: for the minimal stuff I am doing see https://github.com/kartikprabhu/textContent
#
Loqi microformats2
#
Loqi [kartikprabhu] textContent
#
KartikPrabhu does not work correctly yet
#
KartikPrabhu also can try it out here https://kartikprabhu.com/connection/textcontent
#
aaronpk same with http://microformats.org/wiki/microformats2-prefixes#vendor_extensions
#
Loqi microformats 2 prefix conventions
#
tantek looks like we need to do some gardening for those two pages to get them either more in sync with or linking better to http://microformats.org/wiki/vendor-prefixes and http://microformats.org/wiki/microformats2-faq#how_do_you_use_experimental_microformats_and_property_names
#
Loqi vendor-prefixes
#
tantek aaronpk: I think the first one ( http://microformats.org/wiki/microformats-2#VENDOR_EXTENSIONS ) describes the *background* of vendor extensions and likely belongs in more of a historical section or page
#
Loqi microformats2
#
tantek for folks that want to read back to how we came up with them
#
aaronpk yeah but those are the first places I found trying to look up how to do vendor prefixes
#
tantek aaronpk, since microformats2 started as a brainstorm, and then got incrementally formalized, there's a dividing section between the top of the page (more formal) and the original brainstorming: http://microformats.org/wiki/microformats2#About_This_Brainstorm (note that VENDOR_EXTENSIONS is below that on that page)
#
aaronpk I just did a search for "vendor" on the page
#
aaronpk :)
#
Loqi microformats2
#
aaronpk nobody reads pages in order ;-
#
aaronpk )
#
tantek yes that's reasonable
#
tantek created /microformats2-origins (+23268) "move origins brainstorming and background from the main microformats2 page to reduce confusion" (view diff)
[kevinmarks] joined the channel
#
tantek edited /microformats2-brainstorming (+410) "original brainstorming see * [[microformats2-origins]], note long ago accepted/rejected brainstorms, update doc url idea," (view diff)
#
tantek edited /microformats2 () "(-21780) add [[vendor-prefixes]] to see also, move original brainstorming to origins" (view diff)
#
tantek aaronpk please retry your search :)
#
tantek hopefully the above updates will make it easier to find the right information faster in the future
#
tantek (long overdue cleanup of [[microformats2]] page)
#
aaronpk wow much better
#
tantek edited /microformats2-origins (+83) "update contextual prose in about section per content move and current state" (view diff)
#
tantek edited /listing-examples-fr (-199) "Reverted edits by [[Special:Contributions/Billchilds|Billchilds]] ([[User talk:Billchilds|Talk]]) to last version by [[User:Brian|Brian]]" (view diff)
#
tantek edited /Special:Log/block () "blocked [[User:Feep1996]] with an expiry time of infinite (account creation disabled): Spamming links to external sites" (view diff)
#
tantek edited /Special:Log/block () "blocked [[User:Blinqdigital]] with an expiry time of infinite (account creation disabled): Spamming links to external sites" (view diff)
[jjdelc], [kevinmarks], echarlie and [aaronpk] joined the channel
#
@rahelab ↩️ I want a site that uses microformats and easy RSS or API so that I can import my speaking (history and future) into a single place. So far, no joy. (twitter.com/_/status/981245280887758850)
[stefp], KartikPrabhu and GWG joined the channel
#
gregorlove edited /vendor-prefixes (+155) "/* Proposed */ link kevinmarks -schema post" (view diff)
[mrkrndvs], [jgmac1106] and webchat254 joined the channel
#
Zegnat Why do those vendor prefixes start with a - on /vendor-prefixes?
#
tantek because they're more easily recognizable that way
#
tantek should we have (still time?) used -- ? e.g. h--p3k-whatever?
#
tantek or p--p3k-special to distinguish from things like p-country-name ?
#
tantek with kevinmarks's generic sounding -scheme- vendor prefix, and I thought I saw somewhere a -swarm- prefix, it may be worth making it more obvious when things are vendor-specific
#
tantek we could grandfather in existing-in-wild vendor prefixes to avoid breaking any existing content
#
tantek I think that might only be -p3k- but not sure
#
tantek aaronpk: thoughts ^^^ ?
#
aaronpk double dash looks weird
#
Zegnat I don't think that's necessary. Well thought about names should make it clear when something functions as a prefix. I wouldn't change anything.
#
gRegorLove +1 for keeping as-is
#
tantek or we further segment like h-v-p3k-something
#
gRegorLove -swarm- prefix is on /vendor-prefixes
#
Zegnat I was just asking about the page because we never refer to things with a leading dash. E.g. we do not say -author. Either *-author or just author is what we usually use. So the -p3k- stood out to me.
#
aaronpk now that you mention it, I don't understand what "-swarm-coins" means
#
Zegnat x-swarm-coins where x is a parsing prefix. Surely?
#
aaronpk it's "swarm-coins" in the parsed JSON, and "p-swarm-coins" on the page, so omitting the letter but leaving the dash doesn't really make sense
#
Zegnat Yeah. That's what I meant. We never use that notation, AFAIK
#
tantek aaronpk the JSON output is part of the reason for the - before
#
tantek so it would be p--swarm-coins in the page, and -swarm-coins in the JSON
#
tantek this way it is more obvious in the JSON which things are/were vendor specific
#
tantek instead of all looking the same
#
aaronpk hmm
#
Zegnat Is there any demand for that though?
#
aaronpk I will say, I didn't actually intend to use "swarm" as a vendor prefix for that example, I was just writing a property that was descriptive of what it was, and it happens to follow the vendor prefix conventions too
#
Zegnat I'd say don't change things and let property names (with or without prefixes) grow naturally. If a need arises for starting dashes, we'll tackle it then.
#
tantek aaronpk, your use of "swarm" kinda proved the point though - as now it looks like just another multi-word property
#
tantek Zegnat, no something like this you want to do "early" before you have a ton of rando vendor prefixes out there making it more confusing
#
tantek this isn't a demand thing, this is a reduce potential harm thing
#
tantek and the prior art is that CSS did this deliberately
#
tantek even though in that case the prefixes were more "obvious" like ms-
#
tantek and opera-
#
tantek that's another good reason actually, web developers are used to seeing and recognizing leading -* names as vendor prefixes like -webkit-appearance
#
tantek so it makes to keep that kind of distinction in the parsed JSON output of microformats
#
tantek from [manton]'s questions it sounds like we are going to see more vendor-prefix usage soon
#
aaronpk is swarm really a vendor prefix in that example though? I thought vendor prefixes were for producers and consumers to add data that no other systems are expected to consume
#
Zegnat So the idea is that x--swarm-something is clearly vendor prefixed as opposed to x-swarm-coins which is just a generic descriptive property name?
#
aaronpk and in that example swarm has nothing to do with the production or consumption of the data
#
tantek Zegnat correct
#
tantek aaronpk - you're making my point.
#
aaronpk lol what
#
tantek you're using "swarm-" as *not* a vendor prefix but just something specific to them
#
aaronpk but it has nothing to do with swarm itself
#
tantek your rhetorical "is swarm really a vendor prefix in that example though? "
#
tantek makes the opint
#
tantek right
#
aaronpk whereas in manton's example he's talking about explicitly adding something for micro.blog clients to consume from micro.blog servers
#
tantek if there was something that had to do with swarm itself, it should use -swarm-
#
tantek aaronpk - that's exactly the kind of distinction that -- would help make
#
tantek between manton's use of micro.blog (vendor specific) and your use of swarm- (just happens to be for a special type of content)
#
aaronpk interesting
#
KartikPrabhu wait vendor-prefixes should show up a "-prefix-property" in the JSON!?
#
Zegnat They already show their prefix, KartikPrabhu. It is whether they should be set apart from non-redirecting properties by having them start with a dash.
#
tantek KartikPrabhu: just like in CSS you see -webkit-appearance or whatever
#
tantek Zegnat what does non-redirecting properties even mean?
#
KartikPrabhu <sigh> this is going to be a pain to implement
#
Zegnat That is the autocorrect for non-prefixed, apparently, tantek
#
tantek no - because of the p3k change
#
tantek it should be easy
#
tantek there is already a custom RE for the vendor prefix
#
tantek we simply add the "-" in front of it
#
Zegnat I just rolled into bed so writing from my phone now. Programming terms don't do well on autocorrect.
#
KartikPrabhu the RE does not seem to distinguish between p-country-name and p-p3k-name currently in mf2py at least
#
KartikPrabhu RE - regex right?
#
tantek right
#
tantek and I meant as in the spec
#
tantek it has to be different to allow for numbers in the vendor prefix and NOT in other property names
hober joined the channel
#
KartikPrabhu how does one distinguish if the "country" in "p-country-name" is a vendor prefix or not?
#
KartikPrabhu or "p-myapp-name"
#
tantek KartikPrabhu: that's exactly the problem currently
#
tantek which is what the extra "-' fixes
#
Zegnat I am going to sleep on this as I'm already in bed. My first thought is that with mf2 being very generic and people being encouraged to experiment with new properties I wouldn't expect extra punctuation marks to be something people will start to use.
#
Zegnat Looking forward to the logs in the morning ;-)
#
tantek Zegnat, that's a good thing, we should discourage proprietary properties
#
tantek especially use among authors
#
KartikPrabhu so vendor prefixes are authored as "p--myapp-name" ?
#
gRegorLove That's the suggestion, yes.
#
KartikPrabhu I don't see any reason for this
#
KartikPrabhu anyway, if this is changed someone just give me the new regex
#
gRegorLove Link to this conversation with manton and vendor prefixes?
#
gRegorLove I think this is it: https://chat.indieweb.org/dev/2018-04-03#t1522769415855100
#
Loqi [[manton]] [aaronpk] I'm surprised I've never run into this, but is there a prefix convention in Micropub for custom fields in JSON that are likely server/client-specific and not really proposals for broader support? In q=config for example, I was considering a...
#
KartikPrabhu yeah that is fine. but still don't see why the extra "-"
#
KartikPrabhu if someone wants to consume "p-microblog-name" that seems ok
#
tantek KartikPrabhu: so it's obvious in the JSON results as a vendor prefixed property
#
KartikPrabhu yeah but why is that needed?
#
KartikPrabhu what's the use case for making this obvious or something?
#
tantek to avoid having vendor prefixed properties seem "official" and get misrepresented uptake accordingly
#
gRegorLove Implementing double-dash should be easy enough. I'm still not clear on examples of what it solves, but not necessarily opposed.
#
tantek KartikPrabhu: the CSSWG likely has more well documented reasons from like 15+ yaers ago
#
tantek for why we have -webkit- and -moz- etc.
#
KartikPrabhu <shrug> if someone gives me the regex I'll use it in mf2py
#
tantek gRegorLove: when companies pick generic terms as names and then potentially vendor names
#
gRegorLove I could see it being a problem if Swarm themselves started using p-swarm-coins for something official and thus it conflicts with aaronpk's non-vendor-prefix use of it.
#
tantek or a (artificial example) company named "country"
#
gRegorLove Gotcha
#
tantek or "postal" or any other existing first word of a multi-word property
#
gRegorLove The double-dash would also avoid artificial example `p-c0untry-name` getting parsed.
#
tantek true
#
tantek and thus it would help make stricter generic validators
#
tantek to catch earlier typos in both vendor prefix usage and normal property usage
#
gRegorLove nods
#
gRegorLove I think I'm neutral-to +1 on double-dash then.
#
KartikPrabhu is now not sure when hypothetical examples, perceived future use-cases and stricter validation are counted as arguments
#
tantek KartikPrabhu: those are all good questions
#
tantek one difference is when exploring the fragility of an existing feature (making it more robust), vs proposing a new feature
#
tantek also good to use past experience of other specs / syntaxes (in this case, CSS)
#
KartikPrabhu CSS vendor prefixes are now no longer encouraged btw
#
KartikPrabhu (I think)
#
tantek not by themselves, no
#
KartikPrabhu so using experience of CSS we should not add extra "-"
webchat254 joined the channel
#
tantek KartikPrabhu: huh? CSS exactly added the extra "-" after it was clear that no "-" extensions like "ms-" were easily mixed up with other properties
#
tantek CSS added the dash before
#
tantek from "ms-" to "-webkit-"
#
KartikPrabhu yes, and from the CSS experience, the extra dash did not deter people from using them like normal properties
#
tantek no it helped for a while
#
tantek as in you saw very little -ms- usage after that
#
tantek the problem of using them like normal properties happened not because of syntax, but because Apple came out with so much new functionality with -webkit- that people felt compelled to (and CSSWG took too long to standardize them)
#
KartikPrabhu ok, not my hill
#
tantek KartikPrabhu: no that's not my point, my point is that the history is there if you want to explore it
#
KartikPrabhu the way I see the history, extra dashes are of little help eventually
#
KartikPrabhu but <shrug>
#
tantek "eventually" if the features are ignored by standards bodies yes
#
tantek it does mean that anything that appears to start taking off, we should actively look to standardize and not repeat that mistake of CSSWG
#
KartikPrabhu right. extra dashes have not taken off
#
KartikPrabhu we are preempting their use
#
tantek do you mean the - in front of the vendor prefix? because that's exactly what did take off "-webkit-"
#
tantek and now it's a big compat problem (browser have to support it)
#
tantek but only because the error was in not spending *time* standardizing. the error wasn't the syntax
#
KartikPrabhu I mean in the context of mf2
#
tantek yes we are pre-empting the potential take-off of vendor-prefixes that are confusingly named like real standardized properties, especially in JSON output / interop
#
KartikPrabhu oh well.
#
KartikPrabhu as I said I no longer know what the rules for this argument are. so I'll just go back to work
#
tantek in this case the evidence is past harms that occured, were repaired, then went wrong for other reasons
#
tantek while CSS is not microformats, it is similar enough to be worth conservatively erring on the side of re-use of the CSS -vendor- syntax rather than assuming our own "vendor-" is good enough (since they also experimented with that)
#
tantek if you have reasons why you think it would turn out differently for mf2 than for CSS, I'd be interested in hearing them
[kevinmarks] joined the channel
#
[kevinmarks] If we use -- won't that get false positives from the more rococo css conventions?
#
[kevinmarks] BEM for example
#
[kevinmarks] Also custom properties use leading -- which isn't a clash but may be confusing
j12t joined the channel
#
KartikPrabhu [kevinmarks]: I thought BEM uses single dash in the first separation and double in the second
#
[kevinmarks] button--state-success
#
Loqi button has -1 karma
#
[kevinmarks] Hah
#
KartikPrabhu hmmm
[aaronpk], [cleverdevil], KartikPrabhu and [tantek] joined the channel
#
[tantek] Lol
#
gRegorLove Do those type of CSS rules start with p-, u-, e-, dt-, h-?