Bruce Lawson's personal site

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.

• The Fight For Patent-Unencumbered Media Codecs Is Nearly Won by Robert O’Callahan. “”Apple joining the Alliance for Open Media is a really big deal.” … “special thanks to the HEVC patent holders, whose greed gave free-codec proponents a huge boost.”
• Turning Design Mockups Into Code With Deep Learning – show a neural network a design mockup, it spits out HTML and CSS. Quite amazing.
• A letter about Google AMP – “publishers should not be compelled by Google’s search dominance to put their content under a Google umbrella. The Web is not Google, and should not be just Google.”
• Improving URLs for AMP pages – “changes to how AMP works in platforms such as Google Search that will enable linked pages to appear under publishers’ URLs instead of the google.com/amp URL space”
• Permissions on the web suck by Phil Nash
• New Flexbox guides by Rachel Andrew. “I have concentrated on the real use cases of Flexbox, looked at where Grid should be used instead”
• React Food Truck – “a curated set of extensions for discerning React developers who use VS Code.”
• The Future of jQuery UI and jQuery Mobile – “The last few years have been difficult for the jQuery UI and jQuery Mobile projects.”

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.

• Mitigations landing for new class of timing attack – Mozilla shows that the new(-ish) ‘every chip since Morrissey was any good’ security vulnerability can exploited from JS. (And patches Firefox).
• Actions Required to Mitigate Speculative Side-Channel Attack Techniques – what web developers should do to mitigate the ‘every chip since Morrissey was any good’ vulnerability
• What’s behind the Intel design flaw forcing numerous patches? that clever Peter Bright explains it in a way even I can understand.
• Google says CPU patches cause ”˜negligible impact on performance’ with new technique – “We won’t let Spectre / be a slowdown vector” – Larry Page and William Shakespeare
• A Sliding Nightmare: Understanding the Range Input – Ana Tudor investigates styling this one simple form element. I wonder how much JS could be removed from the web, and how much more accessibility we’d get for free if browsers agreed a way to make form elements easily styleable.
• ::part and ::theme, an ::explainer – by Monica Dinculescu
• Screen Reader User Survey #7 Results – from those lovely people at WebAIM
• AccessNow – “We use crowdsourcing to pin-point the accessibility status of locations on an interactive map.” (Android/ iOS)
• Introducing Web Payments: Easier Online Purchases With The Payment Request API by Peter O’Shaughnessy
• LastPass’ Authenticator app is not secure -(Can’t confirm it myself as I don’t use LastPass)
• No boundaries for user identities: Web trackers exploit browser login managers – “a long-known vulnerability in browsers’ built-in password managers is abused by third-party scripts for tracking on more than a thousand sites.”
• Build Your Own React”Š”””ŠA Step By Step Guide – understand how React works by implementing your own virtual DOM, by Ofir Dagan of Wix Engineering
• React’s Accessibility Code Linter
• React.Fragment and Semantic HTML – do what James tells you.
• JavaScript Has Already Won. So here’s a guide to writing Robust Client-Side JavaScript.
• Meet Datally, a new way to understand, control and save mobile data – from Google’s Next Billion Users initiative. Seems like a good replacement for Opera Max, which was “sunsetted”.
• Rated zero – in which Ethan Marcotte looks at the FCC chair Ajit Pai’s assertion that Google AMP is against net neutrality, and whether that justifies the recent FCC decision.
• How the Russian Internet Censor Banned Itself – “More proof that censoring the internet is as difficult as it is futile”
• 8 Medieval Demons that look like Steve Bannon

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.

(Last Updated on 20 February 2018)