search

pyrox0 / fursona-schema

Schema for .well-known/fursona
Creative Commons Attribution 4.0 International
67 stars 5 forks source link

[Question] Links in `description` property #12

Open AverageHelper opened 1 month ago

AverageHelper commented 1 month ago

The description of the description property in the schema says it's for "additional notes or links". Is this field meant to contain some flavor of Markdown? Is there some standard Markdown flavor that authors should expect implementers to sanitize and render? I see Gemini URLs are permitted in various places, so should fursona.json authors expect a hypothetical Gemini viewer to handle Gemtext in the description instead, and somehow serve a different file for Gemini?

The reference viewer implementation doesn't seem to handle Markdown in the description, based on my testing. I'm guessing from the source code that Markdown isn't explicitly handled there.

My use case is that I'd like to link the artist of my ref sheet, and I'm debating whether I should include the link in a parenthetical inside the description (i.e. "description": "Lorem ipsum dolor sit amet. (Ref by [some-artist](https://example.com))"), or play around with some non-standard additional property for the artist's name and URL for my own fursona.json renderer.

If description isn't meant to contain rich text at all, Markdown or otherwise, then maybe an additional refArtist field, or even a refArtists array field, containing objects that have a name and url property, might be useful?

pyrox0 commented 1 month ago

Currently, any potential parsing of text is done by viewers. The format is specifically unspecified, so that you could put markdown there for HTML-based renderers that could convert it to HTML, or Gemtext for Gemini viewers, etc. It's intended to be as flexible as possible(also I never thought of specifying a specific markup language when adding that field)

refArtists or something similar to that would be an interesting idea, and honestly I might refactor it so that ref is an array of objects that each have a URI, artist(with optional link), copyright/license info, etc. I just don't want to make it too complex for those with the simple case of one sona, one ref, one icon.

AverageHelper commented 1 month ago

Hmm, could have an optional refs array maybe. UI for viewers might get complicated, but that's the viewer implementers' problem, lol