[tantek]The use case of linking directly to a GitHub edit link without knowing if the reader is logged into GH is an interesting one. I think the key principle to follow here is user predictability and dependability
[tantek]So like if your site knows it's you that's logged into your site, then maybe a direct GH edit link with relevant=edit makes sense bc your site can guess that you're also signed into GH
[tantek]Or if your site auths people with sign-in to GH then similarly your site knows that a GH edit link will work to directly edit a textarea so rel=edit makes sense
[tantek]Otherwise it may be more user friendly to link directly to the page's source code in GH but without the edit path, and use rel="code repository" (or whatever we end up with per brainstorming) to reliably provide a repo link which then may have a direct edit pencil icon button
doesnmperryflynn: ssg is not because it's just a website. Services like webmentions, microsub, microsub, indieauth and etc need to be delegated to other daemons
[Murray]Pretty out there question: does anyone know of a way to limit Node.js processes per CMD? I'm experimenting with running some of my sites on a CPanel host (it's been a fun weekend of outages and issues 😄), and the main blocker right now is just that each site ends up competing for resources. I have a hard limit of 100 processes, and each Node app seems to want to spin up as many as it can.
[Murray]I've already added a Cron job to clear out unused processes routinely (that helped a lot!) but I'd love to be able to assign blocks, and reserve a handful just in case. I just... have no idea what I'm doing with this kind of server architecture 😅
osteophageI don't know the answer to that, but this question reminded me I should add a section on the lang property to the beginner guide I've started working on, so kudos for that.
[Murray]@zachary.kai are you talking about the root `<html>` element? If so, yes, it's definitely worth it; it has accessibility and translation benefits! If you're talking about using the `lang` attribute on a subsecton of a site (say a `<blockquote>` or a `<p>`), then specifying the language is typically enough (e.g. `en`) and is still definitely worthwhile. Very few things (if any?) actually use the additional context of `-US`. That said, as
[social][KevinMarks] that looks interesting. I don’t have issue with Pinboard and in recent months have had productive chats with Maciej and there have been a fair amount of updates. I like the sharing out, but also looking at what those in my network are bookmarking. I’ve always had a back up to my social bookmarking (starting with http://del.icio.us), my personal site’s homemade CMS started as a (what is now called) linklog (and travel log t
[social]I have a lot of not so public second bookmark capture services locally in apps, but I keep thinking of rebuilding my linklog, importing my ~78k bookmarks, and keeping a structure that could work to integrate somewhere for networked social bookmarks and/or linklogs.
[tantek]lang=en-US is also incrementally better (assuming that's the right dialect for the content) than lang=en bc that's usually ignored by tools and services due to presence in templates and copy/pasta in lots of pages. Classic example of invisible metadata rot
carrvoartlung (or any other css guru): I am using `grid-template-columns` with `grid-column: N / span 1` to give the Nth column, but how do I ensure that it is the only element for the row without having it's width become the whole row (and lose positioning)? Or is grid simply the wrong approach in the first place?
[artlung]harder (for me!) to visualize without seeing the fr'instances. But that makes me kind of think that you would find repeat and auto-fit useful. See this stackoverflow answer which does a nice job. https://stackoverflow.com/a/46227025/63094
[artlung]_(for most layouts, there's a way to do it in grid, but if you have more... arbitrary elements to be added as child elements of to the grid display: flex is great, and then you decide on the max-width and flex-grow of the child elements and things slot into place. all of this is easier said than done but you could do worse than sharing here to for feedback)_
[artlung]last thought: `grid-template-areas:` is great, but if you have numbers of items that are unpredictable named areas can overlap in ways one does not intend
[artlung]And I believe admission to that ecosystem and continuing releases requires paying money to Apple on an ongoing basis unless browser extensions are an exception.
capjamesgI'm not 100% sure if you need it if you plan to distribute outside of the App Store. I think that's an option, but I haven't looked into that side yet.
trwnh(catching up) [tantek] capjamesg [KevinMarks], my use case is most closely (3) or subset: link to the "edit link" of the "same"/"source" resource, but potentially cross origin. just using gitea/forgejo instead of github. it doesn't make sense to point to anything other than specific _edit uri
trwnhin the ideal case you are already authenticated to the website so it can selectively render a rel=edit link while "knowing" that when you land on the _edit page, your current credentials should be accepted just as well
trwnhthe "misleading" part seems to be the idea that, when logged out of gitea/forgejo, you will be redirected to a login, then redirected back to the _edit page
trwnhto me, this is not really any different than linking to any other resource that might happen to redirect or require auth. if i reply to a private post then i have no idea who someone else's audience includes. "in reply to this thing you can't see" might be a degraded UX but it doesn't make the "reply" relation/predicate somehow inaccurate
trwnhbasically i am making the claim "here's where you can edit this page", but when you get there the bouncer might not recognize you immediately (because no consistent Web identity) and you will be asked to see the front desk before coming back
capjamesgIn Firefox, you can selectively show a web extension depending on a condition. This means you can show an edit button only if a page is editable. Showing a button only if a user can edit the page feels like the ideal experience. Promoting rel=edit without any precondition regarding auth makes it hard to strive toward that goal.
trwnhi don't know if i want to add auth to a site solely to detect whether i should render an "edit this page" link, when the invitation to edit the page extends to the unauthed general public also (with the auth at the destination being a formality of the edit *process*, not of the edit *relation*)
capjamesgThis could be consumed by an extension in a waterfall algorithm, where you: Show edit if the user can actually edit the page, show view source to everyone else, or show nothing if no source or edit link is present.
[tantek]I agree with capjamesg that it makes more sense to show the general public a "view source" rel=code link, just as the http://indieweb.org wiki does when you are not logged in
[tantek]If you are logged into your own site, then sure, go ahead and detect that on your backend and show yourself the edit link because you know if you are logged into your site as you (e.g. via IndieAuth), then you are most likely also logged into the cross-origin edit link, and furthermore, you as the individual who built it has full fore-knowledge of what to expect so you won't be surprised
[tantek]the other MAJOR problem with tolerating or normalizing the "verb" -> "show the user a login prompt/screen instead of doing the verb" behavior is that it is RIPE for creating (and normalizing, and reinforcing) a phishing UI
trwnhmaybe there's some kind of weird CORS thing you can declare to say that going from wiki.trwnh.com/foo to git.trwnh.com/sites/wiki/_edit/content/foo.md is okay, like git.trwnh.com declares ahead of time that its local storage can be accessed by wiki.trwnh.com and check for a cookie or something. seems complicated but how else would wiki.trwnh.com know you are logged into git.trwnh.com
[tantek]random web page -> "edit this page" link (with or without rel=edit, though with rel=edit would make the add-on an accessory) -> cross-origin domain that "looks like" github/gitlab/gitea etc. with the exact same login screen presentation to phish your credentials.
trwnhi guess i can see it being expected in a private deployment for some organization perhaps (you might reasonably expect SSO for wiki to extend to gitea)
[tantek]trwnh better to start conservative and user-dependable, user-safe, and explore ways to expand it later, than start too flexible and make it open to abuse, another vector for vulnerabilities etc.
trwnhright, i was thinking a script hosted on git.trwnh.com could figure out if you are logged in, then you CORS on wiki.trwnh.com to allow the script to run from git.trwnh.com
[tantek]then, it's possible to present a UI to allow users to opt-into "edit" links which requires sign-in with the destination of your cross-origin edit links
capjamesgI now have a browser extension that lets me show an edit button for a URL pattern and, when clicked, takes me to a page that redirects me to the corresponding GitHub page.
[tantek]yeah re: fake login screens and phishing, a big part of improving security on the web is NOT teaching users to be phished, i.e. encouraging existing trusted/legitimate sites to NOT adopt UI patterns which inadvertently teach users to be phished. Thus links that claim to do one thing (verb), but actually make the user sign-into another domain first, should be avoided.
[tantek]Because such UI patterns, especially on trusted/legitimate sites, are literally teaching users to trust by reference (with the implied incentive of the original "verb" they were attempting) and provided their credentials to some cross-origin site linked by a different site.
[tantek]This probably deserves a longer write-up or at least a blog post starting with "Why ..." so folks can provide a citation when asking trusted/legitimate sites to NOT put such links on their pages
perryflynn Is a static site generator an option? Otherwise I only know WordPress and TYPO3.
[Murray] Pretty out there question: does anyone know of a way to limit Node.js processes per CMD? I'm experimenting with running some of my sites on a CPanel host (it's been a fun weekend of outages and issues 😄), and the main blocker right now is just that each site ends up competing for resources. I have a hard limit of 100 processes, and each Node app seems to want to spin up as many as it can.
[schmarty] KevinMarks: oh wow! Quite a rabbit hole.
[artlung] harder (for me!) to visualize without seeing the fr'instances. But that makes me kind of think that you would find repeat and auto-fit useful. See this stackoverflow answer which does a nice job. https://stackoverflow.com/a/46227025/63094
trwnh (catching up) [tantek] capjamesg [KevinMarks], my use case is most closely (3) or subset: link to the "edit link" of the "same"/"source" resource, but potentially cross origin. just using gitea/forgejo instead of github. it doesn't make sense to point to anything other than specific _edit uri
capjamesg In Firefox, you can selectively show a web extension depending on a condition. This means you can show an edit button only if a page is editable. Showing a button only if a user can edit the page feels like the ideal experience. Promoting rel=edit without any precondition regarding auth makes it hard to strive toward that goal.
[tantek] I agree with capjamesg that it makes more sense to show the general public a "view source" rel=code link, just as the http://indieweb.org wiki does when you are not logged in
Loqi rel-edit is a microformat for linking a page to a URL that lets you edit a page https://indieweb.org/rel-edit