RFC 01 - Vanilla HTML Element Extensions for Utahraptor.
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.
- Only rely on extending existing HTML Elements
- Cover all major usecases, but also try to cover niche usecases
- Expose extensions as opt-in attributes
-
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 thedata-modeattribute, 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 thedata-modeattribute using compiler plugins for the transformers they use, which in case of Preact for example isswc. In case of multipledata-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. -
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 thehrefs provided, the idea is to have apreloadattribute 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 withpreloadon them to allow better transitions between pages via the Web Navigation API that came out this year. -
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 likeffmpeg, 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. -
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, thetypecan also be one oftext/md,text/markdown, ormd. 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.
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.
