[iambismark], [matpacker], renem, [chrisaldrich], [cleverdevil], tantek__, ben_thatmustbeme, miklb_ and [eddie] joined the channel; mblaney and miklb_ left the channel
LoqiIt looks like we don't have a page for "event embed" yet. Would you like to create it?_ (Or just say "event embed is ____", a sentence describing the term)
LoqiIt looks like we don't have a page for "calendar embed" yet. Would you like to create it? (Or just say "calendar embed is ____", a sentence describing the term)
tantek__calendar embed is a feature of [[event]] hosting sites that allows a series of events (sometimes just one) to be embedded into another site, supported by [[silos]] like [[Google Calendar]], [[Eventbrite]], and [[Facebook]].
Loqi[Michael Bishop] Tonight is our first Open Hack night to pick up where we left off from National Day of Civic Hacking. We’ll be meeting every Wednesday if you can join us this week.
tantek__miklb, definitely, looks like a meetup embed! would be great example to add (or maybe it's worth splitting off /event_embed as a separate thing?)
Ruxtontantek__: indingenous reader on Android shows RSVP action for events, starts a new RSVP post where you select yes/no/maybe/interested - https://puu.sh/Bin2c/bdcb4f9c92.png
tantek__Ruxton: that is very cool! If you have my site in your reader, did you see such buttons for the recent indie event I posted (2nd to most recent post)
petermolnarZegnat: you've recently had an interesting CSS experience, it seems like I'm having one as well: the 3px bottom border on my site's main menu are becoming trapezoids o.O
ZegnatYeah, og: was discussed as an option, the biggest downside of og: is that there wasn’t a way to identify a page as an application unless we wanted to define our own namespace :(
GWGI just assume many web pages end up putting in og:title for other reasons, so if nothing else is there, I pull it as it is often better than the title tag
ZegnatNot sure what the good way is to fallback to application-name when you don’t know what language to pick. Especially if you maybe are taking other information from the manifest file, as you have no way of knowing what language manifest file you were given.
ZegnatThere is an interesting problem with the application-name fallback as well. application-name can explicitly be multilingual per HTML spec (which is amazing!) but web app manifest has removed all multilingual aspects, recommending instead the server supplies separate manifests for separate languages.
sknebel(which is interesting: make the requests to find the manifest with set language headers to get the right one? is that how the manifest discovery is supposed to work?)
ZegnatBut its a bit double edged. Say you `accept-language: la` and get a manifest file back. You have no idea if the website really did offer a Latin version, or just gave you their default. And if they gave you their default, what language application-name fallback do you use? You don’t know their default.
LoqiInternationalization (AKA internationalisation, i18n; localization, l10n.) is the process of adapting software/content to various languages https://indieweb.org/i18n
Zegnatsknebel, yeah, it is proposing a different way of doing the same i18n. I am just not sure it is a better way. How often do we see conneg go right? How many are going to craft multiple manifest files? I think there was probably a reason for the HTML5 way of offering translations within the same document.
ZegnatThis is why I didn’t like HTML Purifier: it has both ForbiddenAttributes and AllowedAttributes configurations. Hard to figure out exactly where it would be removing what
aaronpkthe actual post is more like <div class="h-entry"><div class="e-content"><p>sample emoji <img src="emoji.png"></p></div></div> so doesn't trigger it
LoqiPost Type Discovery specifies an algorithm for determining the type of a post by what properties it has and potentially what value(s) they have, which helps avoid the need for explicit post types that are being abandoned by modern post creation UIs https://indieweb.org/PTD
ZegnatThat’s the full answer ^^^ the micropub endpoint could run PTD on the mf2 object it recieved. This will tell it if it was an article or note (or something else entirely)
tantek__Zegnat: re: WAM and fallback, I think we should only do the fallback in the spec (meta application-name, link rel icon) and not go down the path of rando proprietary values (apple-touch-icon)
ZegnatThe survey data did surface something else that I need to bring up in mf2 parsing. I was using the rel parser from the mf2 parser to find the URLs, and rel-icon is super useless there because we aren’t keeping the `sizes` attribute
snarfedhey GWG, re micropub on localhost allowing missing token (https://github.com/snarfed/wordpress-micropub/pull/162#discussion_r212028124), i'm not sure when it was removed, but i'd like to keep it, built in, and not change to requiring users to write PHP code to handle a filter. mind adding the built in behavior back, in a new PR?
LoqiA disclosure is a bit of content, typically on a home page, on an indie web site that proactively discloses some aspect about the site that the site owner wants the user to explicitly be aware of https://indieweb.org/privacy_policy
NinjaTrappeurHey indieweb! I'm a having a problem related to webmentions. I have been stuck for the last 2 days with this, I think I could use some of your brain power :) It's a bit too long for a chat message, here's the problem: https://alternativebit.fr/rand/webmentionioweird/
NinjaTrappeuraaronpk, you're absolutely right, the actual RFC about this is here: https://www.ietf.org/rfc/rfc2396.txt (section 2.4.1) . Interesting rabbit hole, I guess I can now go to sleep a bit less ignorant :)
@ndwExploring webmentions (mostly implemented) took me back through some micro formats stuff. So angry/sad/frustrated to see namespaces “fixed” by using “-“ instead of “:” and removing any extensibility. You got to h- and u- first! You win, whatever you are! (twitter.com/_/status/1032381785047425024)
tantek__though then Zegnat filed an issue for mf2 parsers not picking up the "sizes" attribute in link tags, but it's like wait, if you're using rel=icon you're already not relying on a microformats parser
sknebelbecause some questioning the use of microformats means nobody should use a microformats parser for it, and potential issues in related areas should not be noted if they don't perfectly fit in the story?
sknebelso we assume that everyone will be publishing WAM and microformats, despite at least part of the reasoning for WAM just yesterday (or the day before?) was that WAM is an easier sell than microformats to e.g. the Oauth groups?
sknebel(I personally think all reasonably widely accepted link-rel-attributes should be covered by the parsers, since it's a very easy addition to the parser and the effort for the parser users that might want a rel-parser too to add another parsing thing just to see the properties the microformats parser doesn't cover is pretty annoying in comparison)
tantek__aaronpk, point being, if you (web dev) already don't want to do mf2 parsing, then by the time you get to step 3, WAM fallbacks, you're not using an mf2 parser (you started with that assumption) so there is no need for the mf2 parser to cater to you
sknebelso I as a web dev willing to use a microformats parser (since I already use it for all kinds of things) now get to find another parser just to find the size= on rel=icons if a site forces me to fall back to that, because ... ?
tantek__aaronpk, also, in all your usage of h-app, did you ever get use-case / feature requests for app photos of different sizes with sizes property or something?
tantek__i'm just saying history is now showing that dead-end sidefile formats are what ends up enabling proprietary silos to take-off, so keeping information publishing/consuming in evolving HTML is the longterm strategy for openness