#microformats 2024-07-30

2024-07-30 UTC
[qubyte], [Doc_Pop], jimw, [KevinMarks], barnaby, [Scout], _capjamesg[d], [aaronpk], gRegor and [snarfed] joined the channel
#
[snarfed] moving here from #indieweb-dev: parsing mf2 out of XML, eg https://github.com/snarfed/bridgy/issues/1766
#
Loqi [preview] [dannypsnl] #1766 Publish: support XML posts
max2 joined the channel
#
Zegnat The question when parsing for mf2 is what you would be looking for. Can you assume that any class attribute is the class we are looking for? Or should it be a class attribute that is specifically marked with an mf2 namespace?
#
Zegnat And if the question is about atom: is it about parsing mf2 from the xml, or from the (potentially) embedded html within the content?
#
[snarfed] sounds like we need to start collecting questions and thoughts like this in a new issue on https://github.com/microformats/microformats2-parsing/issues
#
sdcaulley Zegnat: It is about OpenWebIcons. I am trying to use them in my projec and not having much luck yet.
#
[KevinMarks] A possible case is microformats within the HTML inside an xml wrapper like Atom or ActivityStreams. Very old versions of the universal feed parser would extract vcards and ics from atom posts
#
[tantek] [snarfed] is correct. the mf2 parsing spec only specifies how to parse HTML for mf2. Thus if someone wants to parse XML themselves, and then when they find a chunk of HTML, hand that off to the mf2 parser, they can do that but it has to be HTML parseable by the HTML standard rules for parsing
#
[tantek] we could consider generalizing mf2 parsing spec to cover arbitrary XML but I'm not convinced there are sufficient use-cases (or that they are broadly important/interesting enough) to bother with the overhead of requiring every mf2 parsing implementation to add that support, when clients of mf2 parsing can do the XML parsing themselves
#
[tantek] In this case, Bridgy Publish is one such client of mf2 parsing, and it should make the "product" decision that is best for Bridgy Pub in terms of does it matter to BP to support consuming XML or not (what use-cases) and how much does it matter (is it broadly applicable or is it someone's academic experiment?)
#
[tantek] BTW since the HTML standard parsing rules already cover parsing SVG and MathML inside HTML, each of which have their own class attributes, that's already covered for those "common" XML-ish use-cases
#
[tantek] [KevinMarks] I have yet to see user-relevant use-cases for having an mf2 parser directly parse Atom or AS1/XML that would justify that. Turning them into h-feeds? That seems like a custom application and not necessary to include in every single mf2 parsing implementation
#
[KevinMarks] That seems reasonable. If I get back to hacking on feedparser again, adding h-feed support would then have the dependency in place to do the same for Atom/RSS.
#
Zegnat I would personally not merge it into a single parser implementation. I would leave the file type detection to the consumer, who can then pick the correct mf2 parser. (Ie. either an HTML or XML based parser.) So rather than expanding every mf2 parser, I would see (if the usecase exists) which steps need to be taken to go from XML->mf2 json
#
Zegnat sdcaulley: if you have problems using the icons, maybe #indieweb-dev is the right channel to ask for help with the icons :) Probably someone there who uses (some form of) icons
grubz joined the channel
#
sdcaulley Zegnat: I will ask...thank you.
btrem, grubz and [benatwork] joined the channel