trwnhthis is the part that i'm unsure about -- aren't multiple rel values supposed to apply their semantics independently? what does "code" or "root" mean on its own? > I expect any user visible/clickable in-page links with rel=repository to have at least one other value, e.g. at most one of "code", "directory", or "root"
trwnhthat seems confusing and i'm not entirely sure why -- my intuition is strongly telling me that something like rel="alternate stylesheet" should be equivalent to rel=alternate + rel=stylesheet. i think it has to do with space-delimited values?
[tantek]there's no rule about rel values being independent, so they can be or can do things in combination, in some ways just as different attributes themselves can. like rel=alternate type=application/rss+xml etc.
trwnhlike "alternate" should be in relation to the current resource/document, not as a modifier for "stylesheet". i don't have a problem with rel+type because that feels fine, they're separate parameters intended to be interpreted together
[tantek]example for "code" on its own mentioned previously, wikis that require login to edit, and otherwise display a "View Source" button/link that takes you to a source view
trwnhi guess discriminating on title= is also something that sometimes gets used for this? the problem is that title= is freeform arbitrary input that doesn't really have the expectation of being parsed for token usage
[tantek]trwnh, it is reasonable to propose an alternative where all values are fully combined, e.g. rel="repository-code", "repository-directory", "repository-root" and treat them all as unique tokens
[tantek]to some extent we should explore such possibilities and evaluate them based on ease of publishing for developers and ease of consistent implementation by consuming applications to present consistent and predictable UX to users
[tantek]there are pros/cons to decomposed separate values like "code", "repository", "directory", "root" that can then be used in combination and similarly pros/cons for fully composed values
[tantek]my experience has been that simpler, more elemental values that make sense on their own and in combination work better, and scale better (extend better) than fully composed values
trwnhi'm speaking more in a logical sense though, i would get tripped up if i saw something rel=alternate that wasn't actually an "alternate", it was a "stylesheet that shouldn't be applied by default"
[tantek]on that tangent there was a whole discussion in the W3C sustainability channel that there should also be an "eco-mode" alongside those two, to for example choose pure black pixels on OLED displays
trwnhsorry, by composable i meant that you can use multiple rel values for the same href/target but the rel values should continue to apply independently
[tantek]mediawikis are a good example of where you'd use rel="code" for the not logged in state on the "View Source" link, and in the logged in state rel="edit code" for the "Edit" link
[tantek]this is why it makes sense to have them all as separate rel values, which both act independently and when used in combination, may provide additional functionality
trwnhi would probably publish rel=repository-code for e.g. an "edit this page" link on the mastodon documentation that links back to github.com/mastodon/documentation/edit/... and similar use cases. this is what i was previously considering rel=edit for
[tantek]again, syntactic differences aside, such multiple rel values are a similar mechanism as multiple attributes with their own values that mean their own things, and have special meanings in combination
[tantek]anyway all this is in the chat logs for this channel the past few days, take a look for more explorations and we'll eventually get this documented in an organized way on the wiki page
[tantek]trwnh, since you mentioned mastodon usage and rel values, do you know if any progress has been made on implementing parsing of: link rel="author" type="application/activity+json" ?
[tantek]do you have ideas for how to get mastodon developer attention on re-using existing standards like link rel="author" type="application/activity+json" rather than what happened with the custom mastodon-specific markup?
trwnha few hours ago there was a discussion of rel=tag being used in mastodon to suppress link previews, but also class=hashtag i think does the same thing. things like this are scattered through the mastodon html parser and akkoma publishes class=quote-inline on their placeholders so mastodon will strip that i think
[tantek]which itself was proprietary markup. so the methodology of propose something that mirrors something else proprietary is not a good design approach
trwnhit's not a good design approach but unfortunately it is the prevailing one. proprietary or not, the methodology of fediverse development seems to be driven significantly by mirroring what came before
trwnhthe problem is that applications will publish things with... little regard for whether it is a good idea or not? it ends up being a temporary fix that develops into tech debt and somehow ossifies into an ad hoc standard
[tantek]in this case however, the standard alternative was proposed and discussed in the issue long before the proprietary version shipped, so there was no tech debt to justify it
trwnhthe tragedy here is that what gets proposed and discussed in issues is often swept aside by what catches the whims or interests or attention of the dev team
trwnhit's a small team and it's a big community, and there isn't really a proper governance model yet (although ostensibly this has been in the works for some years now?)
trwnhit's still a big shame that we lost mf2 support in the transition from 3.5 -> 4.0 because public pages started to be handled by the js frontend which didn't support mf2 (unlike the ruby haml pages which did support mf2)
[tantek]ironically a bunch of the content is still there in meta tags so it's theoretically possible to mark those up with "metaformats" (microformats applied to meta tags)
trwnhdo you mean opengraph stuff? yeah, that's probably good enough for pulling a title and description, where "title" here means the author name, and "description" here means the content of the post. i guess you could map meta property=og:title to .p-author and also map meta property=og:description to .p-content
[tantek]ah right, yes that makes sense and was implied in the order I listed, which I was listing from a user perspective of which actions are the most power/useful first then falling back to less powerful/useful links
trwnh this is the part that i'm unsure about -- aren't multiple rel values supposed to apply their semantics independently? what does "code" or "root" mean on its own? > I expect any user visible/clickable in-page links with rel=repository to have at least one other value, e.g. at most one of "code", "directory", or "root"
[tantek] as noted, see the UX in these examples https://chat.indieweb.org/microformats/2025-05-26/1748227008455200
capjamesg [tantek] I have written a JavaScript implementation of the source algorithm that you described in https://microformats.org/wiki/source-code-brainstorming
jamesgallagher edited /source-code-brainstorming (+0) "/* Potential algorithm for finding a representative URL for editing/viewing source */" (view diff)