31–40 of 64 posts
data:image/svg+xml,
Behold!
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…
Yeah I agree in fact this is both a packing strategy or a POV of thinking. Next browser versions could support it. 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.
Earlier quoted context omitted.
Yeah I agree in fact this is both a packing strategy or a POV of thinking. Next browser versions could support it. 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.
Note: the tag does not use and does not need a closing slash and never has in any HTML specification.
Until they support .hmml imma close my image tags. But thanks for highlighting
(its a joke)
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 ? 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?
Earlier quoted context omitted.
Note: the tag does not use and does not need a closing slash and never has in any HTML specification.
Same HTML specification does not support .hmml Until they support .hmml imma close my image tags. But thanks for highlighting (its a joke)