LoqiIt looks like we don't have a page for "best way to add HTML into a contenteditable field" yet. Would you like to create it? (Or just say "best way to add HTML into a contenteditable field is ____", a sentence describing the term)
[manton][aaronpk] Another side effect of including HTML on events.indieweb.org that could be improved… Kimberly’s RSVP has an h-card with “display: none” to hide on her blog, but the image shows up in the RSVP.
[manton]Yeah, usually the h-card would be somewhere else on the page. But I don’t think it’s necessarily wrong, either. I’ve used this kind of markup myself.
[manton]Hmm. In this case, there is no way to put it somewhere else except e-content. You could say that’s a limitation in Micro.blog, but I can imagine other systems working like that too.
[manton]So I’m sure that’s why they put the h-card in the e-content… Basically a choice between modifying the theme or just pasting in some extra HTML in the post.
Loqi[Manton Reece] I’ll be attending IndieWebCamp West later this month. It’s online-only, centered in the west coast timezone, but anyone around the world is welcome. Need to think about IndieWeb-related goals for Micro.blog that week.
aaronpkIf there was an h-card on the home page, then the post could have a link like <a href="/" class="u-author">Kimberly</a> and the receiver can go fetch the full h-card from there and you can also show that link because it makes sense
aaronpkthinking about this generically (since one-off examples often make sense but you forget the implications of something like that in the larger context), this seems very similar to the issue of putting photos inside the content with u-photo as well
aaronpkits almost like what you want the parser/consumer to do is: if an HTML element inside an e-* contains other microformats properties that result in properties being added next to the e-* property, then you want to remove those elements from the HTML of the e-*
[manton]The nice thing about including photos inside e-content is that the HTML can be used in a lot of different contexts (like feeds) without requiring any special behavior to look right.
aaronpkGWG: just the same situation manton is in where people can add arbitrary html including microformats into the content box and the theme already has its own microformats outside of it that the user can't modify
[manton]Maybe let’s take a step back. Assuming the user can’t modify anything except what’s in e-content, is there a best practice for including h-card info?
aaronpkback to the specific problem, I'm actually confused why the event site is showing that at all because I thought my quick fix the other day was to show only the text content of comments
[manton]For events, it seems ideal to allow HTML but strip out images and do other sanitization. That way you can have links but it doesn’t look too cluttered with other stuff.
aaronpkI suppose you could argue that specifically for showing comments on a post or event, you would just always remove images in the content. That'd also break reaction gif posts tho
sknebel(re what's the workaround: a link to a fuller h-card on something that's part of the text or an empty link, that at least doesn't show up visibly)
[manton]So, I looked into what Micro.blog is doing here… And it’s ignoring “display: none” too. But apparently I’m styling the h-card photo so it’s smaller/inline: https://micro.blog/kimberlyhirsh/12444267
[manton]I think [aaronpk]’s point about blog post comments is good too… Those should allow at least some images, similar to RSVPs, but you don’t want the text taking over the page with all sorts of styling or big images.
[manton]Yeah, I have some CSS for WordPress looking for “img.emoji” and “img.wp-smiley” and probably others. And when looking for specific HTML, I actually have a list of filenames like “1f3b5.png” for books.
[manton]Definitely an accessibility problem so I was wondering if WordPress already put something suitable in “alt”. But now don’t have a good reference for what WordPress used to do.
sarahd[d], daiyi[d], Asaf_Agranat[d], Jeremiah[d], rattroupe[d], aspenmayer[d], sayanarijit[d], Seb[d], Murray[d], shaunix[d] and Zegnat[d] joined the channel
aaronpkyeah it seems like hiding stuff in the e-content with display: none and then being surprised when it shows up in something that consumes the e-content is the real problem here
aaronpkso i think i have 2 options for the event site. either I add similar css as micro.blog to make that image appear small and inline, or i allow the "display: none" css
ben_thatmustbeme and cygnoir[d] joined the channel
[manton][aaronpk] The quick fix is definitely the CSS… I think the problem I ran into with “display: none” is being smart about allowing it _without_ also allowing everything else that can go in a “style” attribute.
[manton]Cool. If that already supports it, that would be great. I don’t think the library I use (“sanitize” Ruby gem) didn’t, although I should check again.
[manton]For completeness, here’s what I currently allow in HTML when showing a post in the Micro.blog timeline. I’m sure I’m missing some things… I add things that are safe when I notice something that doesn’t look right. https://gist.github.com/manton/48a5cd6148438d48c81e47e438cfc125
aaronpkok yeah, going to go with that for now since it's less of a drastic change. photo responses are also still supported too since those are treated entirely differently and will pull photos into a nice photo grid
capjamesg[d]I have been beefing up my Microsub post interface. I can now auto link to person tags and get a list of recent hashtags I have used that match what I am trumping.
capjamesg[d]There is now a visual indicator for uploaded images (no more HTML in the client input field for images!). And I can use emojis with the : syntax.
capjamesg[d]The person tags come from the proposed micropub contact extension my endpoint supports. And the hashtags come from my micropub endpoint too.
[tantek]I still think photos make sense inside e-content because they're literally part (if not the primary aspect) of the visible content being presented
aaronpkthere's no concern with photos inside e-content if they are part of the content, it's only a problem when they are *also* marked up with u-photo
aaronpkhere's another way of thinking about it... the point of adding microformats markup is to *help* consumers of that data do something with it. if adding markup is actively making it more difficult for the consumer then don't add the markup. in other words, having a photo inside the content is fine with no other markup of the photo. but if you want to help consumers do something smart with that photo (show
barnabythat reminds me, I need to set the default mf class for uploaded photos in my posts to u-representative, as at the moment all of my images are within the e-content
[tantek]aaronpk, adding u-photo *is* helping consumers of that data do something [different] with it, it's indicating that it's a photo post and should be presented with the photo as the focus of the post.
barnabyheh, I remember discussing this a while ago. interesting to see that it’s still a talking point. In theory I like the idea of e-content being self-contained, so that consumers can adapt to arbitrary post types by just using e-content as a fallback, and then having more advanced behaviours for additional properties which they support (e.g. recognising that u-photo is duplicated in e-content, and making sure that it’s only
jacky^ but even in that case, if the photo's doubly tagged, does the photo-specific app _now_ have to scan the HTML for values existing in `photo` and prune them?
aaronpkright jacky, a consumer sees the "photo" property and is like cool this is a photo post. and then if it also decides to display the content, now the photo appears twice
aaronpkif you want to have fallback behavior for consumers that don't understand a specific property, then that fallback should be able to be ignored when consuming the new property
[tantek]clicking on a photo would show the entire photo post, which presumably if you want to show it in context of other text, etc, then the content makes sense for that
aaronpkwhat you're describing works if you only have: a view of photos with no content, and separately a view of content while ignoring the "photo" property
aaronpklike even just say you want to replicate the instagram UI, you can't do that right now without going through all the hoops i've had to do to remove the photo from the content
barnabyis checking and removing duplicate photos from content really a lot of hassle? IIRC the URLs in e-content should be resolved by the mf parser and therefore guaranteed to be the same as the photo property, so it should be a case of checking for img or picture elements matching photo properties and removing them if you want to do something specific with the photos
[tantek]it's not about "having it both ways". like I said, reformatting author published content is way out of scope for typical use-cases (and things people want to bother trying to code). it's also horribly fragile
barnabyIMO every time you touch untrusted HTML content, there’s already so much sanitization steps which you need to jump through, that adding mf-specific behaviour like this isn’t a big deal
[tantek]focusing on the "how do I remove u-photo from e-content" is completely missing the broader contexts of what publishers do what they do, and the simpler reader use-cases I listed above
[tantek]so we're not going to solve this with a singular issue thread like that. or rather any attempt to do so is going to disproportionately twist a design/solution to fit that and neglect the broader use-cases and ecosystem
[tantek]and folks publishing photo posts will either care how their photo posts show up in readers which are doing simple but predictable things or they won't
[tantek]the problem here AFAICT is jumping straight to narrow issue discussion without documenting the broader use-cases and how people publish what they do
barnabyit’s especially a pity that image alt text is separated from the u-photo property, resulting in consumers not being able to accurately recreate the original markup
[tantek]the discussion has been too plumbing-focused from what I've seen. e.g. we don't have screenshots for different use-cases for publishing & presenting in readers etc.
[tantek]barnaby, pretty sure the alt text in images has been handled for quite some time, in a way that makes it possible to recreate (i.e. they're kept together)
Loqi[tantek] Resolution: issue 2 proposal accepted.
No objections in above discussion, and positive opinions (👍) from a few implementors on the proposal. Proposal text incorporated into spec and reviewed.
Proposal implementation in mf2py parser, test cases p...
barnaby!tell gRegor heya, any objections to me moving https://github.com/microformats/php-mf2/issues/184 to the 0.5.1 milestone and wrapping up the 0.5.0 release? it’s been four years since 0.4.6, and there’s easily enough features and fixes to justify a release IMO
barnabymaybe I’ll take the opportunity to set up some github actions on php-mf2 for testing and linting. I really like how the actions for my indieauth and micropub libraries turned out
aaronpki thought the browser behavior of jumping down to the matching id= attribute based on the query string fragment was relatively newer than the actual id attribute
[schmarty] Ooh hello yes
@frankmeeuwsen ↩️ Maak van je eigen site een identiteitsprovider voor sites die dat ondersteunen. Zoals inloggen met Twitter , Facebook of Google. Maar dan met je eigen domein. Zie https://diggingthedigital.com/indieauth-wordpress/ (twitter.com/_/status/1490584315524268036)
@hagengraf Neu im Novatrend Blog: Was ist eine #Webmention und wie nutze ich sie in #WordPress?
/@pfefferle https://blog.novatrend.ch/2022/02/07/was-ist-eine-webmention-und-wie-nutze-ich-sie-in-wordpress/ (twitter.com/_/status/1490588687016423424)
@novatrend_ch Neu im Blog: Was ist eine #Webmention und wie nutze ich sie in #WordPress? https://blog.novatrend.ch/?p=7164 /cc @pfefferle <… https://twitter.com/i/web/status/1490596203339423747 (twitter.com/_/status/1490596203339423747)
[tantek] The replies here 😂 (some of which are vaguely indieweb-related, toolchain stuff etc.) https://twitter.com/toddmorey/status/1489613725636173825
@toddmorey Made this using only CSS and a single <div> 👀 https://pbs.twimg.com/media/FKwrgMMWQAED3Qi.png (twitter.com/_/status/1489613725636173825)
kinduff [tantek]: this one is my favourite, https://briefs.video/videos/how-do-i-draw-a-line/ saw it posted there too
capjamesg[d] What is the best way to add HTML into a contenteditable field?
Loqi It looks like we don't have a page for "best way to add HTML into a contenteditable field" yet. Would you like to create it? (Or just say "best way to add HTML into a contenteditable field is ____", a sentence describing the term)
@kinduff @rem Hey rem, wondering if the RSS feed for http://webmention.app needs to be formatted in a certain way, should it include source and target too? (twitter.com/_/status/1490682522317033477)
[manton] I did the same thing a couple years ago here, probably for the same reasons: https://pin13.net/mf2/?url=https://www.manton.org/2020/06/08/ill-be-attending.html
[KevinMarks] the bridgy html feeds are fun like that as there's no constraint on image size so you get huge images
aaronpk Maybe there's a role attribute for this? https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles
[jgmac1106] and barnaby build some tool that will automatically take a u-featured and turn it into OGP kruff for me
barnaby heh, I remember discussing this a while ago. interesting to see that it’s still a talking point. In theory I like the idea of e-content being self-contained, so that consumers can adapt to arbitrary post types by just using e-content as a fallback, and then having more advanced behaviours for additional properties which they support (e.g. recognising that u-photo is duplicated in e-content, and making sure that it’s only
jacky hopefully I can get this working to have something living at https://rust.microformats.io