#[tw2113_Slack_]my general take has generally been apache is a bit easier to configure and set up, but if you put in the work, nginx has the longer benefits
[tantek], [KevinMarks] and [fluffy] joined the channel
#[fluffy]Last October I had to rebuild my server and in doing so finally got around to switching to nginx. It is SO much nicer than Apache.
#[fluffy]Setting up PHP is a little more annoying but it’s also a lot easier to keep it secure.
#[fluffy]The lack of .htaccess is a bit of a bummer but it’s for a good cause. And of course as a reverse-proxying fronting server it’s kind of in a different “marketplace” than what .htaccess is meant for. If you really need .htaccess for a site you can always have that site served by a userspace Apache process and then reverse-proxy into it.
#[fluffy](which is, again, way more secure, especially where PHP and CGI is involved)
[chrisaldrich], ShadowKyogre, treora and doosboox joined the channel; ShadowKyogre left the channel
#doosbooxI'm trying to understand what h-card is and how it works. The examples on the wiki use <a class="h-card">, but in the wild I see <span class="h-card"> and others
#doosbooxwhat's the recommended approach, and is there a specific way data within the h-card should be structured?
ShadowKyogre and [Murray] joined the channel; ShadowKyogre left the channel
#[Murray]Hi doosboox 👋 `h-card` is a way of marking up identifying information. So that could be a section of code which contains _your_ details (name, profile image, website url etc.) or it might be for a bit of code that's referencing someone else, such as a link to a person (think Twitter-style @ mention). The HTML tag you use doesn't really matter, so will depend on what that section of code is doing. Often, if you're referencing someone else,
#[Murray]you'll be linking to their website or profile somewhere, so you'd likely put the `h-card` on an `<a>` element. If it's for your own `h-card` then a `<span>`, `<section>`, or just about anything might be more semantically relevant 🙂
#[Murray]All the `h-card` does is point machines where you want them to look. So if a microformats parser is checking out the page, they can easily find out which people are involved or tagged.
#doosboox[Murray]: ty 🙂 I was talking about h-card info on my own index site. When will a machine need to find that? There’s no common parsable way to present it either way
#[Murray]So, looking at the source I'd say you could wrap the entire site in a `<main>` and stick the `h-card` on that *but* if you're not doing this in order for the site to be machine parsable, perhaps you don't need microformats? 😊 A common use-case around here is for auto-populating profile information when logging in to servies that use IndieAuth. I'm sure there are plenty of other reasons too
#[Murray]Ultimately, though, the purpose of microformats are for helping machines understand the context/content of HTML. If that's not a use-case your working for, you can probably safely skip them
#Loqimicroformats are extensions to HTML for marking up people, organizations, events, locations, blog posts, products, reviews, resumés, recipes etc https://indieweb.org/microformats
#doosbooxI was thinking of setting class="h-card" on the <ul> with contact info :) But if h-card is made for machine parseability I should probably figure out how it's supposed to be parsed. Will read that article about microformats :)
#[Murray]Honestly, the parsers themselves will figure that stuff out for you 😉 You can test a page to see how it would commonly be read at a few places. https://indiewebify.me/ has a good `h-card` checker specifically, https://xray.p3k.io/ works a bit differently, and then there's https://microformats.io/
#[Murray]that last one is particularly useful for explaining how the whole concept fits together
#[Murray]@doosbox: also, you could definitely mark up the `ul`. That would probably be what I would end up doing myself. The reason I suggested the whole thing is that your current `<h1>` is obviously useful to include as well, but you can always repeat that info within the `ul` too 🙂
ShadowKyogre, [KevinMarks], [scojjac], Zenyattus and jamietanna joined the channel; ShadowKyogre left the channel
#[KevinMarks]comparing indieweb to OStatus and ActivityPub - we make ti a lot simpler by using URLs rather than email-like IDs, so we don't need the whole WebFinger lookup complications
#LoqiAn autolink is a hyperlink that was automatically added to some text to link that text to an obvious or useful destination, like hyperlinking a URL in plaintext to the URL itself, linking hashtags to search results, and @-names to their profile pages https://indieweb.org/autolink
#sknebelthe python parser also relies on a tree generated by an HTML(5) parser. I think the PHP one does too, but not 100% on that. - but those probably are just "right" in structure, not DOMs API wise
#sknebelsomeone (forgot who...) had a typescript parser last year (?), I didn't look into how that worked
#[tantek]right, I'm a little worried about how out of date the Node parser is
#LoqiAutoAuth is the working title of an extension to IndieAuth that allows clients to authorize to other servers in the name of their user, without the user being present to confirm each individual authorization flow https://indieweb.org/AutoAuth
#jackythat diagram always first confuses me but then I get it immediately :)