it downloads single binary that contains media assets (svg, image, video, ..)
and html/css blueprint,
even js (security concerns!)
roywiggins 20 hours ago [-]
Common side-effect of letting Claude write your landing page.
Apparently it's mostly this:
// ENCODE — pack(html) → one .hmml (a Uint8Array you store or send)
// · lifts every data: image out of the HTML into raw bytes (no base64)
// · gzips the HTML/CSS/JS and frames it all as one binary blob
chrismorgan 19 hours ago [-]
I’ll engage with the editorialised title (which will probably be changed soon), “HTML is a native image format, hear me out”:
That's pretty much what I was thinking too. "A way to create an image, with parts that can be edited using tags, that an LLM can deal with... this sounds like SVG"
yeargun 19 hours ago [-]
yes but not every image/visual is efficiently representable with svgs. sometimes we need rasters
yeah but you know.. it needs to be either base64 or a link
thats why .hmml is a packing strategy to mitigate that, single pack
chrismorgan 18 hours ago [-]
In case you missed it—I’m not showing regular SVG, I’m showing using HTML as an image, via an SVG container. This has worked fine in browsers for more than ten years (around twenty, other than IE/Edge).
yeargun 16 hours ago [-]
yeah I saw it, thats a crazy trick
AbuAssar 19 hours ago [-]
this page failed to convey what exactly is the main pitch, is it a new image format? using html as image? rendering with canvas?
So gzipped base64 can add less than 1% overhead. Of course a binary format can be even more efficient (also when decoding, I imagine) but the question is if the difference is big enough to introduce an entirely new format when base64 data URIs are already widely supported.
Then the other question is why this proposed packed format is better than the dozen already existing formats like Web Archive, CHM, MAFF, MHTML, etc.
blixt 20 hours ago [-]
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.
yeargun 20 hours ago [-]
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.
assimpleaspossi 19 hours ago [-]
Note: the <img> tag does not use and does not need a closing slash and never has in any HTML specification.
yeargun 19 hours ago [-]
Same HTML specification does not support .hmml
Until they support .hmml imma close my image tags. But thanks for highlighting
(its a joke)
assimpleaspossi 19 hours ago [-]
Closing an <img> tag with a slash has no meaning. It does nothing. And browsers ignore it. So it's pointless cause <img> is self-closing by itself.
malicka 19 hours ago [-]
Unless you’re the type who wants their HTML to be valid XHTML! :^)
wewewedxfgdf 20 hours ago [-]
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.
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
yeargun 19 hours ago [-]
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).
ricardobeat 19 hours ago [-]
A vibe-coded, binary mashup of SMIL and web components. Interesting.
If the goal is self-contained documents, is there anything here that can’t be achieved with SVG alone, using SMIL [1] and embedded HTML via <foreignObject>? Or an existing engine like Rive?
1- html/css has more layout capabilities.
2- js
3- its a packing strategy. If you plan to serve images + svgs altogether, either you need to base64 encode or pack like hmml, binary
19 hours ago [-]
19 hours ago [-]
mpeg 20 hours ago [-]
I don't understand the advantage of this vs an html file with embedded images, except the latter would work with no runtime.
yeargun 20 hours ago [-]
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
mpeg 19 hours ago [-]
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.
G_o_D 19 hours ago [-]
Isnt MHTML : THE HTML+CSS WITH BINARY Images embedded.A perfect Snapshot of site.
Chrome started supporting this at some point (though I wish they would've added in motw support). Lack of support for mhtml is one of the things keeping me away from Firefox on mobile.
Tade0 20 hours ago [-]
> Opened 26 years ago Updated 27 days ago
That's a particularly long discussion.
bjt12345 20 hours ago [-]
This cute homepage provides me with nostalgic memories of Geocities spinning skull GIFs.
yeargun 20 hours ago [-]
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!
c048 20 hours ago [-]
You can also paint by squashing flies against a wall. Doesn't mean it's a good, or efficient, idea.
yeargun 20 hours ago [-]
thats a great observation. In fact, I also tried how efficient wall painting is :D
And, yes. HTML & CSS rendering without js is doable with like max 400mb of ram? Idk. Sometimes the tradeoff worths, sometimes not
nobrains 19 hours ago [-]
That "view page source" took some loong time to load.
t1234s 19 hours ago [-]
Looks like reinventing macromedia flash
19 hours ago [-]
webdevnotlame 20 hours ago [-]
that sounds interesting but can't find clear use cases
yeargun 20 hours ago [-]
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
CMay 18 hours ago [-]
We already have iframe and the srcdoc attribute which you can set directly to the document contents without pointing to an external url. So there's nothing new about that. This is primarily about serializing page content more efficiently than the naive approaches.
Advertisements are also generally content in iframes. The only difference here really is that you want the content to be blobs and embedded in the page rather than needing to be loaded from a URL.
You can design websites to be modular even without iframes or without this and many are. One thing to note is that looking at your website, you basically can't tell it apart from any other website. Because websites already effectively manage essentially the same result, but with assets shared across more of the page usually.
The point seems to be, a push to increase the adoption of a combined modularized serialized content approach beyond any scenarios where it's already used, to more closely tie the rich behaviors and the media itself into a single file.
Trust me, I get it. Macromedia Flash was neat. It was nice to have these modular little animation machines you could plop anywhere in a page and it was its own little world. An encapsulation that stood apart, but played nicely together with the rest of it. You also see something similar with the javascript flash players, or with the javascript decoders for image formats that web browser didn't support yet, they have to read the raw bytes and feed the image to the browser.
It's also similar to the difference between local variables and global variables in code. Yes, global variables can be reused a lot and there is some efficiency to be gained there in cases, but you can also simplify side effects by using local variables where you know exactly what can and cannot happen.
I don't think you need to present it as a new paradigm that defines the future on top of what already exists, because this isn't exactly new.
There are a few obvious issues, though. One is that you'll still have to do something about the content security headers and make sure any code inside the blob is allowed to run or even if its safe to run. The fact that it's harder to inspect in its serialized form can increase the amount of effort involved in evaluating whether you want to use it. It's also more effort to swap the content inside of it out, which is actually a cost you pay in making your content less modular at a lower granularity. That makes it less mindlessly plug and play compared to a regular image or video, but it might not be too much extra trouble.
Another is that it does not degrade nicely if javascript is disabled entirely and probably doesn't help search engines find your content. Having to support a fallback would negate a lot of the purpose of doing it at all outside of offline self contained simplicity scenarios.
Trust is a bigger issue now than before and this still comes across as an unnecessary hack that has specific use cases (which can be great), but it's being branded as if it should be generally applied as widely as images. I disagree with that.
I like modularity, so if this gets some people to pick it up as a tool to solve their modular problems that's great. Not sure this would be good for the web if it scaled up, though. For offline scenarios however, things like this are great, but the base64 savings there matter less anyway.
yeargun 17 hours ago [-]
Yeah yeah, tbh even though I branded it like that in the website, packing strategy & overall, its pretty much an apparent technology/library. I realy wanted some such technology 2 years ago, while genai text layouts were lame ash, and I questioned why noone does something like this (diffusion does not play well, or we havent figure it out yet, who knows? https://blog.google/innovation-and-ai/technology/developers-... )
And overall one of the exciting part for me is, to be able to have composable & editable images, hopefuly generated by future genAI models.
And finally, I just realy wanted to rant over what a 'digital image' is
CMay 10 hours ago [-]
That's one of the blessings and the curses of the flexibility of web technologies. They're easy to abuse, or repurpose and see the everyday normal things from new perspectives. That can be good, or it can be bad. There are often many ways to achieve the same thing.
Decades ago there were cool ideas that I loved that simply never took off. They faded away into obscurity. The technology isn't always that important to keep, but the love is. Keep feeling excited about things even if people don't buy into them, because nurturing that feeling of excitement for possibilities is usually more important than today's thing. It's something that can pull you forward to keep trying things. You'll cover a lot of ground that other people already did decades ago, but eventually you'll hit things nobody else did and that becomes important.
Semaphor 19 hours ago [-]
Opened. Had some typing animation make the page jump around because the text would switch between one and two lines. Closed the slop.
The frequency of these things certainly rose with AI.
yeargun 18 hours ago [-]
Slop :D
can you revisit please? What browser are you using ?
The library is not curing cancer
And also it's the first time im hearing that its not working.
Isn't this making HTML in some ways more like a PDF? Or am I missing the point?
yeargun 20 hours ago [-]
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 ..
TZubiri 19 hours ago [-]
Not the first time I saw this Hero header with text that's being written in real time, which is very cute but actually causes the layout to change every second.
I guess it happens when people vibecode and the llm generates code, and it cannot verify that the interface actually works well. Even with agents that use drivers either directly or through playwright/selenium, they might only see a single screenshot, so no video.
Anyways, immediately stopped reading, as the new adage goes, why should I read something you weren't bothered to write?
19 hours ago [-]
19 hours ago [-]
plating1 20 hours ago [-]
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
ultracakebakery 19 hours ago [-]
[flagged]
yeargun 21 hours ago [-]
## 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.*
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>
```
Is it HTML and its contents (e.g. images) in a binary format?
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!)
Apparently it's mostly this:
thats why .hmml is a packing strategy to mitigate that, single pack
I got lost
in the meantime you can take a look at this
https://www.reddit.com/r/Design/s/hv0hyBow9I
Why the comparison with Base64 when Base64 itself has approximately 33% size overhead?
You have 2 options.
- Embed images into html (base64, size overhead)
- embed html/css/js into media binaries
.hmml is the packing strategy for option two. 2kb js for encode/decode. And extra rantings around what a 'digital image' is
- Save the page as a self-extracting ZIP file, see https://github.com/gildas-lormeau/Polyglot-HTML-ZIP-PNG
.hmml might be more hassle free then zip options for web apps. With zips, I think it will require more js bundle & processing to work.
meanwhile with .hmml, its already gzip/br compressed in cdns, and decoded natively by the browser
Then the other question is why this proposed packed format is better than the dozen already existing formats like Web Archive, CHM, MAFF, MHTML, etc.
- 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.
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.
Until they support .hmml imma close my image tags. But thanks for highlighting
(its a joke)
people are crazy for sure
https://youtu.be/O_nE4O5JRBQ
Plus zipping that one file is you insist on a smaller file size
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).
If the goal is self-contained documents, is there anything here that can’t be achieved with SVG alone, using SMIL [1] and embedded HTML via <foreignObject>? Or an existing engine like Rive?
[1] https://developer.mozilla.org/en-US/docs/Web/SVG/Guides/SVG_...
1- html/css has more layout capabilities. 2- js 3- its a packing strategy. If you plan to serve images + svgs altogether, either you need to base64 encode or pack like hmml, binary
Then with html + rasterized images (.jpeg/.png, ..) you would have to pay extra size overhead caused by base64.
With hmml, you dont
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.
All we need is browsers to render Served MHTML
And JS Support in MHTML
The AI slop homepage is really offputting too.
That's a particularly long discussion.
""" 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!
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
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
Advertisements are also generally content in iframes. The only difference here really is that you want the content to be blobs and embedded in the page rather than needing to be loaded from a URL.
You can design websites to be modular even without iframes or without this and many are. One thing to note is that looking at your website, you basically can't tell it apart from any other website. Because websites already effectively manage essentially the same result, but with assets shared across more of the page usually.
The point seems to be, a push to increase the adoption of a combined modularized serialized content approach beyond any scenarios where it's already used, to more closely tie the rich behaviors and the media itself into a single file.
Trust me, I get it. Macromedia Flash was neat. It was nice to have these modular little animation machines you could plop anywhere in a page and it was its own little world. An encapsulation that stood apart, but played nicely together with the rest of it. You also see something similar with the javascript flash players, or with the javascript decoders for image formats that web browser didn't support yet, they have to read the raw bytes and feed the image to the browser.
It's also similar to the difference between local variables and global variables in code. Yes, global variables can be reused a lot and there is some efficiency to be gained there in cases, but you can also simplify side effects by using local variables where you know exactly what can and cannot happen.
I don't think you need to present it as a new paradigm that defines the future on top of what already exists, because this isn't exactly new.
There are a few obvious issues, though. One is that you'll still have to do something about the content security headers and make sure any code inside the blob is allowed to run or even if its safe to run. The fact that it's harder to inspect in its serialized form can increase the amount of effort involved in evaluating whether you want to use it. It's also more effort to swap the content inside of it out, which is actually a cost you pay in making your content less modular at a lower granularity. That makes it less mindlessly plug and play compared to a regular image or video, but it might not be too much extra trouble.
Another is that it does not degrade nicely if javascript is disabled entirely and probably doesn't help search engines find your content. Having to support a fallback would negate a lot of the purpose of doing it at all outside of offline self contained simplicity scenarios.
Trust is a bigger issue now than before and this still comes across as an unnecessary hack that has specific use cases (which can be great), but it's being branded as if it should be generally applied as widely as images. I disagree with that.
I like modularity, so if this gets some people to pick it up as a tool to solve their modular problems that's great. Not sure this would be good for the web if it scaled up, though. For offline scenarios however, things like this are great, but the base64 savings there matter less anyway.
And overall one of the exciting part for me is, to be able to have composable & editable images, hopefuly generated by future genAI models.
And finally, I just realy wanted to rant over what a 'digital image' is
Decades ago there were cool ideas that I loved that simply never took off. They faded away into obscurity. The technology isn't always that important to keep, but the love is. Keep feeling excited about things even if people don't buy into them, because nurturing that feeling of excitement for possibilities is usually more important than today's thing. It's something that can pull you forward to keep trying things. You'll cover a lot of ground that other people already did decades ago, but eventually you'll hit things nobody else did and that becomes important.
The frequency of these things certainly rose with AI.
can you revisit please? What browser are you using ?
The library is not curing cancer And also it's the first time im hearing that its not working.
My goal was to discuss the meaning of what a 'digital image' is.. You can also take a look at this https://www.reddit.com/r/Design/s/7KLKg3wS0D
https://imgur.com/a/KjrSTjk
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 ..
I guess it happens when people vibecode and the llm generates code, and it cannot verify that the interface actually works well. Even with agents that use drivers either directly or through playwright/selenium, they might only see a single screenshot, so no video.
Anyways, immediately stopped reading, as the new adage goes, why should I read something you weren't bothered to write?
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
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?