#aaronpkit's unfortunate we didn't get this into the parsers from the very beginning, but the idea is that the "value" property should always be a useful fallback if you don't understand what the object is
#aaronpkso for comments/salmention, if you don't go into the h-cite object and get the attributes from there, you could just use the "value" of the h-cite
#aaronpkwhich is now the URL if the object is "u-comment h-cite"
#gRegorLoveKartikPrabhu: If you have a neested h-*, the parent h-* value should be the p-name of the child, for example
#KartikPrabhuif you are parsing a comment why not have the palin text as fall back?
#KartikPrabhugRegorLove: yes. so if I have a nested h-cite the value will be whatever p-name it has
#gRegorLoveDepending on the parser prefix. Only if you use p-
#tantekit does say why u-comment. just doesn't say why u-comment vs. all other possibilities
#aaronpkfrankly I don't find the explanation of "because comment discovery" compelling
#tantekalso for a native comment - you probably want p-comment h-entry anyway
#aaronpkand I definitely do like having justifications for things when I'm reading these, otherwise I just think "eh that seems like extra work, why bother"
#gRegorLoveFurther confusing to people coming across a 'how to markup' section :)
#aaronpki think we need a "how to mark up native comments" section too :)
#aaronpkironically i'm pretty sure I was the one that pointed out it was better to use "u-comment", and now I don't even remember the actual reason other than it was related to salmention
#tantekbecause for salmentions you care about the URL of the comment being updated
#aaronpkbut I can't rely on the value being useful because it isn't always guaranteed to be a URL
#tantek(as in an addition for indiewebify.me - test your comments markup on your h-entry)
#tanteksure - we should diagram what happens with a "native" comment and salmentions - and what should happen
#kylewmwell you're only falling back to "value" if you don't recognize the object you want anyway
#tantekkylewm - or you don't even bother looking for the object
#aaronpkthe problem is more apparent when you consider that the "comment" property of the h-entry may be both a native comment or a webmention comment
#tantekthat's the point - to not have to care about the nested object if you don't need those details
benwerd_ joined the channel
#aaronpkif we can make the h-entry spec say that the value of the "comment" properties must always be a URL, then as a consumer I can always expect a URL as the value, whether there's an h-cite, h-entry or it's just a URL
#aaronpkfor native comments, the URL of the comment might be a fragment ID which is fine
#aaronpkthen h-cite becomes a way to augment the "comment" value with additional data beyond the comment's URL
#aaronpkthat's how I imagine effectively using the "value" fallback
#aaronpkdoes that make sense? I can try to re-word if necessary
#KevinMarksgiven a mf2-parsed output of a page, extract certain kinds of indie-useful structure
#aaronpkone could write a generic "get_value" function which is basically: if(is_string(property)) return property; elseif(is_object(property)) return property.value
#KevinMarksso do we define those as a json->json mapping
#KevinMarksor a json->html mapping (for injecting into the page)
#KevinMarksif we want them to be testably consistent across languages, I mean
#aaronpkjson->json maybe, like defining a super simple JSON structure that corresponds to a "comment"
#aaronpkthen writing a funciton that turns one element of an h-entry's "comment" properties into that structure
j12t joined the channel
#KevinMarksand then the 'how to markup' part mappingback into html is a template of choice issue
#KevinMarksthe salmention issue makes this concrete as it does assume some kind of html->json->html->json->html cycle
#aaronpkyes. well, html->parsed->html->parsed->html. JSON is not actually part of the picture
#aaronpknowhere in my code does the HTML page actually get transformed to JSON, it gets parsed from HTML to native data structures
#KevinMarksOK, I'm using JSON as a shorthand for 'dynamic language structure'
#KevinMarkswhich I suppose is python/javascript bias
#aaronpkyea, just wanted to be explicit for the logs ;)
#mapkyca(very) minor point re: https://indiewebcamp.com/IRC as I'm looking at it right now.. Port is listed as 6667 on the set up details. Any reason we don't point folk towards 6697, which is the TLS endpoint?
Sebastien-L joined the channel
#voxpelliDo any Microformats parser parse any language properties?
#voxpelliThinking I want to be able to post both English and Swedish stuff over Micropub so would want to use the same format
#joskarvoxpelli: The parser I wrote last year parses language properties. (not open source though, and is undergoing a rewrite at the moment)
#joskarvoxpelli: (I've tried doing some multilingual stuff on my web page)
#voxpellijoskar: my blog has a somewhat weird attempt at having Swedish content within an otherwise English site – valid HTML, but probably a bit hard for a consumer to understand
#joskarHaven't seen those before, but mine being written last year I don't think it would comply with that anyway (and the language properties doesn't even translate to something remotely JSON...)
#joskarThat page will be good when I'm rewriting my parser though, thanks :)
#voxpelliI think the Node.ja, Python and PHP parsers all produce the output there – and Micropub consumes data in a similar format
#Loqivoxpelli meant to say: I think the Node.js, Python and PHP parsers all produce the output there – and Micropub consumes data in a similar format
j12t joined the channel
#joskarIs there a way to express language properties of the strings in JSON?
#voxpellijoskar: the language probably has to be expressed as a property of the parsed h-*
lewisnyman joined the channel
#joskarvoxpelli: So, a simple "lang": as a sibling for the "type": would be enough then if a lang= attribute was found on the h-* tag? (or possibly on the *-content tag)
mlncn joined the channel
#voxpellijoskar: either that or having it as a key in the "properties", my initial thought was the latter
#glennjonesvoxpelli By default my parser provides text as trimmed textContent as per spec, but there is a switch to collapse whitespace where the output is much more usable http://glennjones.net/tools/microformats/ which I always use when consuming microformats
#voxpelliglennjones: does it also expand whitespace for eg. <br>?
#voxpelliglennjones: I see, it does it for block level tags but not for br I think – anyway – would be great to spec that functionality out as something standard-like
#voxpellishould preferably be the standard way to parse microformats
#voxpelliglennjones: I think it could make sense independent of the microformat spec – all parsers that wants to extract text out of plain HTML needs to do somehting like that
#glennjonesYes will do, once I have finished the work I am currently doing on the parser for Mozilla, I will try and have a look at formalising and document this way of handling text
#csarvenfoo bar { } (where bar is a descendant of foo), foo > bar { bar is first child of foo), foo + bar (bar is a sibling of foo, where they have the same parent)
#jonnybarnescsarven, the + rule is what I wanted, thanks
#csarvenYes, but it can be better e.g., if the object in question to which replying to is given more context (e.g., prominent size, location in contrast to everything else). So, one way to do that may be to simply keep the width of the replied space less than or equal to the width of the object's width it is replying to
#Loqipetermolnar meant to say: hm... I didn't really think it trough that importing all my last.fm scrobbler may stress my database a bit
tilgovi, snarfed1 and gRegorLove joined the channel
#voxpelliaaronpk: KevinMarks: would just using a new "lang" property (for micropub) and eventually getting parsers to set it to the implied value of the html lang attribute be a good solution?
tilgovi joined the channel
#aaronpki would want to see what the parsed microformats version looks like before adding a micropub property
#KevinMarksthe trickiness is that lang could apply to an individual property rather than a whole h- object
#aaronpkyou know how when there's e-content, the value ends up turning into an object? maybe the same could be true for lang
#Loqislack/tantek: The Lang stuff is interesting. Note that we ran into obstacles when we tried similar approaches with capturing the shape and cords attributes from area into the parsed mf2 JSON.
#Loqislack/tantek: Limiting Lang to h- and e- is an interesting approach. Not sure of such a limitation is reasonable though eg for plain text notes in other languages.
#aaronpki am not a fan of limiting to h- and e-, im going to add some more notes to the brainstorming page
#Loqislack/tantek: Point being, is this approach limited to lang or can we use it for other attributes too?
#aaronpki also think that if suddenly any property can be a string or an object ({"lang":"en","value":"foo"}) then consuming code will end up being more robust and vocab-agnostic
#Loqislack/tantek: Yes because rel 'value' as the text inside the a element would be very confusing. (Rel values mean the things in the rel attribute.)
#Loqislack/tantek: And p- 'text' could also be u- 'text' which is confusing because the u- is more likely to be a URL rather than just the "text".
#Loqislack/tantek: Tose are my reasons for being ok with the apparent inconsistency. Each works better in its context.
#Loqislack/tantek: Just wanted to raise that before anyone else did and think/work it through. Not sure if it needs an FAQ or some other note on the wiki.
#voxpelliadded a PR for experimental parsing of languages to the microformat-node project now + documented it at the wiki so I think I've done what I can about that issue for now – guess I'll wait for feedback from aaronpk and others now :)
#Loqislack/tantek: Also cassis num_to_sxg handles negative numbers.
#snarfedheh, you're both right. both have drawbacks. line number at HEAD will eventually point to a different line than the one you want. line number at a commit won't, but the file it shows will eventually be stale.
#tantek.comedited /Atom (+122) "/* Echo */ use archive.org link because this post (and the comments) are too much of a historical gem not to surface" (view diff)
#tantek.comedited /Atom (+939) "/* RSS Atom wars */ opening shots, cite comments, provide analysis, and prescient quote!" (view diff)
#tantekcool - I can now use tantek.com/github/cassis rather than linking to github.com/tantek/cassis - question - is this a bad idea URL management-wise?
#tanteksimilarly I've been able to use tantek.com/w/ instead of links to pbworks, thus creating links I control rather than they control, but that was easier as it was just a flat space of named pages
#csarvenMy reasoning was that, if github disappears, or you want to change the service or even the versioning system, it doesn't need to be tied to cassis in any way.
#tantekright, that's a good reason to do my own /source URL design *at some point*
#tantekyet as a stopgap, it's reasonable to use /github - and just copy / depend on their URL design
#tantekbecause eventually if/when I switch to /source, I can redirect all the /github links to whatever URL design I come up with in the future
#tantekbut this was a good exercise to prove that a) I am dependent on github's URL design for now, and b) I can delay design of my own /source path until the point in time when I feel like doing so.
#aaronpki'm running not one, but two GItlabs right now
#atomiculesAny new projects I'm using Fossil for and self-hosting. I'm keeping Github for my legacy projects.
#tantekditching github is not really practical until you have that working, unless you don't care about the "github community", which frankly, is the biggest reason most people use it, even those that would normally self host (e.g. W3C)
#tantek.comedited /User:Tantek.com (+871) "note silo use of Github, incremental indieweb steps (using URLs where I own the domain, then generic path, redirects, owning my repos etc.)" (view diff)
#kylewm"In addition to doing distributed version control like Git and Mercurial" is ambiguous
#tantekatomicules: another question while you're here, do you know when you first started POSSEing to Flickr? Could you provide a photo post permalink on your site of an example and the Flickr POSSE copy permalink also? https://indiewebcamp.com/Flickr#atomicules
gillisig, bigbluehat, KartikPrabhu and scor joined the channel
#tantek.comedited /timeline (+285) "/* 2011 */ add W3C Workshop on Identity in the Browser, tangentially indieweb related (web identity), but just a month before first IWC, and I attended/presented" (view diff)
slvrbckt, benwerd and KartikPrabhu joined the channel
#tantek.comedited /code-of-conduct (+617) "open code of conduct subsection - how to use IWC code of conduct for your own org - please review!" (view diff)