[KevinMarks]Right, that's what I was thinking. Yet there are lots of parallel implementations of popup notes, footnotes and sidenotes. It's a bit like a details/summary with the details being detachable, but that doesn't work with the nesting. Or maybe like a <ol><li> where the <li>part can appear elsewhere.
[tantek]I mean I get that there's probably just enough publishing patterns to merit a markup pattern, by some of our old reasoning. However I have yet to hear a consuming code use-case so these days I'm not even bothering with a class name
[tantek]footnote << Brainstorming: how to mark-up, prior example, EPUB3 https://www.heliconbooks.com/?id=blog&postid=EPUB3Footnotes ([[js;dr]]) <blockquote>For the link… <br/><a href="#n1" epub:type="noteref" >1</a><br/>…<p>Note the use of epub:type="noteref" this tells the reader that this link is not a standard link but a link to a note.</p><p>The note itself should be inside a new HTML5 semantic tag</p>…<aside id="n1" epub:type="foo
[tantek]footnote << ^ docs with consuming code example: https://help.apple.com/itc/booksassetguide/en.lproj/itccf8ecf5c8.html <blockquote>You use two elements to create a pop-up footnote: an anchor (<code><a></code>) element that triggers the popup and the <code><aside></code> element that contains the footnote text. Both elements have an <code>epub:type</code> attribute to identify their purpose: <code>epub:type="noteref"</code> to trigger
[tantek]capjamesg, even developer documentation should always be for a purpose, specific use-cases, not just implementing a particular spec for its own sake
[tantek]unless it's either a blue-skinned version of your icon, or a 3D version a la Snowcrash, there's no need to call it an "avatar". just call it an icon
[tantek]That seems like a short-sighted way to get contributors, also the wrong focus? Like better to get contributors that want to help with the user functionality than appeal to plumbing
[tantek]The phrase "infinite hackability" is a bit of a red flag but other than that, I do sympathize with the "pick the technology that can stay out of the way and lets you focus on only the parts that make you distinct"
[tantek]This both caught my eye and should be something you get with using HTML UI components so I’m a little confused by it: "The accessibility support was better because people who build UI components for a living are better at it than I am and I wasn’t reinventing the wheel at every turn."
[schmarty]my understanding is that using native HTML UI is far from the first thing React (and similar) frameworks teach. most from-scratch stuff is going to be div-soup in terms of markup. Beyond labeling there tends to be a lot of show/hide and focus-related behavior that requires extra layers of understanding and handling.
[tantek]And this is why I choose to work on OpenUI instead of spending one minute learning React. We have to solve those things at the platform level, not depend on any framework for them
[tantek]In the mean time yes I’m of the belief that *web* sites should "just" use HTML UI components for all the built-in accessibility etc and stop prioritizing trying to make things look as "pretty" as "native"
[schmarty]i am griping because owncast felt _almost_ in a state where i'd want to use it (i really want to be able to shut off or reduce the server usage when the stream is offline), but the knowledge that there's a big React stack waiting if i want to customize is something i am prejudiced against. :}
IWDiscordRelay<capjamesg#4492> It isn't exclusively for mf2 tasks, and even mf2 tasks often have a lot of helper work that goes on (endpoint discovery, validation, etc.).
IWDiscordRelay<capjamesg#4492> (Where "validation" refers to things like URL canonicalization, checking status codes from responses, etc. It doesn't do mf2 validation to be clear.)