Skip to content

Instantly share code, notes, and snippets.

@LePichu

LePichu/utahraptor-rfc-01-vanilla-element-extensions.md

Last active July 25, 2023 17:57
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save LePichu/321efc7c2cd437d45bdd19cbd0bf2781 to your computer and use it in GitHub Desktop.
Save LePichu/321efc7c2cd437d45bdd19cbd0bf2781 to your computer and use it in GitHub Desktop.
Download ZIP
Vanilla HTML Element Extensions (Utahraptor)
Raw
utahraptor-rfc-01-vanilla-element-extensions.md

RFC 01 - Vanilla HTML Element Extensions for Utahraptor.

Motivation

Through out the history of Metaframeworks in the Web Ecosystem, every one of them implements common abstractions to reach common goals, some of these include appending data to the <head> element, another is to have seamless routing between pages, and more.

Goals

  • Only rely on extending existing HTML Elements
  • Cover all major usecases, but also try to cover niche usecases
  • Expose extensions as opt-in attributes

Proposal

  1. Better SSR with <head data-mode="..."> A lot of frameworks offer a custom <Head> element or component, which serves one function, either append to page's <head> that will be served along the page, or to overwrite what is sent entirely. With this extension, we can allow for that using the data-mode attribute, where the value is either "append" or "overwrite", and the values are self-explanatory, compiler frontends will have to mandatorily strip <head> elements from pages or components of they have the data-mode attribute using compiler plugins for the transformers they use, which in case of Preact for example is swc. In case of multiple data-mode="overwrite" per page, the final element which has the "overwrite" mode on it applies, instead of merging them into one and applying, this is open for discussion if we should allow a third mode for that.

  2. Seamless routing with <a>: Additionally, a lot of frameworks provide a <Link> component, which is for seamless transitions or routing between pages, alternatively we can take it and extend it the way Remix does, and make the UX better by preloading the URLs of the hrefs provided, the idea is to have a preload attribute on the anchor element, which would tell the compiler to generate a <link> element and attach it to the head of the page for the browser to asynchronously preload that page, while on the runtime side of things we bind to anchor tags with preload on them to allow better transitions between pages via the Web Navigation API that came out this year.

  3. File Compression: This is more so inspired by Next.js, specifically the <Image> component, what if we took that and made it apply to <img>, <video> and more? How about an attribute which uses CSS as the configuration language with custom properties for compression settings? This is open for discussion but it is very much possible to do it with server side rendering and the help of libraries like ffmpeg, we can change the source path of assets to add context parameters on them and do server side compression and caching to serve specifically compressed assets. This is a niche use-case but it has value for UX, this is a nice to have thing so that people don't have to compress stuff themselves ahead of time, we can do it for them on build time or even runtime depending on what they need.

  4. Cross-Framework Easy Markdown: Another common capability in a lot of Metaframeworks is the ability to write content in markdown, to address this, an extension of the native <embed> element can be worked upon. Something like <embed type="markdown" src="hello-world.md"> can be made which at compile time would be transpiled into a <section> with the contents of the markdown file inside, additionally, the type can also be one of text/md, text/markdown, or md. This is very bare metal and for complex interactivity would not be recommended. Frontmatter extraction will be supported, the data will be converted to a JSON object and will be placed as a <script>tag as the first child of the section.

Concluding Words

Lastly, this is a prototype RFC, there is still discussion needed for extending elements like forms, and a lot of other use cases to extend Vanilla HTML Elements for, please provide ample feedback as such.

Prior Art

@lino-levan
Copy link

Interesting RFC. Just a few initial impressions:

  • Why opt-in? What's the behavior if they don't opt-in? I don't understand a case where the user would like the head element to be inserted randomly in the dom somewhere. I don't see a usecase where we want the links to not preload and the page to be slow. I don't see the usecase for an image not being downscaled.
  • Not sure I see a lot of value in runtime compressing of assets
  • Is this metaframework designed around the edge?

@LePichu
Copy link
Author

LePichu commented Jul 12, 2023

Interesting RFC. Just a few initial impressions:

  • Why opt-in? What's the behavior if they don't opt-in? I don't understand a case where the user would like the head element to be inserted randomly in the dom somewhere. I don't see a usecase where we want the links to not preload and the page to be slow. I don't see the usecase for an image not being downscaled.
  • Not sure I see a lot of value in runtime compressing of assets
  • Is this metaframework designed around the edge?
  • User choice mostly, we only let the compiler plugins kick in for stripping off from client, otherwise we don't, the idea is that the pages/components render on the server first and then we extract the head and other elements off, and sanitize/clean them of sorts, which is why it's opt-in
  • Can be done at compile time purely, could be a build option honestly, likewise Utahraptor is supposed to have implicit building or non-visible build steps like most things Deno
  • Kind of, performance is a huge focus but I do believe being able to run outside of Deno will also be nice, which is why I am open to making most of this on top of cross-runtime tech like Hono

@andreubotella
Copy link

  • Having HTML-like tags acting in a way different than genuine HTML tags, including with attributes doing things different than they do on raw HTML (even if it's an attribute that doesn't apply to the element, like preload on <a>, because that attribute will be ignored on browsers), is something that might cause confusion. If someone is introduced to web development with such a framework, they might expect those things to be part of the web platform, and would expect it to be usable in other frameworks that don't adhere to this standard or in browsers.
  • There isn't just one Markdown. The closest thing to a widely-accepted Markdown standard is Commonmark, which doesn't have tables, footnotes, math blocks, or other common features. Even the Github-Flavored Markdown specification doesn't have support for footnotes or math blocks, although Github's Markdown renderer does support them. If different frameworks use different versions of Markdown, we haven't helped much with interoperability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment