atproto/@standard.site friends: any thoughts on this issue? This... <link rel="site.standard.publication" href="at://..."> ...is invalid HTML, per html.spec.whatwg.org/multipage/se..., because DIDs aren't hostnames. This causes problems with some tools. Issue here: github.com/sveltejs/kit...
Post
github.comat:// link in svelte:head gives error in pre-render mode · Issue #15935 · sveltejs/kitDescribe the bug I'm adding a link tag using svelte:head like this <svelte:head> <link rel="site.standard.publication" href="at://did:plc:dl64qutkgnbktz6o6ssjn7es/site.standard.publication/3mn3gcyl...
I think we're coming to consensus that it's a good idea yeah! The biggest criticism against imo is that the chance of collisions when you have multiple publications under a single repository is pretty real, and rkey's just avoid that entirely.
0 reposts3 likes
yes, TIDs are definitely a reasonable default. but if you know what you’re doing, and have a unique identifier already (e.g. a URL path that includes the publication base-path), then it’s so much nicer to just use that instead of having to derive a TID from that. In our library we now support both:
mastrojs.github.ioHow to easily add Standard.site support to your website
my library only supports rkeys based off of url slugs 🙃
github.comGitHub - thegu5/astro-scute: Simple and cute Standard.site integration for AstroSimple and cute Standard.site integration for Astro - thegu5/astro-scute