#microformats 2019-02-08

2019-02-08 UTC
[jgmac1106], nitot, [tantek], [cleverdevil], [eddie], [kevinmarks] and tantek joined the channel
#
@jgmac1106 ↩️ Back to xAPI, idea of e just being CoP and inventing vocabularies sounds freeing but opposite of metadata's task. Reason I got attracted to microformats (after I knew about #IndieWeb) could not understand massive … https://quickthoughts.jgregorymcverry.com/2019/02/08/downes-benwerd-back-to-xapi-idea (twitter.com/_/status/1093682273956909062)
[tantek], nitot, tantek, [cleverdevil], [eddie], [benatwork], [manton], aaronpk, [jeremycherfas], mickael, [Vincent], [kevinmarks], [svandragt] and jgmac1106 joined the channel
#
@psd ↩️ Indeed. Microformats were onto something; they work best with such publishing tools and quick feedback from other people consuming the data. (twitter.com/_/status/1093825488399798272)
nitot joined the channel
#
@jgmac1106 ↩️ I would go with are over "were a good" idea. Many of use microformats to drive the modern social web as alternative to corporate silos and search engine who usually push us based on their profit needs not our people needs. (https://quickthoughts.jgregorymcverry.com/s/1ZouxN) (twitter.com/_/status/1093829990444089344)
mickael and [jgmac1106] joined the channel
#
Zegnat sknebel: are we not already tracking author as a property on h-event? I feel like there is a github issue that I put some research in?
#
Zegnat Because I was seeing h-event alongside h-entry within feeds, sharing many properties
#
Zegnat Hmm, I was thinking of https://github.com/microformats/h-event/issues/2#issuecomment-308650834
#
Loqi [Zegnat] Does it become significantly harder to change properties after “flipping the switch”? If so (I am not fledged in the Microformats processes) we might need to do some changes to h-event first. The current draft specification does not adress usi...
#
sknebel Zegnat: didn't see any reference to that from the wiki page, which is what i looked at
#
[jgmac1106] and i would assume p-orgainzer goes into an h-card but this would be different than post author h-card
#
Zegnat You could have an h-card as the value of the organizer, yes
#
Zegnat you could even have both author and organizer, and have both be an h-card. Or even multiple h-cards for multiple organizers (or multi authors, though we have no published examples of that)
#
Zegnat Mix and match, [jgmac1106] :D
#
jgmac1106 yes I would assume two h-cards, unless author and organzier the same but stil my default to two just to make temoplating easier
barpthewire joined the channel
#
jgmac1106 I think it would be either p-organization or p-organizer or would the h-card for an organization who organized be<div class="p-organizer"><p class="h-card"><span class="p-organization">IjndieWeb</span></p>?
nitot, mickael and [Rose] joined the channel
#
Zegnat <div class="h-event"><a class="p-author p-organizer h-card" href="https://vanderven.se/martijn/>Martijn</a></div>
#
Loqi Martijn van der Ven
#
Zegnat Would be if I authored the event post, and am the organiser
#
Zegnat Might want to swap to u-author and u-organizer
#
@jasonopus ↩️ I’ve been playing around with post formats and layouts to achieve a microblogging look/feel and I’m using microformats where I can. Unfortunately, no webmentions since there’s currently no plugin for them in #craftcms. (twitter.com/_/status/1093877374062612483)
bradenslen, [kevinmarks], [schmarty], [frank], [eddie], [tantek], [jgmac1106], [jeremycherfas], [tmiller] and [Coty_Beasley] joined the channel
#
[tantek] Zegnat is correct
[schmarty] joined the channel
#
[jgmac1106] yeah I find I have to start with all the divs take time and channel my inner zegnat to get down to fewest elements and properties possible
#
Zegnat [jgmac1106], or you just start with the markup and content, rather than starting with what microformats you want to put in there. Let the content dictate the data :D
[cleverdevil] joined the channel
#
[tantek] Zegnat++
#
Loqi Zegnat has 21 karma in this channel over the last year (168 in all channels)
#
[jgmac1106] but I still have hardest time grasping the rules around u- vs p- in your minimal h-card you adding properties to the a element and I alays think link=u and text =p but that is p
[kevinmarks] joined the channel
#
[jgmac1106] and I messed up trying to do "u-url h-card"
Zee and nitot joined the channel
#
[tantek] aaronpk the mf2 spec already says all properties are plural. no reason to repeat that in every single property description.
#
[tantek] (moving generic mf2 discussion from indieweb dev to here)
#
sknebel for the vocabulary it makes sense to limit some IMHO, but it probably also makes sense to assume plural by default
#
Zegnat [jgmac1106], the big one to remember about is that if you are putting properties (u-*, p-*, etc) on an element that also is an object (h-*) those are properties of its _parent_ object. So <div class="h-entry"><a class="h-card u-author"></a></div> means the h-card is the author of the h-entry. If you want properties within the h-card, those have to be on nested elements.
#
Zegnat Properties must be on child elements of h-* objects, always
#
aaronpk no you're missing the point tantek
#
aaronpk this is not a parser question, it's a vocab, publishing and consuming question
#
aaronpk most of the descriptions of properties here http://microformats.org/wiki/h-entry have an implied numerality
#
Loqi [Tantek Çelik] h-entry is a simple, open format for episodic or datestamped content on the web. h-entry is often used with content intended to be syndicated, e.g. blog posts. h-entry is one of several open microformat standards suitable for embedding data in HTML. ...
[schmarty] joined the channel
#
aaronpk "p-name - entry name/title" implied there is only one name
#
aaronpk as an author, you need to know whether you should be putting p-name on only one element or if it's okay to have multiple
#
aaronpk "p-category - entry categories/tags" clearly more than one is allowed
#
aaronpk there are many cases where the description there does not match the in-the-wild usage as well
[tmiller] joined the channel
#
[tantek] it's literally possible to always publish multiple values for a property for any vocab
#
[tantek] vocabs don't get assert singularity
#
[tantek] that's part of the design of mf2
#
[tantek] consumers MUST be able to "handle it"
#
[tantek] even if that just means looking at the first item in the array and ignoring the rest
#
[tantek] implying singularity from the property descriptions is a deliberate misreading IMO
#
[tantek] I'd like to reduce the chance of that though
#
[tantek] maybe every "Properties" section in every vocab needs a short sentence.
#
[tantek] "All properties are multivalued. Implementations may treat the first value for a property as special if their use-case or semantics require it."
#
aaronpk :sigh:
#
[tantek] that way as a spec reader you must pay attention such explicit wording, instead of trying to guess at something by "implied" wording
#
aaronpk something somewhere needs to decide whether multiple values are allowed
#
aaronpk I really don't even care where that is anymore, but we need to write it down
#
aaronpk that's why this was an #indieweb-dev discussion not a microformats discussion
#
[tantek] no we tried that in mf1 and it resulted in breaking changes
#
[tantek] vcard3 also got that wrong and had to be fixed in vcard4
#
[tantek] turns out vocab usage evolves, and if you assert singularity, you most of the time get it wrong
#
aaronpk when you are building software, you ultimately are going to make a decision about whether you will use the first value of the list or use all the values. right now that is not written anywhere and is going to lead to a mess.
#
[tantek] in the end I think it's a UI-specific-to-your-consuming-app problem. not a format problem.
#
Zegnat For interop between specific consumer cases, I agree it is nice to decide that all readers will work with the first dt-published even if multiples are defined on the h-entry. The question is if you want to bake this into the mf2 vocab or not.
#
[tantek] if your UI only allows for one value, show one
#
aaronpk if we don't put it in the spec, then it will go in libraries
#
aaronpk if the libraries are making their own decisions things will be incompatible ultimately
#
aaronpk again this is why this was in #indieweb-dev
#
Zegnat (Readers just being an example of the type of apps the end user would probably expect to be in sync.)
#
[tantek] TBH better in a library than a spec, because libraries are more expected to make breaking changes
#
aaronpk i'm not necessarily advocating for this being in either microformats vocab or in libraries or in jf2. it just needs to be somewhere.
#
[tantek] I'm saying it's not a format issue at all. It's a UI issue. so it belongs in the UI design of each app
#
aaronpk and i'm saying I dont want to leave it to every app author to have to figure out what the heck to do
#
[tantek] similarly with the possibility of 0 values
#
aaronpk because it's not obvious at all right now
#
[tantek] also why "required properties" caused problems
#
[tantek] every app author has to figure out their UI. if we want to document UI patterns for folks to start with, that's fine
#
aaronpk that is what I am saying
#
aaronpk again that's why I was saying this in #indieweb-dev in the context of readers which use jf2
#
[tantek] great then it's not a library issue either, since app authors have to make their own UI decisions on top of a library too
#
aaronpk my idea of jf2 is that it takes these decisions into account because it's made for a use case and not as a generic transport
#
aaronpk that's why i've baked these decisions into XRay
#
aaronpk and I never said this should affect microformats parsing at all
#
aaronpk or microformats json
#
[tantek] the deeper you bake-in those decisions, the greater the chance of a bigger breaking change in the future
KartikPrabhu, mickael, [Rose], [manton], nitot, [jgmac1106], [eddie], [schmarty], [frank], [tantek], Zee, [cleverdevil] and [kevinmarks] joined the channel
#
[kevinmarks] I get both halves of this discussion. Maybe the answer is instead of jf2 being multiple different things, do a document for the microsub case and one for the webmention.io case
#
[kevinmarks] I'd like to converge mention.tech output with webmention.io output (and webmention.herokuapp.com output too ideally).
#
[kevinmarks] Then we can have a place to discuss cardinality with that focus.
#
aaronpk I don't see why those are different cases, especially since I use the same code for both
#
[tantek] I am kinda ok with a one-off feed format that makes more stringent assumptions
#
[tantek] however I am willing to bet some of those assumptions are already wrong
#
[tantek] e.g. "assume one title/name"
#
aaronpk really
#
aaronpk of all the properties *that* is the one you think might be wrong?
#
[tantek] nope. note = zero title/name. internationalized via lang attribute = multiple translations of title/name.
#
[tantek] yeah I deliberately picked on that one because people least suspect it to be wrong
#
[tantek] "of course there is only one title! how can there be more than one? there is never more than one."
#
[tantek] and by demonstrating how even that assumption is false, then it follows that the other assumptions are also likely false
#
[tantek] and we're back to plural all the things
#
[tantek] http://meme.loqi.me/m/4yvvGiq.jpg
#
aaronpk well until there's a good story for localized data in mf2 JSON i feel like that's not a good argument
#
[tantek] questions: 1. does your consuming client care about a UX that handles showing "note" posts? evidence would seem to suggest most feed readers don't care about being dumb about note posts. 2. does your consuming client care about showing translations of a post title/name? again, evidence would suggest no (none that I know of).
#
[tantek] yet should a format omit those just because current clients are lazy? no.
#
aaronpk also I never said "name" is required, where did that come from
#
[tantek] "there is one name"
#
aaronpk shakes head
#
[tantek] what is cardinality?
#
[kevinmarks] Well, it was there by default for a long time until we cleaned up implied name.
#
[tantek] back in the day, kevinmarks and I had fun pointing out to the vCard4 AKA VCARDDAV WG how many of their assertions of cardinality were wrong
#
[kevinmarks] I'm interested that mentions and arbitrary posts are the same case for you, as their presentations end up different a lot of the time.
#
aaronpk Notifications of mentions are very different, but the posts themselves are the same
#
[kevinmarks] Seeing fluffy's mention presentation script was interesting there.
#
aaronpk Things like "Tantek liked your photo" require quite a lot of steps to derive each word there
#
aaronpk authorship, post type discovery
#
aaronpk I don't have a name for what it takes to say "your" there
#
aaronpk cause sometimes it's "a photo you were tagged in" or "someone's photo"
#
[kevinmarks] I remember trying to converge this in opensocial and as1. Monica was very good at use cases
#
[tantek] Ooh aaronpk that’s an excellent insight “quite a lot of steps” ... “each word”
#
[tantek] Would likely look nice as a flow chart
#
[tantek] That assembles all the pieces with the notification sentence at the bottom in large text
#
aaronpk It'd be like an algorithm of algorithms
#
aaronpk to assemble a sentence
#
aaronpk that describes activities
#
aaronpk almost kike
#
aaronpk almost like
#
aaronpk an activity stream
#
[tantek] don’t get ahead or yourself.
#
[tantek] notification stream
#
aaronpk :-D
#
[tantek] Since as you pointed out, it does make some “your / you” assumptions
#
aaronpk No assumptions! It has to be careful about choosing when to say your
#
aaronpk depends on the webmention target and the properties of the post
#
aaronpk I got it wrong in webmention.io so I know this :-)
#
aaronpk it says some silly things
#
[tantek] No the assumption is that yes it does speak to your perspective
#
aaronpk it sometimes says "your" when it shouldn't
#
aaronpk because I made that assumption
#
[tantek] Sorry we are speaking past each other
#
[tantek] Different assumptions
#
[tantek] A notification text synthesizer can/should assume it is writing text directed at a particular person.
#
[tantek] Now the question of *when* it should or shouldn’t say you or your is a matter of algorithms
#
[tantek] This is kinda IndieWeb dev tho TBH
#
[jgmac1106] Or better content writing to avoid the situation all together
[eddie] joined the channel