HTML is a native image format, hear me out

Is it HTML and its contents (e.g. images) in a binary format?

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_...

Why the comparison with Base64 when Base64 itself has approximately 33% size overhead?

I got lost

- 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.

  data:image/svg+xml,
  <svg xmlns="http://www.w3.org/2000/svg">
    <foreignObject width="100%25" height="100%25">
      <div xmlns="http://www.w3.org/1999/xhtml">
        Behold!
      </div>
    </foreignObject>
  </svg>

Plus zipping that one file is you insist on a smaller file size

All we need is browsers to render Served MHTML

And JS Support in MHTML

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.

The AI slop homepage is really offputting too.

The frequency of these things certainly rose with AI.

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?

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?

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