If this shows itself to be highly useful as a concept, then I would perhaps avoid reinventing the wheel on the file format side of things, and just standardize what we already have:
- Come up with a file extension (.hmml)
- Decide on an entrypoint filename and format (index.html)
- Use an existing standard for combining resources into one file (tar + zstd)
Now you have something that is usable only using pre-existing tools.
This is the sort of weird thing I would come up with - a solution without a problem perhaps, but a magnificent testament to some technical itch that had to be scratched.
I get that, but the drawbacks outweigh the benefits imho and the b64 overhead is not solved, just deferred.
Say I want to distribute an hmml file as a single file, I'd have to create an html with the embedded js runtime, and then embed the hmml file... as b64, therefore negating any benefits.
Chrome started supporting this at some point (though I wish they would've added in more support). Lack of support for mhtml is one of the things keeping me away from Firefox on mobile.
PDF is an irreversible format in terms of editability. (btw I build the world's most performant pdf/pptx editor at https://eddocu.com , I would enjoy if you have any feedback)
Regardless, I cant find the relation in between.
It's like an abstraction that might help future genai models, or a packing strategy, or ..
We also invented svgs, its a vector. SVG is a declarative language, has its own format and has own renderer
HTML, CSS is no different.
`<div style="background:black">html is underdog</div>`
Having this perspective on our mind, even considering any imperative code as a native image makes complete sense.
`canvas.drawCircle();`
So, .html/.hmml/.js is as image as .webp
====
## How can we/future's genAI models could leverage the world's most popular and feature rich image format (HTML, CSS, JS, SVG, IMAGE altogether). And how can we leverage it to build editable/composable images?
This so to 'popular' image format we call .html has a caveat. It's UTF-8, and whenever you need to embed any resource, you either need to base64 encode it(it has extra size overhead) or link the resource as a seperate thing. So.. as you decide to serve single pack of data for a single image, a binary packing strategy makes sense.(Image can be anything as we discussed earlier)
To match these concerns, we created/proposing you a new format, HMML (HyperMedia Markup Language).
HMML (HyperMedia Markup Language) is a declarative+imperative markup+ language for images/videos/media.. *HMML is HTML, CSS, JS, SVG, image, but not UTF-8.*
and we have a npm library that does encode/decode of this binary format, and mounts the so to image into dom. (2kb js for encode/decode each. For comparison React is 90kb js. )
`npm i @eddocu/hmml`
# image-leftdog-rightcat.html
```
<div style="display:flex">
<img src="base64" alt="i am dog image" />
<img src="base64" alt="i am cat image" />
</div>
```
Apart from doing this, hmml does embed the html, css, js blueprint into media binaries
# image-leftdog-rightcat.hmml
`binary stuff`
People already do similar things. But this format or POV of thinking accepts html/css/js as a native image format. Excited to see if future operating systems/browsers also accepts this format. <hmml /> or <img src="maybe.hmml" />
===
```
<Technical-Appendix>
The word "green apple" is an image, that has no format and no renderer.
`const vectorMultiDimensional_768 = get_word_embeddings("green apple")`
Now the word green apple has a format, its: "embedded by Embedding Model X"
If you had a renderer as such Embedding_Model_X.render()
Now you could call entire english sentences/paragraphs are images.
</Technical-Appendix>
```
wait this is actually kinda brilliant in a weird way
like when you think about it we're already doing this with svg and nobody bats an eye. svg is literally xml markup that renders as an image and everyone just accepts it as normal
also the composability angle is interesting. being able to edit an "image" by just opening it in text editor instead of photoshop has some appeal
I’ll engage with the editorialised title (which will probably be changed soon), “HTML is a native image format, hear me out”:
this page failed to convey what exactly is the main pitch, is it a new image format? using html as image? rendering with canvas?
I got lost
sorry for this, im updating
in the meantime you can take a look at this
https://www.reddit.com/r/Design/s/hv0hyBow9I
There's so much text but nothing that clearly says what it is.
Is it HTML and its contents (e.g. images) in a binary format?
yes exactly.
you can go devtools at https://hmml.eddocu.com
it downloads single binary that contains media assets (svg, image, video, ..) and html/css blueprint, even js (security concerns!)
If this shows itself to be highly useful as a concept, then I would perhaps avoid reinventing the wheel on the file format side of things, and just standardize what we already have:
- Come up with a file extension (.hmml)
- Decide on an entrypoint filename and format (index.html)
- Use an existing standard for combining resources into one file (tar + zstd)
Now you have something that is usable only using pre-existing tools.
Yeah I agree
in fact this is both a packing strategy or a POV of thinking. Next browser versions could support it.
<img src="html-underdog.hmml" />
or
when tomorrow's genai models mix declarative images with rasters, then they would like something like this
or
OS -> html-underdog.html double clicks -> browser opens it.
This is the sort of weird thing I would come up with - a solution without a problem perhaps, but a magnificent testament to some technical itch that had to be scratched.
I mean,
https://eddocu.com It's the worlds most performant pdf / pptx editor on web.
I have a page that I list documents, each with their thumbnails. I serve medium quality rasters(.webp) for them.
I could rather do it via hmml to save up network space for instance. I convert pdf/pptx/docx into completely editable with html at Eddocu.
So I already have everything in html, css, svg, image.
For the ones that can get represented with .hmml i could serve hmml link maybe.
Its an overengineering maybe.
But thats how I made https://eddocu.com world's most performant pdf/pptx editor. (alpha release, has bugs.)
https://www.nicovideo.jp/watch/sm2796083
A vibe-coded, binary mashup of SMIL and web components. Interesting!
You can also paint by squashing flies against a wall. Doesn't mean it's a good, or efficient, idea.
thats a great observation. In fact, I also tried how efficient wall painting is :D
https://x.com/yeargun24/status/1825516494861508943?s=20
And, yes. HTML & CSS rendering without js is doable with like max 400mb of ram? Idk. Sometimes the tradeoff worths, sometimes not
What wrong with inlining base64 in regular .html if you want it all in one file?
Plus zipping that one file is you insist on a smaller file size
Same zip also helps serving .hmml from cdns smaller (gzip/brotli)
Even then base64 is worse in size though
Also I wouldn't prefer serving a zip and load and render it within my web app (extra overheads).
I don't understand the advantage of this vs an html file with embedded images, except the latter would work with no runtime.
If you plan to serve your image with a self contained, single pack.
Then with html + rasterized images (.jpeg/.png, ..) you would have to pay extra size overhead caused by base64.
With hmml, you dont
I get that, but the drawbacks outweigh the benefits imho and the b64 overhead is not solved, just deferred.
Say I want to distribute an hmml file as a single file, I'd have to create an html with the embedded js runtime, and then embed the hmml file... as b64, therefore negating any benefits.
I would rather see native browser support for the familiar MHTML (https://bugzilla.mozilla.org/show_bug.cgi?id=40873) than creating a brand new format that does the same thing.
The AI slop homepage is really offputting too.
Chrome started supporting this at some point (though I wish they would've added in more support). Lack of support for mhtml is one of the things keeping me away from Firefox on mobile.
Completely agree with that. But look whats the situation with MHTML.
""" Open Bug 40873 Opened 26 years ago Updated 27 days ago """
So if you need some such feature in your web app, and if you are okay with 2kb encode/decode js. Its all good.
At least the posts are pretty much not AI slop I guess.. But I'll take your feedback. Thanks!
This cute homepage provides me with nostalgic memories of Geocities spinning skull GIFs.
> Opened 26 years ago Updated 27 days ago
That's a particularly long discussion.
Isn't this making HTML in some ways more like a PDF? Or am I missing the point?
Nope
PDF is an irreversible format in terms of editability. (btw I build the world's most performant pdf/pptx editor at https://eddocu.com , I would enjoy if you have any feedback)
Regardless, I cant find the relation in between.
It's like an abstraction that might help future genai models, or a packing strategy, or ..
that sounds interesting but can't find clear use cases
In fact it has lots of use cases,
1- For design tools, they can combine multipe images, texts, svgs and serve them with single pack/abstraction
2- When you need editable/composable images.
3- Future genai models for generating visuals/html/js/svg would have more feature rich abstraction/toolset
4- When you want to prevent base64 size overhead
## What's an image
We consider rasters as image (.jpeg, .webp, ..)
We also invented svgs, its a vector. SVG is a declarative language, has its own format and has own renderer
HTML, CSS is no different. `<div style="background:black">html is underdog</div>`
Having this perspective on our mind, even considering any imperative code as a native image makes complete sense. `canvas.drawCircle();`
So, .html/.hmml/.js is as image as .webp
====
## How can we/future's genAI models could leverage the world's most popular and feature rich image format (HTML, CSS, JS, SVG, IMAGE altogether). And how can we leverage it to build editable/composable images?
This so to 'popular' image format we call .html has a caveat. It's UTF-8, and whenever you need to embed any resource, you either need to base64 encode it(it has extra size overhead) or link the resource as a seperate thing. So.. as you decide to serve single pack of data for a single image, a binary packing strategy makes sense.(Image can be anything as we discussed earlier)
To match these concerns, we created/proposing you a new format, HMML (HyperMedia Markup Language).
HMML (HyperMedia Markup Language) is a declarative+imperative markup+ language for images/videos/media.. *HMML is HTML, CSS, JS, SVG, image, but not UTF-8.*
https://hmml.eddocu.com
and we have a npm library that does encode/decode of this binary format, and mounts the so to image into dom. (2kb js for encode/decode each. For comparison React is 90kb js. )
`npm i @eddocu/hmml`
# image-leftdog-rightcat.html
``` <div style="display:flex"> <img src="base64" alt="i am dog image" /> <img src="base64" alt="i am cat image" /> </div> ```
Apart from doing this, hmml does embed the html, css, js blueprint into media binaries
# image-leftdog-rightcat.hmml
`binary stuff`
People already do similar things. But this format or POV of thinking accepts html/css/js as a native image format. Excited to see if future operating systems/browsers also accepts this format. <hmml /> or <img src="maybe.hmml" />
===
``` <Technical-Appendix> The word "green apple" is an image, that has no format and no renderer.
`const vectorMultiDimensional_768 = get_word_embeddings("green apple")` Now the word green apple has a format, its: "embedded by Embedding Model X" If you had a renderer as such Embedding_Model_X.render()
Now you could call entire english sentences/paragraphs are images. </Technical-Appendix> ```
bs or not. what you think?
wait this is actually kinda brilliant in a weird way
like when you think about it we're already doing this with svg and nobody bats an eye. svg is literally xml markup that renders as an image and everyone just accepts it as normal
also the composability angle is interesting. being able to edit an "image" by just opening it in text editor instead of photoshop has some appeal