Archive for January, 2018

Video as the new GIF in Safari

The latest pre-release of the next version of Safari is chock-full of exciting web technologies like Service Worker, Web App Manifest, Payment Request API. Congratulations to the webkit team – this looks to be great work.

One aspect of the release hasn’t met with universal acclaim, however. That’s the ability to have a short, silent video as the source of an <img> element:

<img src="adorable-cat.mp4" alt="adorable cat tears throat out of owner and eats his eyeballs">

This is basically designed to do the same job as an animated GIF, but more performantly. As Colin Bendell writes,

Early results show mp4s in <img> tags display 20x faster and decode 7x faster than the GIF equivalent – in addition to being 1/14th the file size!

People have commented that this isn’t “standard” – but there is no “standard” for the format of images. We’ve used GIF, JPG and PNG because they’re supported everywhere. But nowhere is there a prescription of what kind of images are allowed or disallowed on the <img> element.

Animated GIFs were always a hack; the GIF specification says

The Graphics Interchange Format is not intended as a platform for animation, even though it can be done in a limited way.

The best way to serve mp4 images with fallback to GIF etc for non-supporting browsers is to use the <picture> element, which was invented by a team of legendarily gorgeous chaps, and Marcos Cáceres:

<picture>
  <source type=video/mp4 srcset=adorable-cat.mp4>
  <img src=adorable-cat.gif alt="adorable cat tears throat out of owner and eats his eyeballs">
</picture>

However, as Colin Bendell also writes

there is this nasty WebKit bug in Safari that causes the preloader to download the first <source> regardless of the mimetype declaration. The main DOM loader realizes the error and selects the correct one. However, the damage will be done. The preloader squanders its opportunity to download the image early and on top of that, downloads the wrong version wasting bytes. The good news is that I’ve patched this bug and it should land in Safari TP 45.

Given that these mp4 animations will not play sound (so make sure you strip out the audio to make it even smaller), and are more performant than GIFs, I welcome this addition from the webkit team.

Reading List

Reading List

Happy New Year! As usual, my Reading List is sponsored by the lovely people at Wix Engineering who give me money to look at interesting shit, and when I find some I put it here.

RFC: named parameters in Stylable custom values

Howdy, gentle readers, and happy 2018.

I have a little question for you. With Wix Engineering, I’ve been working on a CSS pre-processor that extends CSS to make it easier to style component-based web apps (you can read more about it in my 24ways article Styling Components – Typed CSS With Stylable).

One of the design principles is that working with Stylable should be as simple as working with CSS, and not break your tooling. So, for example, transpiler directives are given a “vendor prefix” of -st- so they’re valid CSS syntax and therefore won’t throw an error in syntax highlighters etc (even though they’re transpiled away into valid CSS at build time).

And here’s where I want to pick your brains.

In our mixins, we want to pass named parameters in a custom value, like this:

.root {
  -st-mixin:
   --Theme(
     color1:green,
     color2:red
     )
   }

The double-hyphen syntax is allowed as a custom property (it’s actually an “empty” vendor prefix), so we’re borrowing that for a custom value.

Passing the named parameters color1 with a value of green and color2 with a value of red is trickier. The colon syntax feels more “CSS-y” (and is similar to that used by SASS) and works nicely with postcss and postcss-value-parser. However, any IDE that we tried that doesn’t have Stylable language intelligence raised an error on the colon between the param name and value.

We could support named params with a space as separator between name and value:

.root {
  -st-mixin:
   --Theme(
     color1 green,
     color2 red
     )
   }

But that just feels ugly and wrong. I’ve asked the Houdini working group but suspect that even if a colon were eventually allowed here, we need to go with a space for the time being, just to avoid IBS (IDE barfing syndrome).

What do you think?

Update 20 February: Tab Atkins’ answer.