Using some good old obsolete HTML to create JavaScript-free animations | Hacker News Reader

Using some good old obsolete HTML to create JavaScript-free animations

medium.com

106 pointsmjtweaver39 comments

Highly recommend svg for animations too. Totally JS-free, self-contained files, supported by all browsers but Microsoft (can just show static svg)... Once you get the hang of the syntax and svg layout, animating is pretty straightforward.

Here's a fun 404 page I made that shows just how extensive an animation you can accomplish (let it play for > 1 minute) - https://app.astronomer.io/404

(You can open the image in a new tab and take a look at the svg code (it's --pretty printed)

The problem with SVG animation is it seems to be abnormally resource intensive. I noticed it on a project I worked on recently -- simply pulsing a few <circle>s larger and smaller pegged a CPU core at a constant 40% on my work machine. Indeed, opening your (very cool) 404 page shows a constant 30% CPU usage.

Fine for a 404 page which people are unlikely to stick around on, not fine for a screen that someone is going to spend a significant amount of time on.

My Firefox jumps from about 6% to 10% on that page... Noticeable, but not nearly as bad as you're seeing.

How many cores do you have? If you have 8 it is scarily close to 100% for a single core.

What browser/OS/hardware configuration is this? I have never observed such an effect before.

I'm working on speeding this up via the Pathfinder project, for Firefox. :)

awesome - I enjoyed reading up on your work! stuff like this makes me wonder if variable fonts will become a popular method for animating certain things on the web (maybe in the context of UI kits like font awesome, ionicons, etc).

it still kind of blows my mind how quickly we all moved to abandon adobe flash once HTML became viable. I'm not a fan of the attack surface that flash presents, but in retrospect, especially thinking about the hardware I was using 15 years ago, it almost seems like advanced alien technology when contrasted with the state of vector animation on the web today.

Do you know by any chance if support for new SVG standard will ever land?

That is indeed inspiring. Running very smoothly even on an old iPhone I tested it with. I will implement something using animated SVG for the 404 and 500 error pages of our webapp.

Don’t do it. Not worth it. Once you get into transforms it’s a waste of time. Anything more complex than a couple `animate` elements and you’re better off with a mini JavaScript lib.

I used to spend time on this but when a little animation takes two hours then you stop.

It's not so bad once you figure to create a new <g> tag for every animation. But yeah, there's a lot of trial and error to it (as with any design work)... unless you want to really mentally nail down the coordinate system.

The image is downloaded by JS code (via astronomer.io's API) :|

Well yeah it's a react app... here's a link to the raw svg file on our cdn - https://cdn.astronomer.io/app/img/astronaut.svg

Beautiful, but it took a long time (~7 seconds) to paint when viewing it in Brave on an Android Pixel. I'm on a 4g connection. This is a lot to ask of users, for a page that ultimately tells you there's nothing to look at. I haven't experimented with skeleton loading placeholders for SVG heavy presentations, but it may be suitable here.

Interesting, will have to look into that... the file itself is only 27kb. So a normal placeholder while it downloads wouldn't do much. I'm not sure if there's a way to set a loading placeholder while the svg paints? ie is there an event for when it's finished painting?

it's because you load a huge 2.4 MB JS file, and your web server is configured terribly so gzip is off so it really is 2.4 MB.

If that's true, then pity the mobile users on a capped data plan.

There are a lot nicer ways to say that FYI

Nice animation! Thanks for the Easter egg hint. Loaded immediately on Safari/iPhone 8+ and was butter smooth.

What tool did you use to author the SVG file? And presumably you optimized it as well?

Inkscape for graphics. Text editor for animations. svgo to optimize.

Loved the finale

Have a look at bodymovin / Lottie, I appreciate the handmade approach but might save you a bunch of time

Nice! I made an SVG animation myself, but I used embedded CSS animations instead of SMIL: http://nin.ten.dog/img/shibe.svg

The irony is that I needed to allow Javascript from three different domains (medium.com, embedly.com, codepen.io) to see the demos of these Javascript-free animations.

Yeah - you can actually implement surprisingly complex motion by nesting <marquee> tags with different directions, speeds, etc.

I posted this long time ago: http://lcamtuf.coredump.cx/marquee.html

The thing that surprised me most about this is that the marquee element is still supported: I'd just assumed it had long since gone the way of the blink tag.

And then this got me wondering whether, if you'd done this back in say the year 2000, would it have been possible to animate images in this way back then? I certainly saw plenty of uses of the marquee tag (although my recollection was it got a fairly comprehensive slagging even in the HTML4 book I had at the time, published in 1998, so it was already pretty heavily discouraged) but it was always text, never images. I also don't remember seeing any sites with nested marquee tags, but I wonder if that would have worked too?

Interesting piece anyway.

I'd be really interested in seeing examples of the most dynamic websites can get with HTML only. Penalties for using CSS but that's fine, too. Does anyone have pointers?

In theory... not interactive at all. HTML is supposed to be structure only. There are a few exceptions (blink and marquee tags), so this page pretty much shows the extent.

(If you allow CSS, you can do pretty much anything JavaScript can do.)

Fun fact: neither the <marquee> element or the <blink> element have ever been part of any HTML specification.

It's in HTML5 (described as obsolete, but defined)

Yes. I was waiting for someone to bring that up. It's there for the sole purpose of marking it obsolete as a warning so browsers can eventually remove it. No, you won't find a definition for that element anywhere with WHATWG though the W3C has one.

I was actually surprised how detailed the WHATWG specification is for something that's been "not recommended" for ages, but I guess they document everything that's still implemented: https://html.spec.whatwg.org/multipage/rendering.html#the-ma...

(I believe <blink> support has actually been dropped by at least some browsers)

HTML + CSS is Turing complete so depending on your definition of interactive, pretty much anything

Turing completeness means you can't compute stuff, it does not take user interaction into account.

I don't see any definition of "interactive" that would convince someone that lambda calculus is interactive, despite it being Turing complete.

Fun to remember but obviously useless at this point thanks to CSS animations — which are eased, interactive and more complex than x/y movements.

Obligatory:

http://shouldiuseacarousel.com/

...but a carousel using the marquee tag?

Definitely. Maybe throw in some inline CSS for good measure, maybe sticking to web safe colour gifs too.

I don't know if they did it intentionally, but that was one of the worst implementations/uses of a carousel i've seen yet -- scrolls every like 2 seconds, so you can't even finish reading a sentence; have to keep hitting back to try and read each block.

After looking at those "studies", it really seems like nobody is using it appropriately, not that carousels are actually bad: too fast; not clear its a carousel; broken implementations; being surprised when people click the first item, despite that probably being the item they were looking for.

To add, if only 1% are clicking the first item, perhaps reconsider what people care about and are looking for, because clearly they don't :)

Interesting to say the least!

Reply on news.ycombinator.com