Brian Birtles’ Blog

Lessons learned switching to Rspack

Wed, 14 Aug 2024 00:00:00 GMT

NOTE: This post was published while Rspack’s latest version was v1.0.0-beta.4. Some details are likely to change as Rspack approaches its 1.0 release.

Rspack is a Rust-based alternative to Webpack that promises to be faster and includes a few common conveniences too. After a year of trying, I’ve finally finished converting my two largest Webpack projects to Rspack. Here are some of the things I learnt along the way.

Why Rspack?

First, however, why choose Rspack? For me it’s because I’m already using Webpack for my two largest projects and Rspack offers a comparatively simple and low-risk upgrade compared to other build tools. The build times for these projects are also slow enough that speeding them up could make a worthwhile difference to productivity and CI costs.

But while we’re switching build tools, why not switch to Vite? A lot of people have switched from Webpack to Vite and seem to love it. The reasons I decided to go with Rspack for these particular projects are:

Coming from Webpack, it’s a much simpler and less risky upgrade path.
From what I can tell, Vite’s on-demand file serving appears to shine in SSR contexts like Next.js apps but I’m using Webpack for an SPA and a Web extension where this matters less.
My experience with Vite so far hasn’t been great.
I like to keep dev and prod builds as close as possible so I can confidently test what I’m shipping. Vite is weak in this area with its esbuild-based dev mode and Rollup-based prod builds. In fact, I found the gap so large that I gave up implementing some features in dev mode with Vite because it was too much effort to implement them twice.
Rspack is apparently faster than Vite, at least in the areas that matter to me.

Perhaps the biggest problem with Rspack is that, like Webpack, it’s not easy to get started with and that appears to be why the Rspack team have also produced Rsbuild as a more approachable layer on top of Rspack.

Lessons learned along the way

The steps involved in migrating from Webpack are covered in Rspack’s Webpack migration guide so what follows are the things I learned that weren’t covered there or that might not be obvious.

TypeScript

Rspack uses SWC to transpile TypeScript which means you no longer need ts-loader. However, after building with Rspack, I noticed that the generated JS assets were a lot bigger than when using Webpack and ts-loader.

It turned out that a lot of boilerplate was being generated for features like async iterators. In the Webpack build ts-loader was picking up my tsconfig.json which specified "target": "es2020" so these features were not being downleveled. In Rspack, however, SWC was downleveling them to ECMAScript 5. The solution was to specify the target for SWC in the Rspack config.

For example:

const config = {
  module: {
    rules: [
      {
        test: /\.ts$/,
        exclude: /node_modules/,
        use: {
          loader: 'builtin:swc-loader',
          /** @type {import('@rspack/core').SwcLoaderOptions} */
          options: {
            sourceMap: true,
            jsc: {
              parser: {
                syntax: 'typescript',
              },
              target: 'es2022',
            },
          },
        },
        type: 'javascript/auto',
      },
      // ... similarly for tsx files
    ],
  },
  // ...
};

I believe it’s also possible to achieve this by specifying browser versions using the env.targets setting.

Even after doing that, however, the JS assets generated by Rspack were still larger but when 1.0 alpha enabled optimization.concatenateModules by default they fell to within 3% of their Webpack counterparts and were sometimes fractionally smaller.

Type checking

One consequence of using SWC to transpile TypeScript is that type checking is no longer performed. You’ll need to enable isolatedModules in your tsconfig.json and work out when and how you want to perform type checking.

I opted to use fork-ts-checker-webpack-plugin as recommended by the official docs but on reflection, I wonder if that’s even necessary. Assuming you have your editor set up to perform type checking and you run tsc in CI, and perhaps as a pre-commit hook too (e.g. using tsc-files), then you might not even need to perform type checking on each build.

Using Webpack I was ignoring certain TypeScript errors during development so that they didn’t interrupt me while refactoring like so:

use: {
  loader: 'ts-loader',
  options: env.ignoreUnused
    ? {
        ignoreDiagnostics: [
          6133 /* <variable> is declared but its value is never read */,
          6192 /* All imports in import declaration are unused */,
        ],
      }
    : undefined,
}

With Rspack, if you’re performing type checking using fork-ts-checker-webpack-plugin, you can pass in similar options there instead:

new ForkTsCheckerWebpackPlugin({
  issue: {
    exclude: env.ignoreUnused
      ? [
          // <variable> is declared but its value is never read
          { code: 'TS6133' },
          // All imports in import declaration are unused
          { code: 'TS6192' },
        ]
      : [],
  },
}),

CSS

Although the migration guide mentions replacing mini-css-extract-plugin with rspack.CssExtractRspackPlugin, the documentation for CssExtractRspackPlugin states:

If your project does not depend on css-loader, it is recommended to use the built-in CSS solution experiments.css of Rspack for better performance.

As a result, for my Web app project, I was able to update my CSS configuration from:

// rspack.config.js
const config = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          { loader: MiniCssExtractPlugin.loader },
          {
            loader: 'css-loader',
            options: {
              url: false,
              importLoaders: 1,
            },
          },
          {
            loader: 'postcss-loader',
          },
        ],
      },
      // ...
    ],
  },
  // ...
};

To just:

const config = {
  experiments: {
    css: true,
  },
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [{ loader: 'postcss-loader' }],
        type: 'css/auto',
      },
      // ...
    ],
  },
  // ...
};

However, I noticed my CSS assets were ~11% larger than those generated from Webpack. Comparing the output, I discovered that the Rspack output was not performing some optimizations like converting rgba() colors to hex values.

By default Rspack uses Lightning CSS to minimize CSS assets and it turns out the features Lightning CSS uses as part of its default settings are very conservative. After adding some more recent values to the minimizerOptions.targets property Rspack’s output was slightly smaller than Webpack’s:

  optimization: {
    // ...
    minimizer: [
      new rspack.SwcJsMinimizerRspackPlugin({
        // ...
      }),
      new rspack.LightningCssMinimizerRspackPlugin({
        minimizerOptions: {
          targets: [
            'last 2 Chrome versions',
            'Firefox ESR',
            'last 2 Safari versions',
          ],
        },
      }),
    ],
  },

Update (2024-08-17): It looks like the Rspack team have taken note of this and added default targets for Lightning CSS in beta 5!

Service workers

My app includes a Service Worker and relies on the InjectManifest plugin from Google’s Workbox to trigger the generation of the Service Worker asset and populate it with a precache manifest. Unfortunately when I went to migrate my app, this plugin wasn’t supported by Rspack.

Rspack 1.0.0-alpha.0, however, added native support for recognizing Service Workers (and various kinds of worklets too). It’s a little bit quirky in that you need to pass a URL object to navigator.serviceWorker.register() (not a string) and you can’t pass a variable referring to a URL object either.

For example, the following would cause a chunk to be generated for the service worker at sw.ts:

const registrationPromise = navigator.serviceWorker.register(
  new URL(
    /* webpackChunkName: "serviceworker" */
    './sw.ts',
    import.meta.url
  )
);

You also need to take care to ensure the service worker chunk ends up with a fixed filename rather than one with a cache-busting hash in it:

// rspack.config.js
const config = {
  // ...
  output: {
    chunkFilename: (assetInfo) => {
      if (assetInfo.chunk?.name === 'serviceworker') {
        return '[name].js';
      }
      return '[name].[contenthash].js';
    },
  },
};

However, all that still won’t help with embedding a precache asset manifest like InjectManifest does. I tried various alternatives but none of them seemed to work with Rspack’s native service worker support so I ended up writing my own by extracting just the needed parts of Workbox’s InjectManifest plugin and adapting them to Rspack.

Since then, Rspack have announced that Workbox is fully supported. My package is smaller and seems to work better than Workbox when making changes so I’ll stick with it for now but I’m sure most people will be happy to continue using Workbox as-is.

One quirk of the native Service Worker support, however, is that it appears to run before dead code elimination. As a result, if you are using build-time constants to disable service worker registration like in the following code, you may find the service worker asset is still generated even though it’s not referenced anywhere.

function registerServiceWorker() {
  if (!('serviceWorker' in navigator) || !__ENABLE_SW__) {
    return Promise.resolve(null);
  }

  // The following code will be eliminated when __ENABLE_SW__
  // is falsy, but the sw.js asset will still be generated.
  const registrationPromise = navigator.serviceWorker.register(
    new URL(
      /* webpackChunkName: "sw" */
      './sw.ts',
      import.meta.url
    )
  );

  // ...

  return registrationPromise;
}

React Cosmos

Perhaps the biggest hurdle in migrating to Rspack was getting React Cosmos to play with it. I’m a big fan of React Cosmos for developing and testing components because I found that unlike Storybook it doesn’t require a lot of additional development dependencies but works with your existing bundler instead.

Unfortunately React Cosmos does not include support for Rspack, only Webpack, Vite, and a few others. It includes instructions on how to configure a custom bundler but I figured, “How hard can it be to port the Webpack plugin to Rspack?”

The answer, it turned out, was “quite hard” mostly due to me insisting on building the plugin with tsup and getting confused about how each endpoint should be bundled. A few weeks later, however, react-cosmos-plugin-rspack was born offering a drop-in replacement for the Webpack plugin.

Knip

The final dependency requiring attention was Knip. Knip is a tool for detecting unused cruft—dependencies, exports, files, etc.—in your project. If it sees you are using Webpack, it will look up your Webpack config and detect your project’s entrypoints, Webpack plugins etc. and analyze your project accordingly. Unfortunately, it didn’t know about Rspack.

My company is a sponsor of Lars’ work on Knip so I reached out to see if we could commission a Knip plugin for Rspack. Lars jumped on it and invited others to join in the crowdfunding and a few days later it was complete.

As a result, Knip detected that I no longer needed any of the following dependencies:

clean-webpack-plugin (replaced by output.clean)
copy-webpack-plugin (replaced by rspack.CopyRspackPlugin)
css-loader (replaced by experiments.css)
mini-css-extract-plugin (replaced by experiments.css)
react-cosmos-plugin-webpack (replaced by react-cosmos-plugin-rspack)
ts-loader (replaced by builtin:swc-loader and fork-ts-checker-webpack-plugin)
webpack, webpack-cli (duh)
webpack-dev-server (built into @rspack/cli)
workbox-webpack-plugin (replaced by @birchill/inject-manifest-plugin)

Command-line flags

Rspack CLI includes a built-in dev server but unfortunately, the command-line flags differ from webpack-dev-server in a few places, notably missing options like --port and --hot/--no-hot.

To handle such cases I ended up using various --env values and checking them in rspack.config.js’s configuration function. This seems like a potentially unnecessary point of friction that could be eased in a future release.

Update (2024-09-05): This has been fixed in version 1.0.1!

Rsdoctor

The Rspack team have helpfully created a plugin, Rsdoctor for analysing your bundle and its build times. For what it’s worth, I ended up with the following configuration:

new RsdoctorRspackPlugin({
  disableTOSUpload: true,
  linter: {
    rules: {
      // Don't warn about using non ES5 features
      'ecma-version-check': 'off',
    },
  },
  supports: { generateTileGraph: true },
});

What didn’t change

Apart from the above changes, everything else appeared to work as-is including the following plugins:

I also use the Bugsnag Webpack plugins but they only run on a new release so I haven’t had a chance to test them yet.

Results

So how much faster is Rspack after all?

For my SPA project I saw the following results:

| Environment | Webpack | Rspack | Rspack without type checking | | ------------ | ------- | --------------- | ---------------------------- | | Home laptop | 19.1s | 8.1s (-57.7%) | 3.04s (-84.16%) | | Work desktop | 13.24s | 5.57s (-57.94%) | 2.44s (-81.61%) |

Since type checking is performed in a separate process, most of the time you’re only waiting on the build and the final column is what matters most.

Furthermore, if I am reading the results of Rsdoctor correctly, it seems that most of the compile time comes from postcss-loader so I hope that when Tailwind 4 is released I can switch to using builtin:lightningcss-loader instead and see further improvements to the compile time.

For my Web extension project, the improvements were even more significant, going from 11.65s to 3.6s (69% faster) on my desktop computer even with type checking enabled.

Update (2024-09-05): The Rspack team have added a list of performance bottlenecks. In addition to postcss-loader I am also using html-webpack-plugin from that list. I currently need that in order to use html-webpack-inject-preload (since it checks for the HtmlWebpackPlugin constructor name). If I can migrate that to work with HtmlRspackPlugin it might improve the build time further.

Looking forward

As Rspack is approaching 1.0, we’ve had announcements for two more Rust-based build tools (which also appear to have roots in China) in Farm and Mako. Obviously there is also Turbopack, the Rust-based successor to Webpack, and Rolldown, the Rust-based version of Rollup.

It will be interesting to see which of these tools gets traction. Personally I think Rspack has a good chance of succeeding because:

Webpack is probably the most widely used build tool for apps today and Rspack provides the simplest and lowest risk migration path from Webpack. It’s easy to overlook this point but hopefully this post demonstrates how even for a modestly complex app like mine, migrating to a different build tool, even one that is largely compatible, can be quite involved.
Webpack has a rich plugin ecosystem, most of which work in Rspack. Many of the services I use like Relative CI and Bugsnag provide a Webpack plugin but don’t support any other build tools. Other build tools will be at an initial disadvantage unless they offer compatibility with Webpack’s plugin API.
Rspack is fast enough. Other tools might end up being fractionally faster (curiously both Mako and Farm claim to be marginally faster than Rsbuild but don’t show how they compare with Rspack) but if your build is already only 2~3 seconds, even an order of magnitude faster is not going to be a compelling enough reason to switch.

As Rspack approaches 1.0 I’m looking forward to seeing how it’s received and where the team takes it from here.

Weird things engineers believe about Web development

Sat, 06 Jan 2024 00:00:00 GMT

I wrote most of this post sometime in 2022 but I think it holds up alright in 2024 so I decided to publish it for posterity. I don’t really like doing posts like this—I’d much rather share some innocuous learnings or tips but it turns out I have opinions too 😓 Sorry!

2024-02-21: I’ve added a few reflections at the end of the post.

2024-04-27: Developpez.com has produced a French translation of this post.

Since I quit Mozilla and went back to full-time Web development, I’ve discovered a few surprises. It turns out Web development is actually pretty hard, Web developers are actually very smart, and some of these frameworks and techniques we mocked as browser engineers aren’t so bad. Oops.

At the same time, it turns out some Web developers have ideas about browsers and the Web that, as a former browser engineer and standards editor, I’m a bit dubious of.

Here are a few of the things that surprised me.

“Web browser engineers know Web development really well”

It’s easy to imagine that Web browser engineers, who write the code that makes up the Web platform, must know the Web inside-out like no-one else.

The trouble is, writing Web browsers is hard.

Most browser engineers focus on a particular area and know it really well with only a superficial understanding of other areas. Furthermore, browser platform engineers are writing C++ and Rust code all day long with a smattering of very simple JavaScript test cases. On top of that, they contribute to one massive respository where someone else takes care of all the tooling.

As a result, in their day jobs browser engineers are not fighting webpack, not trying to understand full-page TypeScript errors (they’ve got C++ template errors to fill that hole in their lives), not trying to get Safari on iOS to behave like other browsers, not struggling with CSS at scale, not trying to evaluate if the latest SSR/SSG/island framework is worth investing in, not refactoring massive JS codebases for more optimal chunking, not filing exasperated issues on GitHub because the latest version of one of their dependencies broke their app, not trying to get all their tools to agree on ESM vs CJS, and not losing sleep over whether or not they chose the right state management approach or if they should rewrite the entire thing for the tenth time over.

In short, they’re not doing Web development day in and day out so they know much less about real-world Web development than Web developers probably expect.

Now the engineers working on browser developer tools and the browser front-end often are using JS day-to-day and certainly have more awareness of the issues, but it’s still a few degrees removed from regular Web development. For example, they only need to target a single browser engine’s platform features, and often only a single browser version (being able to use the new and shiny features without worrying about compatibility is amazing), don’t need to worry about bundle size, or servers, or being offline, or so many other issues that make Web development hard.

Obviously some browser engineers have hobby projects, but the constraints on a hobby project are a world apart from being in a startup where you live or die by the success of your Web app.

I started my career in graphic design and Web development and even after I started contributing to Firefox I worked at a Web development company in Osaka for a time and produced some Web apps at Mozilla Japan too. However, after I quit Mozilla and got back into Web development full-time I was shocked at how much it had changed and how little I knew about it.

My experience as a browser engineer has been incredibly useful in Web development not least because I know where to look, who to ask, and where to file bugs, but I’d be kidding myself if I said that being a browser engineer automatically qualified me as a Web developer.

During my time at Mozilla, the Firefox OS days were by far the most enjoyable. We had internal teams building real-world mobile Web apps that we, as the platform team, had to debug and make successful as our highest priority. I saw how transitionend events could be unreliable and cause Web apps to be buggy and overly complicated and so I proposed and implemented the transitioncancel event and Web Animations’ Animation.finished promise.

But even working side-by-side with Web developers could not prepare me for actually being a full-time Web developer again. For the most part browser engineers just operate in a different world from Web developers and might not be the Web developer superheroes we imagine them to be.

”The people who make Web specifications know Web development really well”

Ok, but surely the people working on Web standards and specifications (who, it turns out, are mostly browser engineers) must be well-versed in Web development, right?

Back in 2012, Brendan Eich pointed out that, “Standards-making like law-making is definitely sausage-making” referring to the following quote from John Godfrey Saxe:

Laws, like sausages, cease to inspire respect in proportion as we know how they are made.

As a Web developer, it’s easy to imagine a group of people, infinitely wise about all things related to Web technology, making calm, rational decisions based on the technical merits of each proposal balanced against a thorough understanding of industry needs.

That illusion typically won’t last your first working group meeting. Despite the best of intentions, sometimes decisions get made based, at least in part, on one person’s charisma or forceful personality, on who happens to be in the room at the time, on how tired everyone is, or, dare I suggest, maybe even someone’s need to ship a feature in order to fill out their promotion packet.

That sounds very cynical so let me make two clarifications.

Firstly, the folks on these groups are well-meaning, wonderful people. Furthermore, they are often aware of their limitations and try their best to elicit Web developer feedback. Unfortunately, I’ve yet to see a group do this very successfully. There are Twitter/X polls, for example, but they tend to only be answered by the Web developers on the bleeding edge and are easily skewed by who spreads the word about the poll.

Secondly, I haven’t had much experience with WHATWG specs like HTML and DOM where decisions appear to be made asynchronously (“any decisions made during in-person meetings are to be considered non-binding”—WHATWG meetings), but my impression is that they seem to make better decisions. Folks like Anne van Kesteren, Simon Pieters, and Domenic Denicola probably know the Web better than anyone else on the planet. But even that is not the same as knowing Web development.

”Web developers know Web development really well”

As a browser engineer it’s really satisfying to ship a new platform feature. There are articles about it on Smashing Magazine and CSS tricks and Twitter/X goes abuzz with the news. It’s easy to think that now the whole world now knows about this great new advance in the Web’s capabilities.

At one point a few years ago, a few of us in Mozilla’s Japan team decided to interview local Web developers in Tokyo to learn what developer tools they would benefit from.

The results were surprising.

Many didn’t know about new CSS features that had shipped 10 years ago. What’s more, even when we told them about them, they didn’t seem too excited. They were doing just fine with jQuery and WordPress, thank you.

Instead, they were having trouble with things like, “When I show clients a site in responsive design mode, if the window doesn’t have a mockup of an iPhone around it, clients can’t grasp that they are looking at a preview of how the site will look on a smartphone. I really need that iPhone mockup.”

As a browser engineer involved in developing new Web standards I was a little disappointed but my lasting impression was of the constraints on these folks who are making their living from shipping Web sites and Web apps.

Unlike people working on browsers or well-funded Silicon Valley startups, many of these people are working for little shops with considerable pressure to deliver something quickly and then move onto the next project in order to pay the bills. They don’t have the luxury of spending a morning tinkering with upcoming technologies and instead reach for tried and trusted solutions they have experience with.

”Browsers aren’t made to run SPAs”

Another surprise from moving from browser development back to Web development was some of the assertions about how browsers work.

When I worked on animations, I was surprised at how many people believed that some animations “run on the GPU” (the browser can offload some animations to a separate process or thread that updates animations using the GPU to composite or even paint each frame but it doesn’t offload them to the GPU wholesale) but that was a fairly minor misunderstanding compared to some of the other ones that get thrown around like, “browsers aren’t made to run SPAs (single page applications)“.

I believe the argument here is that originally browsers would load content off the network, progressively laying it out and rendering it and have been heavily optimized for this. Dynamic content came later and so has been less heavily optimized.

Having worked on a browser on and off for nearly two decades I’m not convinced this is the case, or at least not anymore.

After all, the Firefox front-end and developer tools are, in effect, SPAs. The developer tools in particular are written using React and Redux and are in every sense an SPA.

To the argument that browsers are deficient at handling complex and long-lived DOM trees with dynamic changes made via JavaScript, the browser itself stands in contradiction to that claim.

An argument could be made that on mobile browsers aren’t optimized to run SPAs. After all, on Android, Firefox switched from an HTML rendered browser chrome to a native browser chrome in order to improve performance. I’m not in a position to comment on what the particular performance constraints were that lead to that change, but a blog from that time suggests it was related to improving app startup time and panning and scrolling performance, neither of which point to browsers being deficient at handling SPAs compared to other architectures.

“Ok, so maybe browsers can handle complex long-lived DOM trees with frequent dynamic changes, but SPAs tend to have large JS bundles that are slow to download and parse, blocking the initial render.” That’s a fair argument, but it’s an argument for smaller render-blocking initial bundles, which applies to equally to your average WordPress site, not an argument that browsers are somehow unsuited to running SPAs.

”MPAs will replace SPAs”

While we’re talking about SPAs and “the one true way to write Web apps”, a more recent variation on the “browsers can’t handle SPAs” take is, “MPAs (multi-page applications) will replace SPAs”.

I’m pretty excited about MPAs. More specifically, as someone who is involved with a lot of animation specs, I’m excited by the view transitions spec spec. It’s something we wanted to do at Mozilla for a while, particularly during the Firefox OS days, and made a proposal to that end. Kudos to Jake and others for finally making it happen.

View transitions were originally implemented for SPAs but have been adapted to work for MPAs and to the extent that they make multi-page sites more enjoyable they are a very welcome addition.

However, building on the “SPAs are bad” thinking, there seems to be a tendency to assume that MPAs are the future and SPAs are on the way out.

Unlike the earlier points in this post, my surprise at this take is not based on my experience with working on browsers, but on my more recent experience with working on Web apps.

First though, what do we even mean by MPAs?

My understanding is that whereas SPAs are characterized by having a long-lived DOM tree or two that are frequently updated by script, MPAs primarily update content by navigating to different HTML resources served from the network. These don’t have to be topmost navigations—it could be by navigating an <iframe>, for example. Similarly, SPAs might use <iframe>s as a means of chunking but there’s a difference in how content is typically updated.

By this definition, Google Docs is an SPA since although each document is served as a separate resource, most of the time you’re interacting with the one document that is continually updated via JavaScript. YouTube would probably be considered an MPA but it might actually be implemented as an SPA in order to smooth out changes in content, intercepting navigations and replacing the content via script—that is, until view transitions can help with that.

In either case, my surprise at the idea that MPAs will replace all SPAs is simple: How would Figma or Photoshop for Web work as an MPA? Or Slack, or Discord, or Google Maps?

I’m currently working on an offline-first mobile Web app that stores data locally and syncs to the server. Wanting to be on the forefront of Web tech I investigated how we could embrace MPAs.

To keep a long story short, if we’re to retain our desired UX which has independently navigable panels and our offline-first requirement, we could introduce some <iframe>s to partition out some of the functionality into separate HTML requests (as opposed to separate script chunk requests) and we could probably even pre-render some chunks sometimes. The trouble is it would increase the complexity ten-fold (two-way sync becomes three-way sync for a start) while providing no benefit to customers whatsoever—instead it would almost certainly lead to more bugs, more latency, and shipping features more slowly.

Given that our app is not currently released I realise that’s a fairly weak argument since no-one can look at the app and suggest a better approach so I’m just asking you to trust me on this one. I tried. I really did. It’s just not the right architecture for this particular app and I’m surprised by the suggestion that everything should be an MPA.

”All sites should work without JavaScript”

Continuing on our theme of Web development best practices, building a site that works without JavaScript is an admirable goal. Doing so probably means it degrades gracefully, has no JS blocking the initial render, and works on a wide range of browsers. But I’ve been surprised to see how often this becomes dogmatic: “all sites should work without JavaScript”.

I guess it’s easy to come to this conclusion if your site is able to work without JavaScript (see “My blog is representative of Web development at large”) but it feels a little myopic to me.

I’ve mentioned Figma and Photoshop for Web before; it’s hard to imagine how they could work without JavaScript. Likewise for a browser’s developer tools. Or even Parapara Animation!

Furthermore, although many advocates against JS are also concerned about accessibility, JavaScript is often necessary in order to make an app accessible.

One thing the accessibility folks at Mozilla taught me about keyboard navigation was that Tab navigation should be fairly coarse. That is, you use Tab to navigate to the control group (e.g. toolbar) and then use the arrow keys to move within that group. That allows you to move around an app more quickly without having to Tab through every single control first. WAI calls this a “roving tabindex”.

However, in order to implement this kind of coarse-grained keyboard navigation you’re going to need JavaScript. If you want to make the arrow-key based navigation two-dimensional, you’re going to need even more JavaScript. Maybe one day we’ll fill that gap in the platform (looking at you, focusgroup) but for now you should feel no shame about using client-side JavaScript to make your app accessible.

Honestly, I think some sites should use more JavaScript.

As an example, the Eleventy documentation seems to avoid using client-side JavaScript for the most part. As Eleventy supports various templating languages it provides code samples in each of the different languages. Unfortunately, it doesn’t record which language you’ve selected so if your chosen language is not the default one, you are forced to change tabs on every single code sample. A little client-side JavaScript here would make the experience so much more pleasant for users.

Update (2024-01-11): It seem that Eleventy have taken this feedback onboard and fixed this. Thank you! 🙏

“Web development shouldn’t need a build step”

While just about everything in this post is from 2022, while tidying it up I couldn’t resist adding just one more recent idea that surprised me.

Our final stop on the Web development dogma train is a view that’s come up a few times but still surprises me. The most recent rendition I saw went something like, “we’re so blind and stubborn that we’ve ended up with a hugely complex toolchain but we really should be able to ship Web apps without a build step at all”.

As someone who spent most of his career working with compiled languages the desire to go without a build step is surprising. The things compiler engineers do amaze me. They are geniuses who layer clever optimization on top of clever optimization transforming my very average code into something unrecognizable and insanely fast. If anything, I want more of that compiler magic in my Web development.

Obviously JavaScript presents its own challenges since it can be very hard to statically determine the side effects of a certain operation but I’m sure there’s still more room to explore in optimizing JavaScript at compile time.

Web developers seem to agree on optimizing image assets and pre-generating static HTML pages where it makes sense, why is there resistance to optimizing code assets too? Why defer computation and I/O to runtime that can be done once at build time? If nothing else, I have no desire to ship my megabyte-long comments cursing iOS Safari to every user on every request.

Maybe 2024 will be the year where client-side Rust/WASM frontend frameworks start to get traction and if that’s the case, we’d better get used to having a build step!

”My blog is representative of Web development at large”

A number of the points above could possibly be summarised as “My blog is representative of Web development at large”. That is, coming from browser engineer to Web developer, most of the notions about Web development that have surprised me are the result of people extrapolating their experience of the Web in a way that doesn’t overlap with mine.

Since I left Mozilla over four years ago, I’ve spent most of my time working on a Web app. I’ve also spent way too long setting up this blog. Surprisingly, with regards to tooling, architecture, or Web platform features used, I’ve found almost no overlap between the two. It’s almost as if blogs and apps exist in entirely disparate corners of the Web development landscape.

My app is a mass of TypeScript code, my blog uses almost no client-side JavaScript. My app is hugely complicated by two-directional data sync, my blog is read-only. My app uses webpack, Playwright E2E tests, a component framework, and a state management library, my blog uses none of those.

If you’re mostly engaged with one or the other, it’s easy to think that’s what Web development looks like. In truth, Web development is probably more diverse than any of us imagines.

Conclusion

There are other notions I’ve found surprising but the common theme in the above is it’s easy to assume our experience of the Web is representative of Web development in general.

Moving from browser development back to Web development has been humbling because it’s so much broader and deeper than I knew. I have a much greater respect for Web developers, especially those at little Web shops and startups that live or die by the success of their Web apps.

If that’s you, I hope reading this post gives you confidence that even if browser engineers, standards editors, and other Web developers insist on a particular way of doing things, you know your constraints better than anyone else and you’re probably doing things just fine.

Reflections a couple of months later

Since posting this article I’ve received some very useful feedback which I’ll summarise below:

Some people pointed out that the background behind a lot of anti-JavaScript and anti-SPA sentiment is a reaction to seeing static sites being rendered as React SPAs which is a very poor fit. That was helpful context that I hadn’t appreciated.
Others clarified that the “no build step” argument is more about local development and not about production assets. That makes a lot of sense and is something I can appreciate.

My point wasn’t to say you should have a build step but simply to say that coming from browser development I was surprised at the anti-build-step sentiment because I’m used to compilers and I’d be interested in seeing what more they can do for us.
Some people took issue with some of the later points because I failed to clearly summarise my main contention. Here it is:

I worked on browsers for over a decade and am still involved in Web standards and browser development. I love the platform and encourage others to make full use of it.

My contention is with the absolute terms with which Web development best practices are sometimes asserted. Web development social media can be a fierce place—something I was sheltered from when working on browsers.

I’m certainly not trying to establish a new dogma but just to push back and say that using JavaScript, writing an SPA, and having a build step is sometimes the right choice and you shouldn’t feel bad about it.

Sharding Playwright tests by browser

Sun, 17 Dec 2023 00:00:00 GMT

2024-01-22: I’ve updated this to work with Playwright 1.41.

Last week started like every other week, meaning half a dozen projects were broken by half a dozen incompatible dependency updates. There were the usual suspects like Lexical but most noticeable was Playwright.

Playwright had been more-or-less behaving up until 1.39, but something in 1.40 was causing the WebKit tests to intermittently fail, a lot.

Nothing in the commit log stood out except a few opaque feat(webkit): roll to r1926-type commits and there didn’t seem to be a pattern to the failures other than having to do with text input and focus—which is basically all our tests. So I decided to do the grown-up thing and collect some data.

Trying to be lazy

I asked ChatGPT for the simplest possible way to analyze the test data which politely suggested I use Lambda to ingest data to DynamoDB or RDS coupled with QuickSight, Angular and Flask and possibly Athena, ELK stack, DataDog and Grafana.

And this point I’m pretty sure ChatGPT was trolling me so instead I was forced to use my own two fingers to query a search engine the old-fashioned way. Fortunately that turned up the amazing Currents which was everything I was looking for and more.

I spent a couple of hours setting it up “just right” and was thoroughly impressed to see it live stream the test results. Very nice work.

The trouble came when I stepped into the office the next morning and got a mail saying that while I was sleeping I’d hit the limit of the free tier. I was about to to pull out my wallet until I calculated that for this little project with its pitiful E2E test suite of only about 280 tests running on three browser engines, it would cost about $500 per month to send all the test results to Currents, or about 50 times as much as it costs to actually run the tests 😬

I suppose I could have tried to negotiate but I don’t think this AI was about to give me a 98% price reduction.

Looping screen capture of the Currents customer support chatbot. It features a 3D rendered head flicking backwards and forwards unnervingly and there's something odd like a metal plate attached to her head.

I backed out all my Currents setup but not all was lost. In the process of setting it up, I’d been introduced to the magic of Playwright test sharding.

Normally sharding splits your test runs up into roughly-equally sized buckets that can be run in parallel but I wondered if you could split them up by browser instead. It turns out you can and it has a lot of advantages, but there are a few tricks needed to get it to work.

Sharding by browser

Firstly, in our GitHub Actions workflow we set up a matrix based on the different browsers we’re targeting:

e2e:
  runs-on: ubuntu-latest
  name: E2E tests
  timeout-minutes: 20
  strategy:
    fail-fast: false
    matrix:
      browser: [chromium, firefox, webkit]
      include:
        - maxFailures: 10
        - maxFailures: 40
          browser: webkit

This setup allows us to tweak the parameters used for each browser such as the number of allowed failures or the number of workers, for example.

Then we need to install Playwright but we can be a bit clever and only install the dependencies needed for the browser we are running which will speed up CI time even further.

steps:
  - uses: actions/checkout@v4

  - uses: actions/setup-node@v4
    with:
      cache: yarn
      node-version: 18

  - name: Install
    run: yarn install

  # Playwright cache:
  #
  # Based on https://github.com/microsoft/playwright/issues/7249#issuecomment-1154603556
  #
  # Figures out the version of Playwright that's installed.
  #
  # The result is stored in steps.playwright-version.outputs.version
  - name: Get installed Playwright version
    id: playwright-version
    run: echo "version=$(cat yarn.lock | grep "^\"@playwright\/test" --after-context 1 | tail -n 1 | sed 's/\s*version "\([0-9.]\+\)"/\1/')" >> $GITHUB_OUTPUT

  # Attempt to restore the correct Playwright browser binaries based on the
  # currently installed version of Playwright (the browser binary versions
  # may change with Playwright versions).
  #
  # Note: Playwright's cache directory is hard coded because that's what it
  # says to do in the docs. There doesn't appear to be a command that prints
  # it out for us.
  - uses: actions/cache@v3
    id: playwright-cache
    with:
      path: '~/.cache/ms-playwright'
      key: '${{ runner.os }}-playwright-${{ matrix.browser }}-${{ steps.playwright-version.outputs.version }}'
      # As a fallback, if the Playwright version has changed, try use the
      # most recently cached version for this browser. There's a good
      # chance that the browser binary version hasn't been updated, so
      # Playwright can skip installing that in the next step.
      #
      # Note: When falling back to an old cache, `cache-hit` (used below)
      # will be `false`. This allows us to restore the potentially out of
      # date cache, but still let Playwright decide if it needs to download
      # new binaries or not.
      restore-keys: |
        ${{ runner.os }}-playwright-${{ matrix.browser }}-

  - name: Install Playwright with dependencies
    if: steps.playwright-cache.outputs.cache-hit != 'true'
    run: npx playwright install --with-deps ${{ matrix.browser }}

  - name: Install Playwright's dependencies
    if: steps.playwright-cache.outputs.cache-hit == 'true'
    run: npx playwright install-deps ${{ matrix.browser }}

Finally we run the tests.

- name: Run E2E tests
  run: yarn playwright test --project=${{ matrix.browser }} --max-failures ${{ matrix.maxFailures }} --workers 2

With all that, our browsers run as separate tasks which means:

CI run setup time is reduced since we only install the required dependencies for one browser.
You can adjust the run parameters separately by browser.
You can potentially run different browsers on different hardware.
You can tell at a glance who you’re waiting on.

Here’s how it looks:

Merging reports

One of the problems with sharding is that all your test results are sharded too. Playwright, however, very conveniently provides a utility for re-uniting them.

The first step is to configure your tests to use the blob reporter. So in playwright.config.ts you might set your reporter to something like:

reporter: process.env.CI ? [['github'], ['blob']] : 'list',

However, if we do that all the reports would have the same name and they’d clobber each other when we tried to merge them. When you shard using the regular --shard 1/3 approach Playwright adjusts the name of the reports for you, but when you shard by browser you’re on your own.

Prior to Playwright 1.41 this was as simple as setting the PWTEST_BLOB_REPORT_NAME environment variable but 1.40 added a fileName option to the blob reporter which is a little more cumbersome to use.

First we need to stick our browser name in an environment variable. For example:

 - name: Run E2E tests
   run: yarn playwright test --project=${{ matrix.browser }} --max-failures ${{ matrix.maxFailures }} --workers 2
+  env:
+    PWTEST_BOT_NAME: ${{ matrix.browser }}

Then, when we set up the reporter, we can pass that into the fileName:

reporter: process.env.CI
  ? [
      ['github'],
      [
        'blob',
        {
          fileName: process.env.PWTEST_BOT_NAME
            ? `report-${process.env.PWTEST_BOT_NAME}.zip`
            : undefined,
        },
      ],
    ]
  : 'list',

Finally, once all shards are done, we upload the artifacts and merge them together:

      - name: Upload any failure artifacts
        uses: actions/upload-artifact@v4
        if: always()
        with:
          # upload-artifact@v4 no longer permits overlapping artifact names so
          # we need to make the name unique
          name: blob-report-${{ matrix.browser }}
          path: blob-report
          retention-days: 1

  upload-reports:
    if: always()
    name: Upload Playwright reports
    needs: [e2e]
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          cache: yarn
          node-version: 18

      - name: Install
        run: yarn install

      - name: Download blob reports from GitHub Actions Artifacts
        uses: actions/download-artifact@v3
        with:
          path: all-blob-reports

      # download-artifact@v4 will download each artifact to a separate directory
      # based on the artifact name but merge-reports won't look into
      # subdirectories so we need to flatten the hierarchy.
      - name: Move reports into the same folder
        run: mv all-blob-reports/blob-report-*/*.zip all-blob-reports/

      - name: Merge into HTML Report
        run: npx playwright merge-reports --reporter html ./all-blob-reports

      - name: Upload HTML report
        uses: actions/upload-artifact@v4
        with:
          name: html-report-${{ github.run_attempt }}
          path: playwright-report
          retention-days: 14

The final report looks something like this:

I suspect the reason it shows “webkit” and “chromium” twice next to each test run is because it tags the results both by shard name and the engine (“project” in Playwright terms) which happen to be the same in our case.

Back to debugging WebKit

I still haven’t worked out what’s going on with WebKit. I’ve disabled half the tests from running on WebKit and it still takes four times as long and fails ten times as often as Chrome and Firefox but working that out is a subject for another blog or two.

In praise of WordPress

Tue, 28 Nov 2023 00:00:00 GMT

After over a year of fighting with Eleventy and then Astro to set up a this blog just right I find myself needing to set up yet another blog, this time for work. I could just build on what I’ve got with Astro but I can’t help but wonder if I would have been better off sticking with WordPress after all.

When I first got into Web development in the 90s I used to write little Visual Basic programs to generate the HTML pages for the site. It turns out spitting out HTML pages is easy enough that even before the existence of GitHub and Node and every other part of a modern Web dev toolchain, a high school kid could knock up a program to do it in their spare time.

So you’d think that with all the advances in Web tech in the last ~30 years, generating a static site would be amazing by now. However, my lasting impression after struggling with Eleventy and Astro is just how underwhelming it is.

Even now, after months and months of tweaking and testing, my site still doesn’t have a newsletter feature, the comments take about 10 minutes to show up, and I just spent half a day trying to fix my one and only Netlify edge function because I updated its dependencies and now it can’t figure out how to dynamically load a WASM file forcing me to migrate the whole thing to AWS instead.

All this has made me appreciate just how great WordPress—where I used to host this blog—was.

With WordPress you get:

A WSYIWYG blog post editor
Index pages by tag, day, month, year, etc. with pagination (i.e. double-pagination, something which is particularly hard in Eleventy)
Threaded comments with spam filtering and moderation features
A login system so users can receive notification about replies via email
Social images and metadata
Draft blogs and instant previews
An automatic newsletter system
A search feature
RSS feeds (by comparison, just look at how much trouble setting up RSS in Astro is)
Media management, plugins, themes, commerce features and so on.

WordPress has a reputation for being bloated—and WordPress sites certainly can be—but if I’d spent half has much time optimizing a WordPress site as I spent making this site, I’ll bet I could have made it fast enough that most people would never notice.

And I’ll bet WordPress experience is at least an order of magnitude more marketable than Astro experience if I ever decide to go into consulting!

RSS the hard way: Adventures with Astro Assets

Mon, 02 Oct 2023 00:00:00 GMT

2023-12-14: I’ve heavily updated this to work with Astro 4.0 but for posterity I’ve saved the old version in the Internet Archive.

There’s something depressing about a blog about blogging. I never wanted this to be one of those blogs. But I’ve struggled so much with Astro’s image feature these past few weeks that I really hope it will benefit others and amount to a bit more than one over-engineered RSS feed.

First step, “fixing” lazy loading

Before we get into RSS, I want to introduce Astro’s image feature by looking at a simpler problem: lazy loading.

Astro very helpfully lets you reference images from a Markdown file using a relative path. In other words, you can have a Markdown file src/content/posts/blog-a-log/index.md and write:

Look at this picture:
![Amazing picture](./picture.jpg)

Astro will find the picture at src/content/posts/blog-a-log/picture.jpg, copy it to your dist/assets folder, generate a WebP version, then create an <img> tag in your generated HTML complete with width and height attributes for reducing CLS badness. That way your images can live happily alongside their corresponding Markdown files.

Awesome.

But Astro also takes the liberty of slapping loading="lazy" on every single <img> tag.

That’s not awesome because:

If the image is “above the fold” it will hurt your LCP score.
It can be distracting to read blogs with loading="lazy" since you can see the images load as you scroll through the page.
It’s annoying when you enter a tunnel on the train and can no longer see the images in the rest of the article.

How can you fix it? According to the Astro issue tracker, you can’t fix it from Markdown. Instead you have to make your own image service.

That sounds really hard but it turns out to be quite simple.

For example, if you’re already using the sharp image service you can wrap it like so:

import sharpImageService from 'astro/assets/services/sharp';

export const nonLazySharpServiceConfig = () => ({
  entrypoint: 'src/utils/non-lazy-sharp-service',
  config: {},
});

/**
 * A fork of the sharp image service that drops the loading="lazy"
 * attribute from outputted image tags since it can hurt LCP scores (and is
 * generally annoying when scrolling the page).
 */
const nonLazySharpService = {
  validateOptions: sharpImageService.validateOptions,
  getURL: sharpImageService.getURL,
  parseURL: sharpImageService.parseURL,
  getHTMLAttributes: (options, serviceOptions) => {
    const result = sharpImageService.getHTMLAttributes(options, serviceOptions);
    delete result.loading;
    return result;
  },
  transform: sharpImageService.transform,
};

export default nonLazySharpService;

Drop that in, e.g. src/utils/non-lazy-sharp-service.js, and include it in astro.config.js in place of sharpImageService() and you’re done. Eager loading all around.

If you get errors like the following:

No loader is configured for ".node" files: node_modules/sharp/build/Release/sharp-linux-x64.node

you’ll also need to exclude the sharp binary from the bundle by adding something like the following to your vite config:

  optimizeDeps: { exclude: ['sharp'] },

The hard bit: RSS

Now onto the hard problem. I had set up a pretty solid RSS feed using Astro’s RSS feature because, if you’re setting up a blog, apparently you should have an RSS feed.

I’ve never used an RSS feed reader but I like the idea. I decided to double-check my awesome RSS feed with Feedly only to be devastated by the lack of pretty pictures.

Check out that follower count too.

Inspecting the source of the RSS feed itself it turns out all the images were still using the relative path from the source file, i.e. ./picture.jpg from above. So “all we need to do” is adjust those paths to the final resolved paths. How card could it possibly be? (Spoiler: very very hard)

It turns out images in Astro go on quite the journey from being announced in Markdown to finally appearing in HTML ready for showtime.

From Markdown to optimized HTML

Astro is built on vite. Before encountering this problem I’d been trying my hardest to not know what vite is so, if you’re like me, all you really need to know is vite is like webpack but built on rollup, which is also like webpack.

That last point is important because as you’re cruising the Astro source code you’ll see things like this.resolve() and will surely wonder where on earth they’re defined. It turns this.resolve() and a whole lot of other functions attached to this are part of the Rollup plugin API.

With that background out of the way, the journey from Markdown image to optimized HTML image goes something like this:

Astro registers a vite plugin called vite-plugin-markdown which handles any Markdown files it encounters.
vite-plugin-markdown parses the Markdown using @astrojs/markdown-remark which basically wraps up the remark library and configures a bunch of plugins.
The remarkCollectImages plugin extracts all the relative image paths that should be optimized and stores them in the Markdown virtual file metadata.
After converting the Markdown to HTML another plugin, rehypeImages, looks for any <img> elements whose src matches one of the paths we found in the previous step. For any matching <img>s it drops the src attribute and adds an __ASTRO_IMAGE__ one in its place with the same value.
Back in vite-plugin-markdown we read back all the image paths from the third step and resolve them using Rollup’s resolve API turning ./picture.jpg into /home/me/blog/src/content/posts/blog-a-log/picture.jpg.
Finally, we export a big template string of TypeScript code in place of the Markdown file that:
- Includes a map of image paths from the relative image paths to their fully resolved paths.
- Takes the HTML we generated previously and runs a regex on it to replace all those __ASTRO_IMAGE__ attributes with the corresponding resolved path from the map of image paths.

That’s the overview, but we glossed over a lot of details with regard to the image path map in the second last bullet point.

The template string to generate the map looks like this:

return `
    import { getImage } from "astro:assets";
    ${imagePaths
      .map(
        (entry) =>
          `import Astro__${entry.safeName} from ${JSON.stringify(entry.raw)};`
      )
      .join('\n')}

    const images = async function() {
      return {
        ${imagePaths
          .map(
            (entry) =>
              `"${entry.raw}": await getImage({src: Astro__${entry.safeName}})`
          )
          .join(',\n')}
        }
      }
     //...
  `;

The mix of executed code and generated code here is a bit of a mind-bender but there are two important points.

Firstly, the import Astro__${entry.safeName} from ${JSON.stringify(entry.raw)}; part hides the fact that this is triggering yet another vite plugin. This time it’s the vite-plugin-assets plugin.

By importing an image using ESM we arrive at the astro:assets:esm section of that plugin which calls emitESMImage. emitESMImage emits the file using Rollup’s emitFile API and returns the image metadata like the width and height as well as a handle to the image in the form __ASTRO_ASSET_IMAGE__${handle}__.

In effect, this takes something like /home/me/blog/src/content/posts/blog-a-log/picture.jpg and returns a handle like _⁠_ASTRO_ASSET_IMAGE__6cf702f7__ where 6cf702f7 is the referenceId returned by emitFile.

Then, in the renderChunk hook of the same plugin, it finds the _⁠_ASTRO_ASSET_IMAGE__6cf702f7__ handle, extracts the referenceId 6cf702f7, looks it up using Rollup’s this.getFileName and gets back assets/picture.b5a66e4a.jpg.

Secondly, we pass the metadata returned from emitESMImage including the now-resolved src (i.e. assets/picture.b5a66e4a.jpg) along to getImage. getImage calls our image service which calls addStaticImage from vite-plugin-assets to ensure that our WebP image gets generated.

addStaticImage adds its own hash to the resulting file producing something like /assets/picture.b5a66e4a_13mnAp.webp which getImage forwards on.

Getting the resolved path in our RSS feed

So, how do we get from ./picture.jpg to /assets/picture.b5a66e4a_13mnAp.webp in our RSS feed?

Summarising the above, there are roughly four steps:

Get all the suitable relative images from the Markdown file (e.g. ./picture.jpg).
Resolve the absolute path on disk for each (e.g. /home/me/blog/src/content/posts/blog-a-log/picture.jpg).
Emit the file as part of our Rollup build producing, e.g., assets/picture.b5a66e4a.jpg.
Get the path of the optimized version of the file (e.g. assets/picture.b5a66e4a_13mnAp.webp).

Pretty straightforward except step 3. Step 3 is trouble.

Step 1: Collecting the relative images

In order to include an HTML version of our posts in the RSS feed we need to do our own Markdown processing.

The Astro docs suggest using markdown-it or similar for this. I decided to use remark so that I can re-use plugins between parsing Markdown for regular display and for generating HTML previews.

Doing that means we can re-use Astro’s remark plugin for extracting relative images like so:

import { remarkCollectImages } from '@astrojs/markdown-remark';
// ...

// Using a singleton parser improves performance _dramatically_
const postParser = unified()
  .use(remarkParse)
  .use(remarkCollectImages)
  .use(remarkRehype)
  .use(rehypeSanitize)
  .use(rehypeStringify);

// When generating each RSSItem we do:
const content = await postParser.process({ path, value: post.body });

Note that although Remark will accept the markdown content (post.body above) by itself, we also need to pass the path of the Markdown file too or else remarkCollectImages will skip it.

Step 2: Resolving the absolute path on disk

Astro resolves relative paths with the following code:

(await this.resolve(imagePath, id))?.id ??
  path.join(path.dirname(id), imagePath);

The first part uses Rollup’s this.resolve which ends up running any plugins registered for the resolveId hook.

In Astro’s case, that includes the configAliasVitePlugin plugin which picks up your tsconfig.json and applies any aliases from the paths section but fortunately Astro 3 dropped the alias it added there so we can ignore that plugin.

Instead, we can just add another plugin that operates on the HTML—a rehype plugin—that picks up the extracted image references and locates them on disk like so:

export function rehypeAstroImages(options) {
  return async function (tree, file) {
    if (
      !file.path ||
      !(file.data.imagePaths instanceof Set) ||
      !file.data.imagePaths?.size
    ) {
      return;
    }

    const imageNodes = [];
    const imagesToResolve = new Map();
    visit(tree, (node) => {
      if (
        node.type !== 'element' ||
        node.tagName !== 'img' ||
        typeof node.properties?.src !== 'string' ||
        !node.properties?.src ||
        !file.data.imagePaths.has(node.properties.src)
      ) {
        return;
      }

      if (imagesToResolve.has(node.properties.src)) {
        imageNodes.push(node);
        return;
      }

      const absolutePath = path.resolve(
        path.dirname(file.path),
        node.properties.src
      );

      if (!fs.existsSync(absolutePath)) {
        return;
      }

      imageNodes.push(node);
      imagesToResolve.set(node.properties.src, absolutePath);
    });

    // ... to be continued
  };
}

Step 3: Getting the path to the asset produced by Rollup

This is where it gets hard. It seems like we could just call this.emitFile, grab the referenceId then look it up with this.getFileName. But that requires having a Rollup plugin context to work with.

Many parts of the Astro codebase do this sort of thing. emitESMImage itself takes this.emitFile as an argument. Many other places take a plugin context as an argument. But where do we get a plugin context from in the middle of generating our RSS?

This is where I get stuck and I hope someone reading this blog can tell me an easy way to do this. I fear the right way might involve creating yet another vite plugin and exporting TypeScript template strings and other messy business so for now I’ve implemented the hacky way: shadow what Rollup does very poorly and hope it’s enough.

Specifically, we want to shadow how Rollup goes from <absolute path>/picture.jpg to assets/picture.<hash>.jpg.

First the hash. Rollup has a function getXxhash which calls into xxhashBase64Url that boils down to the following Rust code:

use base64::{engine::general_purpose, Engine as _};
use xxhash_rust::xxh3::xxh3_128;

pub fn xxhash_base64_url(input: &[u8]) -> String {
  let hash = xxh3_128(input).to_le_bytes();
  general_purpose::URL_SAFE_NO_PAD.encode(hash)
}

It’s using the XXH3_128 variant of the xxHash algorithm and encoding into base64. Unfortunately none of the Node implementations of xxHash I could find support the 128-bit variant but fortunately Rollup publishes a WASM version of its binaries under @rollup/wasm-node. As a result we can install @rollup/wasm-node and import the hashing function as follows:

import { xxhashBase64Url } from '@rollup/wasm-node/dist/wasm-node/bindings_wasm.js';

That will generate a rather long hash but Rollup only uses a part of it in the filename. In fact, the filename generation is quite involved…

function generateAssetFileName(
  name: string | undefined,
  source: string | Uint8Array,
  sourceHash: string,
  outputOptions: NormalizedOutputOptions,
  bundle: OutputBundleWithPlaceholders
): string {
  const emittedName = outputOptions.sanitizeFileName(name || 'asset');
  return makeUnique(
    renderNamePattern(
      typeof outputOptions.assetFileNames === 'function'
        ? outputOptions.assetFileNames({ name, source, type: 'asset' })
        : outputOptions.assetFileNames,
      'output.assetFileNames',
      {
        ext: () => extname(emittedName).slice(1),
        extname: () => extname(emittedName),
        hash: (size) =>
          sourceHash.slice(0, Math.max(0, size || defaultHashSize)),
        name: () =>
          emittedName.slice(
            0,
            Math.max(0, emittedName.length - extname(emittedName).length)
          ),
      }
    ),
    bundle
  );
}

Looking at the important bits here:

sanitizeFileName is only dealing with drive letters and things so hopefully we can ignore that 👍
makeUnique ensures the filename doesn’t clash but since we’re including a bit of hash in the filename hopefully we’re ok 🤞
renderNamePattern is problematic. It implements the asset format defined by output.assetFileNames which we’re likely to want to override 😬

In fact, my Astro config already does:

export default defineConfig({
  // ...
  vite: {
    build: {
      rollupOptions: {
        output: {
          assetFileNames: (assetInfo) => {
            if (assetInfo.name === 'style.css') {
              return 'css/styles.[hash][extname]';
            }
            return 'assets/[name].[hash][extname]';
          },
        },
      },
    },
  },
});

Now, unfortunately, as far as I can tell Astro doesn’t provide any easy way to access configuration values and as someone else discovered, simplying importing astro.config.js no longer works either.

You can access the config using an integration but if you try loading the same integration when generating RSS you’ll be disappointed to learn that it’s executing in a different context so you can’t share the config you gleaned from the integration API.

At this point, the simplest thing is just to move the vite config to a separate file, vite.config.js so it can be imported separately from both astro.config.js and our rehype plugin.

With our output.assetFileNames option finally available, we can proceed to fork Rollup’s generateAssetFileName into just the parts we need. We don’t need most of the validation code since presumably that’s going to be run when we generate the actual asset.

Putting it altogether we have something like this:

import * as fs from 'node:fs';
import * as path from 'node:path';
import { xxhashBase64Url } from '@rollup/wasm-node/dist/wasm-node/bindings_wasm.js';

/**
 * @param {string} absolutePath
 * @param {Buffer} data
 * @param {string=} assetsDir
 * @param {ViteConfig=} viteConfig
 */
function getImageAssetFileName(absolutePath, data, assetsDir, viteConfig) {
  const source = new Uint8Array(data);
  const sourceHash = getImageHash(source);

  if (Array.isArray(viteConfig?.build?.rollupOptions?.output)) {
    throw new Error("We don't know how to handle multiple output options 😬");
  }

  // Defaults to _astro
  //
  // https://docs.astro.build/en/reference/configuration-reference/#buildassets
  assetsDir = assetsDir || '_astro';

  // Defaults to `${settings.config.build.assets}/[name].[hash][extname]`
  //
  // https://github.com/withastro/astro/blob/astro%404.0.3/packages/astro/src/core/build/static-build.ts#L208C22-L208C78
  const assetFileNames =
    viteConfig?.build?.rollupOptions?.output?.assetFileNames ||
    `${assetsDir}/[name].[hash][extname]`;

  return generateAssetFileName(
    path.basename(absolutePath),
    source,
    sourceHash,
    assetFileNames
  );
}

function getImageHash(imageSource) {
  return xxhashBase64Url(imageSource).slice(0, 8);
}

function generateAssetFileName(name, source, sourceHash, assetFileNames) {
  const defaultHashSize = 8;

  return renderNamePattern(
    typeof assetFileNames === 'function'
      ? assetFileNames({ name, source, type: 'asset' })
      : assetFileNames,
    {
      ext: () => path.extname(name).slice(1),
      extname: () => path.extname(name),
      hash: (size) => sourceHash.slice(0, Math.max(0, size || defaultHashSize)),
      name: () =>
        name.slice(0, Math.max(0, name.length - path.extname(name).length)),
    }
  );
}

function renderNamePattern(pattern, replacements) {
  return pattern.replace(/\[(\w+)(:\d+)?]/g, (_match, type, size) =>
    replacements[type](size && Number.parseInt(size.slice(1)))
  );
}

Step 4: Getting the path to the optimized asset

Now that we have the asset name that Rollup is (hopefully) going to produce, getting the path to the optimized asset is easy since Astro helpfully provides the getImage function for this.

Continuing our rehype plugin, we can resolve the references as follows:

import { getImage } from 'astro:assets';
import { imageMetadata } from 'astro/assets/utils';

// ...

const imagePromises = [];
for (const [relativePath, absolutePath] of imagesToResolve.entries()) {
  imagePromises.push(
    fs.promises
      .readFile(absolutePath)
      .then(
        (buffer) =>
          /** @type Promise<[ImageMetadata, Buffer]> */
          new Promise((resolve) => {
            imageMetadata(buffer).then((meta) => {
              resolve([meta, buffer]);
            });
          })
      )
      .then(([meta, buffer]) => {
        if (!meta) {
          throw new Error(`Failed to get metadata for image ${relativePath}`);
        }

        const fileUrl = url.pathToFileURL(absolutePath);
        fileUrl.searchParams.append('origWidth', meta.width.toString());
        fileUrl.searchParams.append('origHeight', meta.height.toString());
        fileUrl.searchParams.append('origFormat', meta.format);
        const assetPath =
          '/@fs' +
          absolutize(url.fileURLToPath(fileUrl) + fileUrl.search).replace(
            /\\/g,
            '/'
          );

        return getImage({ src: { ...meta, src: assetPath } });
      })
      .then((image) => [
        relativePath,
        { src: image.src, attributes: image.attributes },
      ])
  );
}

// Process the result
const resolvedImages = new Map();
for (const result of await Promise.allSettled(imagePromises)) {
  if (result.status === 'fulfilled') {
    resolvedImages.set(...result.value);
  } else {
    console.warn('Failed to resolve image', result.reason);
  }
}

for (const node of imageNodes) {
  const imageDetails = resolvedImages.get(node.properties.src);
  if (imageDetails) {
    const { src: resolvedSrc, attributes } = imageDetails;
    if (options.rootUrl) {
      node.properties.src = new URL(resolvedSrc, options.rootUrl).toString();
    } else {
      node.properties.src = absolutize(resolvedSrc);
    }
    node.properties.width = attributes.width;
    node.properties.height = attributes.height;
  }
}

function absolutize(path) {
  return !path.startsWith('/') ? `/${path}` : path;
}

Epilogue: Ship it!

We did it! Having finally tamed Astro Assets I thought it was time I unleashed my abomination on the world as a brand new drop-in package. I spent half a day setting up the repo and npm package “just right”, popped into into my blog and fired up a build only to get…

Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme
in: file and data are supported by the default ESM loader.
Received protocol 'astro:'

It turns out all these fancy vite plugins and virtual modules in Astro aren’t applied to code under node_modules? I tried to brute force my way past the first error but next it was virtual:image-service that was not reachable.

I tried to persuade Rollup to do its thing for my module too but with no luck.

By this point I have to conclude that all this code is just not the Astro way to do things. The correct approach probably involves a bundle of vite plugins writing Typescript template string incantations but I’ve spent way too much on this problem by now so in lieu of an npm package I have a gist.

I look forward to someone reviewing my code and telling me all the places I did it wrong!

Unfortunately, it looks like Feedly only ever fetches a post once so it doesn’t matter that I fixed my old posts—Feedly users will see the original broken version for eternity 😅

Sponsoring Open Source as a Japanese Company

Sat, 09 Sep 2023 00:00:00 GMT

Six years since my last post, I thought I’d get back into blogging. I plan to write about Web apps and things but I’d also like to talk a bit about running a company in Japan since there’s not a lot of good information on that in English.

Today, I want to share some notes about sponsoring Open Source through GitHub as a Japanese company.

A few years ago I started using React cosmos for iterating on UI components. I was previously using Storybook but it required babel, a separate webpack file, and a lot of configuration and maintenance. React Cosmos just worked and does everything I need.

Since my company is benefitting from Ovidiu’s hard work, when I saw he was developing the next major version I figured it was only right to support him.

But how does a Japanese business account for GitHub sponsorships?

It turns out others have already asked this question and the options generally given are:

Entertainment expenses (交際費)
Donation (寄付金)
Advertising/publicity (広告宣伝費)

So which one should you use?

Entertainment expenses

The idea with entertainment expenses is that if sponsoring a client’s event, for example, helps you to maintain a good relationship with them, you could call that an entertainment expense. (“Entertainment” here being “entertaining” clients to win their favour, not going to the movies, or watching ice blocks melt in the kitchen sink.)

That seems like a stretch in my case. Ovidiu is a swell bloke, but he’s not a client.

Donation

A donation would seem like the obvious choice but it’s tricky.

Firstly, the upper limit on tax-deductible donations is pitifully low. The formula is:

（資本金の額および資本準備金の額の合計額または出資金の額） ×当期の月数を12で割った数×1,000分の2.5＋所得の金額×100分の2.5〕×4分の1＝〔損金算入限度額〕

Source: https://www.nta.go.jp/taxes/shiraberu/taxanswer/hojin/5281.htm
Better still, see the 別表十四（二） PDF

i.e. $Deductible limit = (Capital \times \frac{No. of months this financial term}{12} \times \frac{2.5}{1,000} + Taxable income \times \frac{2.5}{100}) \times \frac{1}{4}$

So let’s plug some numbers in. Let’s assume a small company with 10M JPY in capital making a solid 10M JPY each year. The most you can write off as tax-deductible donations is:

(10,000,000 \times \frac{12}{12} \times \frac{2.5}{1,000} + 10,000,000 \times \frac{2.5}{100}) \times \frac{1}{4} = (25,000 + 250,000) \times \frac{1}{4} = 68,750

Putting that in very rough dollar terms, a company making a profit of 100k USD could only deduct less than 7k in donations.

There are a couple of brackets, e.g. one for recognized charities (特定公益増進法人) and one for general donations (一般の寄附金) but even putting those together, the deductible limit is very low compared to other countries and really doesn’t encourage Japanese companies to be generous.

Secondly, the tax office indicates that gifts that are directly related to the execution of your business should not be donations:

金銭その他の資産または経済的利益の贈与または無償の供与であっても、 法人の事業遂行と直接関係のあると認められる広告宣伝および見本品の費用その他これらに類する費用並びに交際費、接待費および福利厚生費とされるものは、 寄附金から除かれます。

https://www.nta.go.jp/taxes/shiraberu/taxanswer/hojin/5281.htm (Emphasis added)

Advertising

That leaves us with advertising. When you sponsor someone through GitHub sponsors your organisation logo shows up on the project homepage and you get a little “Sponsor” badge on your organisation’s page too. With any luck, the project will spotlight their sponsors in different ways as well. All of this could be reasonably expected to highlight your company, bringing it fame and great prestige.

In any case, my tax accountant agreed advertising was justified in this case which probably counts for more than anything else I’ve written in this post.

”Don’t let your left hand know what your right hand is doing”?

Some people might feel a bit awkward about advertising their contributions, however. In perhaps the most famous speech ever given, Jesus warned against “practicing your righteousness before other people to be seen by them” (Matt 6:1-18) particularly when it comes to giving to charity, praying, and fasting.

I think we often feel a bit skeptical when we see companies promoting their charitable donations and wonder, “Is that a genuine donation or just a marketing ploy? Can companies be genuine anyway?”

In any case, surely contributing to Open Source is not a charitable donation or act of righteousness but just a cost of doing business. Provided the project itself (or GitHub) is doing the advertising it needn’t be awkward self-promotion either.

Are there other options?

Some GitHub sponsorship plans promise benefits like dedicated support and development advice. I wonder if it would be possible to account for these as commission fees (支払手数料), outsourcing (業務委託 or 外注費), or compensation (支払報酬)? Who knows? A tax accountant would but I’ve troubled my tax accountant enough recently with my woeful bookkeeping to bother him again.

Implications for Open Source developers

I have no idea if any of this applies outside Japan, but in the very unlikely case that you are working on Open Source and would like Japanese companies to support you, the obvious implication is promote your sponsors. It makes it easier for them to justify the cost and probably lifts the image of your project at the same time.

Web animation in 2017

Tue, 10 Jan 2017 00:00:00 GMT

Happy new year! As promised I thought I’d share a few of the Web animation things I’m looking forward to in 2017. I’m terrible at predicting the future (I used to be a believer in BeOS and VRML) so this is mostly based on what is already in motion.

Specs:

CSS transitions – this should move to CR status soon. Part of that involves splitting off a separate Timing Functions spec. That separate spec would give us:
- Level 1: An additional frames() timing function to do what step-end and step-start should have done in the first place.
- Level 2: Low-level syntax for export of complex timing functions (multi-segment béziers?), spring timing functions, script-defined timing functions, and perhaps even timing functions that affect the duration of animations.
CSS animations – this too should move to CR soon. All that is really missing is some clarification about the liveness of values and some text about how @keyframes rules cascade. Then we can start work on new things in level 2 like animation-composition.
Web animations – this too is approaching CR and I hope we can ship (most of) the remainder of the API in the first half of this year in Firefox and Chrome. For that we still need to:
- Add a FillAnimation concept to allow browsers to compact finished but filling animations so they don’t keep consuming memory. This is a bit hard, but seems do-able.
- Simplify the timing interfaces to use fewer live objects and make the interface consistent with keyframe interfaces. I hope this will simplify the implementation for Edge and Safari too.
- Add compositeBefore and compositeAfter methods to control how animations combine and overlap.
- Replace SharedKeyframeList with StylePropertyMaps from Houdini.
- Integrate a few tweaks to making specifying keyframes more flexible.
I’m looking forward to shipping additive animation soon since it helps with a lot of use cases, but it really needs FillAnimation first.

getAnimations is also exciting—being able to inspect and manipulate CSS animations and transitions from the same API—but probably won’t ship until the second half of the year when we have the mapping between CSS and Web Animations clearly specified.

Being able to ship the finished and ready promise would be great but was blocked on cancelable promises being realized and now it’s not clear what will happen there.
Scroll-driven animations – This is going to take quite a bit of work to get right, but hopefully within this year we can start shipping parts of it so you can create hidey bars and parallax effects that run smoothly on the compositor.
AnimationWorklet – This is also going to take time to make sure it plays well with the other animation pieces in the platform but fortunately the Chrome folks pushing it have been very responsive to feedback and admirable in their willingness to rethink ideas.

At Mozilla, apart from editing and implementing the above specs, some of the bigger animation items I anticipate this year include:

Making our current animation features work with Quantum CSS, i.e. Servo’s style engine. This involves a lot of tricky plumbing but it means Firefox gets faster and Servo gets more spec compliant.
CSS offset (aka CSS motion). We’ve been putting this off for a while as the spec stabilizes but I hope this year we will actually do it.
Promoting various SVG attributes to properties. Tackling this and the previous item would significantly narrow the gap between CSS and SVG’s (SMIL) animation features and let us simplify the SMIL code a lot.
Animation of CSS custom properties. There are patches written but they need some work before they land.
DevTools. We have plenty of ideas here but most of all we want to make our animation DevTools the place to go not just to debug all the above features, but also to author for them!

If any of those items sound interesting to you, please get involved!

MozAnime in 2016

Tue, 27 Dec 2016 00:00:00 GMT

MozAnime is the informal name we use to cover all the work on animation-related features at Mozilla. We’re based in Tokyo, Tochigi, Taipei, Toronto, and… somewhere in France that probably, hopefully, starts with a ‘t’ as well.

I can’t wait to tell you all the things I’m looking forward to next year, but in this post I want to share some of the highlights from the MozAnime crew in 2016.

Shipped `Element.animate`

Five years since I first proposed Web Animations we finally shipped some of it! We worked together with the Chrome team to make sure we have an interoperable feature set (something web-platform-tests helped with a lot!) and thanks to their work on a polyfill, authors can now write cross-browser animations that in many cases will run in a separate thread. See the hacks article for more details.

Performance of regular JavaScript animation vs Element.animate()

Finished^* Web Animations

Of course, Element.animate is only the tip of the iceberg. Web Animations has a lot more to offer such as being able to modify and query animations—even CSS-defined animations—on the fly and make independent animations that morph together. We finally landed the last pieces of that API last weekend.

^*Technically, however, it’s not actually finished. We haven’t done SharedKeyframeList because that part of the spec is likely to change. In fact, there are a few parts of the spec that will change so we’ll need to do a bit more work on those before we’re ready to ship. More on that next time. Nevertheless, it’s a significant milestone and as far as I can tell we’re the first browser to get there although Chrome is coming along too.

Improved Animation DevTools

We launched our first animation DevTools in 2015 but this year we deepened the collaboration between platform work and DevTools producing some new features like:

Animations on pseudo-elements

Platform performance information

This was initially implemented by an intern who did a great job. This is incredibly useful—if you’re debugging animation performance please give it a try! You can find more details on MDN.

Richer timing display

This is just the start of making the animation inspector much more useful. See Patrick’s hacks article for all the details of this first step. Because of the close integration of platform and DevTools work, these tools also handle the obscure edge cases that might not be apparent to a casual user of animation features (like large negative end delays that overlap start delays). There is a lot more work to do here but the next piece is already up for review and there is more on the way.

(And just in case you’re wondering what an excessively large end delay looks like, it’s something like this.)

Proposed scroll-linked animations and started implementation

At W3C TPAC this year we proposed a spec for scroll-linked animations based on a previous proposal by Apple. There was strong support for pursuing this and Google have been actively involved too, giving great feedback. We have an initial implementation due to land any day now but it will be preffed-off initially since there is still a lot of spec discussion that needs to happen.

Specced and implemented new transition events

Our experience with Firefox OS helped us realize how difficult it can be to work with transitions. Sometimes they don’t fire (e.g. you set a property to its existing value), and sometimes they get cancelled (e.g. you “re-rendered” a part of the DOM and blew away the elements that were transitioning), so if you’re waiting for transitionend you could be waiting a long time.

So we specced transitionrun (for when the transition is created), transitionstart (for when the transition finishes its delay—mostly since Edge already had this), and transitioncancel (for when the transition is dropped without reaching the end). They’re implemented in the latest Nightly edition of Firefox (53) and we’ll implement a similar animationcancel event for CSS animations soon.

What’s coming up in 2017?

That’s enough for one post but I’ll follow up early in the new year with what we hope to do in Mozilla-land in 2017 as well as some of the other animation-related developments I’m looking forward to in the wider Web landscape.

Thank you to the many people who contributed, not only to Mozilla but also to many fantastic people at Google and Microsoft in particular whom I had the pleasure of working with this year. Happy new year!

Gecko insiders

Fri, 01 Apr 2016 00:00:00 GMT

At Mozilla Japan, we’ve been doing a series of monthly events called “Gecko inside” where we discuss details of hacking on Gecko in the hope of helping each other learn and helping new contributors to get started.

Last weekend we held a special “write a patch” day where we gathered a group of long-time contributors to mentor first-time contributors through the process of setting up a build environment, writing a patch, and getting it reviewed and landed.

We fixed nearly a dozen bugs on the day and if you were hanging around on #developers about that time, you might have been surprised at the stream of Japanese names ticking by.

It was a fun event with veterans and first-time contributors alike asking if we could do it again.

Gecko internals

In keeping with the topic of new contributors, we were recently very pleased to have Ryo Motozawa join us for an internship during his university’s winter break. Ryo came to us with more curiosity than experience but quickly found his way around implementing WebIDL interfaces, animation timing features, and a number of DevTools features including exposing detailed animation performance information (due to land any day now!) using an interface Hiro recently built—all in just 2 months! Nice work Ryo!

(And, before you mention it, there’s already a bug to fix the text in that tooltip!)

Gecko geeks

Some of the other notable things we’ve been plugging away at here in Japan include:

Clearing out the blockers from shipping Element.animate() which should be ready for Firefox 48.
Steadily filling in the rest of the Web Animations API.
Fixing a long-standing issue with keyboard shortcut keys not working when plugins are active. Masayuki has done some heroic refactoring here and it should already be working on Nightly builds for Mac with just a bit more work to go for Windows.

Also, while far from a Japan-only effort, another animation-related feature I should mention is that thanks to platform work from Boris Chiou and Daisuke Akatsuka, and DevTools work from Patrick Brosset, the animation inspector now finally works with animations on pseudo-elements!

They’re just a few of the things we’re excited about at the moment. Oh, and this view!

Mozilla Japan engineering is quite hot right now

Thu, 06 Aug 2015 00:00:00 GMT

Fortunately Taipei’s shaved ice extravaganza Ice Monster has popped-up just around the corner from our office in Tokyo!

Now that I’ve sufficiently buried the lede, I’d like to introduce you to what our platform engineers have been up to in the land of the rising (and scorching) sun.

Since April we’ve been trying to focus our efforts around two themes: Input and Animation although we also work on other items like fonts and supporting partner projects. Some of the things we’re tackling this quarter include:

Input:

Prototype a new Japanese IME for Firefox OS
Fix IME-related bugs blocking e10s
Work on some performance issues in the Firefox OS keyboard

Animation:

Try to get our Web Animations implementation in shape so we can ship Element.animate by the end of the quarter
Work on PerformanceObserver so we can implement the Frame Timing API on top of it
Work on a few animation performance issues

Other:

Start to merge the Firefox OS TV simulator into mozilla-central

Gecko guts

Last night we held our first “Gecko inside” meetup. The idea is for engineers to teach each other about different parts of our code and provide some useful information to people who are interested in contributing. This time, Makoto gave us a great overview of e10s in Firefox.

We plan to do it again on September 8 including a special guest appearance from Gary Kwong presenting on fuzzing in Firefox!

If you’re in Tokyo please drop by! Better still, if you’re hacking on any of the same things, why not pay us an extended visit? In addition to Taiwanese shaved ice, we’ll gladly introduce you to some tasty sushi or barbecued beef tongue.

What do we do with SMIL?

Fri, 01 May 2015 00:00:00 GMT

Earlier this week, Blink announced their intention to deprecate SMIL. I thought they were going to replace their native implementation with a Javascript one so this was a surprise to me.

Prompted by this, the SVG WG decided it would be better to split the animation features in SVG2 out into a separate spec. (This was something I started doing a while ago, calling it Animation Elements, but I haven’t had time to follow up on it recently.)

I’ve spent quite a lot of time working on SMIL in Gecko (Firefox) so I’m probably more attached to it than most. I also started work on Web Animations specifically to address Microsoft’s concern that we needed a unified model for animations on the Web and I was under the impression they were finally open to the idea of a Javascript implementation of SMIL in Edge.

I’m not sure what will happen next, but it’s interesting to think about what we would lose without SMIL and what we could do to fix that. Back in 2011 I wrote up a gap analysis of features missing in CSS that exist in SVG animation. One example, is that even with CSS Animations, CSS Transitions, Web Animations and the Motion Path module, we still couldn’t create a font using SVG-in-OpenType where the outlines of the glyphs wiggle. That’s because even though Web Animations lets you animate attributes (and not just CSS properties), that feature is only available via the script API and you can’t run script in some contexts like font glyph documents.

So what would we need? I think some of the following might be interesting specs:

Path animation module – We need some means of animating path data such as the ‘d’ attribute on an SVG element. With SMIL this is actually really hard—you need to have exactly the same number and type of segments in order to interpolate between two paths. Tools could help with this but there aren’t any yet.

It would be neat to be able to interpolate between, say, a <circle> and a <rect>. Once you allow different numbers of segments you probably need a means of annotating anchor points so you can describe how the different paths are supposed to line up.

(If, while we’re at it, we could define a way of warping paths that would be great for doing cartoons!)
Animation group module – SMIL lets you sequence and group animations so they play perfectly together. That’s not easy with CSS at the moment. Web Animations level 2 actually defines grouping and synchronization primitives for this but there’s no proposed CSS syntax for it.

I think it would be useful if CSS Animations Level 2 added a single level of grouping, something like an animation-group property where all animations with a matching group name were kept in lock-step (with animation-group-reset to create new groups of the same name). A subsequent level could extend that to the more advanced hierarchies of groups described in Web Animations level 2.
Property addition – SMIL lets you have independent animations target the same element and add together. For example, you can have a ‘spin’ animation and a ‘swell’ animation defined completely independently and then applied to the same element, and they combine together without conflict. Allowing CSS properties to add together sounds like a big change but you can actually narrow down the problem space in three ways:
1. Most commonly you’re adding together lists: e.g. transform lists or filter lists. A solution that only lets you add lists together would probably solve a lot of use cases.
2. Amongst lists, transform lists are the most common. For this the FXTF already resolved to add translate, rotate and scale properties in CSS transforms level 2 so we should be able to address some of those use cases in the near future.
3. While it would be nice to add properties together in static contexts like below, if it simplifies the solution, we could just limit the issue to animations at first.
```
.blur {  filter: blur(10px); }
.sepia { filter: sepia(50%); }
```

There are other things that SMIL lets you do such as change the source URL of an image in response to an arbitrary event like a click without writing any programming code but I think the above cover some of the bigger gaps? What else would we miss?

After 10 years

Fri, 31 Oct 2014 00:00:00 GMT

Yesterday marks 10 days to the day since I posted my first patch to Bugzilla. It was a small patch to composite SVG images with their background (and not just have a white background).

Since then I’ve contributed to Firefox as a volunteer, an intern, a contractor, and, as of 3 years ago tomorrow, a Mozilla Japan employee.

It’s still a thrill and privilege to contribute to Firefox. I’m deeply humbled by the giants I work alongside who support me like I was one of their own. In the evening when I’m tired from the day I still often find myself bursting into a spontaneous prayer of thanks that I get to work on this stuff.

So here are 8 reflections from the last 10 years. It should have been 10 but I ran out of steam.

Why I joined

I got involved with Firefox because, as a Web developer, I wanted to make the Web platform better. Firefox was in a position of influence and anyone could join in. It was open technically and culturally. XPCOM took a little getting used to but everyone was very supportive.

What I learned

Don’t worry about the boundaries. When I first started hacking on SVG code I would be afraid to touch any source file outside /content/svg/content/src (now, thankfully, dom/svg!). When I started on the SVG working group I would think, “we can’t possibly change that, that’s another working group’s spec!” But when Cameron McCormack joined Mozilla I was really impressed how he fearlessly fixed things all over the tree. As I’ve become more familiar and confident with Firefox code and Web specs I’ve stopped worrying about artificial boundaries like folders and working groups and more concerned with fixing things properly.
Blessed are the peacemakers. It’s really easy to get into arguments on the Internet that don’t help anyone. I once heard a colleague consider how Jesus’ teaching applies to the Internet. He suggested that sometimes when someone makes a fool of us on the Internet the best thing is just to leave it and look like a fool. I find that hard to do and don’t do it often, but I’m always glad when I do. Earlier this year another colleague impressed me with her very graceful response to Brendan’s appointment to CEO. I thought it was a great example of peace-making.
Nothing is new. I’ve found these words very sobering:

What has been will be again,
what has been done will be done again;
there is nothing new under the sun.
Is there anything of which one can say,
“Look! This is something new”?
It was here already, long ago;
it was here before our time.

Ecclesiastes 1:9–10

It’s so easy to get caught up in some new technology—I got pretty caught up defending SVG Animation (aka SMIL) for a while when I worked on it. Taking a step back though, that new thing has almost invariably been done before in some form, and it will certainly be superseded in my lifetime. In fact, every bit of code I’ve ever written will almost certainly be either rewritten or abandoned altogether within my lifetime.

In light of that I try to fixate less on each new technology and more on the process: what kind of person was I when I implemented that (now obsolete) feature? What motivated me to work at it each day? That, I believe, is eternal.

How I hope Mozilla will shape up over the next 10 years

I hope we’ll be the most welcoming community on the Web. I don’t mean that we’ll give free hugs to new contributors, or that we’ll accept any patch that manages to enter Bugzilla, or we’ll entertain any troublemaker who happens upon #developers. Rather, I hope that anyone who wants to help out finds overwhelming encouragement and enthusiasm and without having to sign up to an ideological agenda first. Something like this interaction.
I hope we’ll stay humble. I’d love to see Mozilla be known as servants of the Web but when things go well there’s always the danger we’ll become arrogant, less welcoming of others’ ideas, and deaf to our critics. I hope we can celebrate our victories while taking a modest view of ourselves. Who knows, maybe our harshest critics will become some of our most valuable contributors.
I hope we’ll talk less, show more. By building amazing products through the input of thousands of people around the world we can prove Open works, we can prove you don’t need to choose between privacy and convenience. My initial interest in Mozilla was because of its technical excellence and welcoming community. The philosophy came later.
I hope we’ll make less t-shirts. Can we do, I don’t know, a shirt once in a while? Socks even? Pretty much anything else!

Animations on Fire @ Graphical Web 2014

Mon, 08 Sep 2014 00:00:00 GMT

Just recently I had the chance to talk about authoring animations of CSS/SVG for better performance at The Graphical Web 2014. I thought I’d put up the slides here in case they’re useful to others.

If you’re reading this blog directly or the syndicator didn’t eat this bit, you can view the slides right here:

Web Animations @ html5j 2013

Tue, 24 Dec 2013 00:00:00 GMT

Over the weekend I had the chance to speak about Web Animations at the HTML5 conference 2013 in Tokyo. I put a fair bit of work into the presentation so I thought I’d put up an English version of the slides (including videos of the demos) in case they’re useful to someone else looking for a gentle introduction to Web Animations.

I ran out of steam when producing the last few slides so it kind of ends with a fizzle but I put a fair bit of work into the other ones so hopefully it’s entertaining. Although you can’t tell from the slideshare version most of the slides include animation somewhere and most of the pictures are made with SVG so I think it looked pretty.

Slideshare / PDF

(If you’re curious there’s the HTML version too but be warned that it doesn’t have explanatory notes like the slideshare and PDF versions.)

(日本語の資料ももちろんあります！イベントの配信、Slideshareの資料、PDF版、HTML版(注釈なし)をご覧ください。）

Players wanted: the pause and seek game

Thu, 25 Jul 2013 00:00:00 GMT

Last time I introduced timing groups in Web Animations as a simple yet powerful tool for synchronising animations. Great as they are, they open up a few interesting questions. For example, what happens when you pause an animation that’s in a timing group?

Consider the following parallel timing group. It has two child animations, A and B, and the group repeats twice.

A parallel timing group with two children A and B whereby the group repeats twice.

Suppose we pause child animation A at the red down arrow and then resume it at the red up arrow. What should happen?

One option is to just let everything play as normal.

A child of the parallel timing group is paused such that all other animations continue to play as normal.

But then what happens to the second run of A? Does it run at all? Get squashed? Get overlapped? And if so, who wins?

So what if we automatically unpause animation A when we hit an iteration boundary?

A child of the parallel timing group is paused such that it is automatically unpaused when an interval boundary is reached.

From an API point-of-view that automatic unpausing is tricky and likely to lead to bugs where a piece of script assumes an animation is paused but on some devices the interval boundary occurs before the script gets a chance to run, breaking the assumption.

Another approach is just to stretch the iteration to fit the pause like so.

A child of the parallel timing group is paused such that the iteration is stretched to fill the pause amount.

This mostly works for parallel containers but, like the other behaviours, it doesn’t make sense for a sequence timing group because the sequence is broken.

Also, all these behaviours are problematic if we seek the group whilst a child is paused. And if we seek backwards after unpausing what is the expected state of the world?

The approach that provides the most intuitive behaviour in these situations is simply to pause the group as a whole like so.

A child of the parallel timing group is paused by applying the pause to the group.

This of course applies all the way up the tree.

But what do other APIs do?

Looking at a number of other animation APIs:

QML just ignores play control on animations if they’re in a group.
Android doesn’t include repeating etc. on groups and animations and groups don’t have play control.
In WPF only the root clock can be interactively controlled.
In HTML, media slaved to a controller (similar in some sense to a timing group) behaves differently to independent media. You can pause it independently, but seeking throws an exception. Pausing due to buffering pauses the controller. There is no repeating.

In summary, QML and WPF push pausing to the root of timing hierarchy. Android and HTML manage to do something different but only because they don’t allow groups to repeat.

For Web Animations, like QML and WPF, the best option is to push pausing and other play control to the root of the timing hierarchy. The trouble comes when we try to represent this in the API.

At first we tried to do this transparently, that is, you’d call pause and it would just go up to the top-level timing group and apply the pause there. However, a couple of concerns were raised with this,

It’s not obvious that the operation you’re performing may have wide-reaching effects.
It doesn’t work for seeking since the time values are relative to the child not the parent. HTML just throws an exception in this case, but some people felt uncomfortable that this method would sometimes work and sometimes throw an exception depending on whether there was a parent timing group or not.

Enter the players

In order to emphasise the fact that play control (pausing, seeking, etc.) takes place at the root-most timing group a new concept, the player, was introduced. A player plays things. It’s the point of attachment between some timed content and a timeline. The arrangement is as follows.

Players form the point of attachment between the rootmost timing groups and animations and a timeline.

From a code point of view it looks like this:

var anim = elem.animate({ left: '20px' }, 3);
anim.player.pause();

This separation hopefully makes it more obvious to an author that the change they are making may have more wide-reaching effects.

It also can make avoiding some common coding mistakes a little easier.

// The following could cause some animations to be sped up 4, 8 times or more
elem.getCurrentAnimations().forEach(function (anim) {
  anim.player.playbackRate *= 2;
});

// The following will speed everything up by a factor of 2 and no more
elem.getCurrentPlayers().forEach(function (player) {
  player.playbackRate *= 2;
});

It also has a few nice properties:

TimedItem.localTime is always readonly and has a different name to the always writeable Player.currentTime.
TimedItem.timing.playbackRate affects the model in the same way as changing other timing parameters does including possibly causing the playback position to jump. Player.playbackRate, on the other hand, makes dynamic changes so that the current playback position is preserved.

Unfortunately, introducing the idea of players adds conceptual weight to the API. It’s probably one of the most unfamiliar concepts for people coming to the specification (hence this blog post!). For these reasons I resisted this change strongly but ultimately lost. 🙂

That said, it does make the model more consistent and therefore, to some degree, more intuitive. It is also expected that many authors will never use this functionality (jQuery, for example, does not provide pause control) and so this additional concept shouldn’t become a barrier to adoption for simple usage.

I’ll look forward to seeing how authors take to this concept. If you have any feedback, feel free to follow-up at public-fx@w3.org with subject starting [web-animations].

Upcoming changes

Recently we’ve been discussing some changes to the way players work. Currently they just keep playing forever but we think it might make sense for them to behave more like a VCR and stop when they hit the end of their media. This would allow us to define a reverse() method that behaves sensibly and perhaps make players then-able.

You can see some of the discussion in the minutes from our recent telcon, item 6, Making players stop. As always, your comments are welcome at public-fx@w3.org.

Group and conquer: timing groups for your synchronization woes

Tue, 09 Jul 2013 00:00:00 GMT

Once you start animating anything more than simple fade and slide effects, pretty soon you start wanting to synchronize things. The penguins should start dancing together, the watermelon should explode the moment the blind-folded person hits it, the credits should roll after the movie finishes and so on.

In this post I want to outline the approach taken to these problems in Web Animations and the biggest new feature in the spec: timing groups. But first, what can we already do?

Synchronization in CSS

In CSS you can do a few things:

By toggling a style on a common ancestor you can get two animations to start at the same time. For example, see this example from Smashing Magazine.
Using animation-delay you can stagger the start times of animations and by calculating the length of A, you can use this to make B start after A.

There are a few limitations though:

It’s not particularly scalable—if A changes duration, you need to update B as well. That’s particularly problematic if, for example, A is a video of unknown length.
You’re not declaring the temporal relationships between different animations—their synchronization is just a by-product of how you triggered them—and as a result there’s no easy way to pause or seek a particular set of animations.
It requires you to structure your document so that you’ve got a common ancestor to toggle a class on. Suddenly your document structure is doing triple duty: semantics, layout (all those empty <div>s to persuade CSS to do what you want), and timing.
You can’t create animations on the fly that line up with already running animations.

The problem with SVG and syncbase timing

SVG has a neat feature which seems to meet these needs: syncbase timing. That lets you create arrangements like:

<animate id="a" begin="b.end" ... />
<animate id="b" begin="0s" end="c.end" ... />
<animate id="c" begin="a.begin+2s" ... />

That would seem to do everything we could ever want, except it has a few problems:

It’s complex. The above example is just the tip of the iceberg. You can have any number of conditions on both the begin and end of an animation pointing to any other animation including the same animation. You can create cyclic dependencies and some are allowed, some are not, and the rules for breaking cycles are vague (and thus, inconsistently implemented).

What’s more, all this feeds in to the most complex part of SVG animation: deciding what intervals to create. As a result if you want to determine what animations are active at a given time, you have to step through all the significant moments up to that time and work out what intervals to create. This makes seeking costly.
Another problem is that you can’t cancel just part of such a sequence.

For example, imagine you have a sequence of actions A, B, and C representing “fade the background of the button from grey to blue”, “pulse it”, then “make it glow”. You trigger A when the mouse moves over the button but the mouse suddenly leaves while A is still running. You cancel A (e.g. using end="mouseout" or endElement) but then B still runs since it sees that A has ended. And consequently C also runs. There’s no way to cancel the chain and nor is there any way to seek/pause such a chain independently of other animations that might be running.

Enter timing groups

These use cases can be addressed using the concept of timing groups. This is a well-established concept in animation APIs. For example,

QML has ParallelAnimations and SequenceAnimations.
SMIL has <par>, <seq>, and <excl> time containers.
Android has AnimatorSets that play animations together or in sequence.

Common to all these APIs is the concept of two types of groups: groups that run animations together and groups that run animations in sequence.

Furthermore, in each of these APIs the two types of groups can be nested so you can easily build complex arrangements up from simple parts in a way that is easy to reason about.

For example, the following arrangement:

<animate id="curtainOpens" ... />
<animate id="penguinADances" begin="curtainOpens.end" ... />
<animate id="penguinBDances" begin="curtainOpens.end" ... />
<animate id="curtainCloses" begin="penguinBDances.end" ... />

could be represented with timing groups as:

<seq>
  <animate id="curtainOpens" ... />
  <par>
    <animate id="penguinADances" ... />
    <animate id="penguinBDances" ... />
  </par>
  <animate id="curtainCloses" ... />
</seq>

Graphically, the arrangement is as follows:

You can cancel a chain of animations in this case by simply cancelling the group. The hierarchical nature of the groups also means seeking is constant-time with regards to the seek interval.

Timing groups in Web Animations

In Web Animations we have adopted this same approach of using timing groups with the following features:

Two types of timing groups: parallel, sequence.
Children of a group can have a delay which can also be negative. This allows children of a sequence group to overlap so you can, for example, start a fade animation 2s before a video ends. (SMIL does not allow negative delays on children of a sequence group.)
Any timing property you can apply to an animation, you can also apply to a group which means you can repeat, ease, reverse, delay, or speed up a group.

The last point is interesting since most other APIs don’t do that. It can be quite useful as we showed in a demo of this in our preview video last October where we combined a door closing animation and a creaking sound “animation” in a group then eased the group.

However, it introduces some complexity. For example, since easing functions can be non-invertible, it means you can’t always convert from child time to group time which complicates event handling.

Also, the interaction between fill modes specified on a group and on a child are not always obvious and we need to revise the spec to be more intuitive in this area.

Building up the example above using the API in Web Animations look like the following.

document.timeline.play(
  new SeqGroup([
    new Animation(...),   // Curtains open
    new ParGroup([
      new Animation(...), // Penguin A
      new Animation(...)  // Penguin B
    ]),
    new Animation(...)    // Curtains close
  ])
);

On a side-note, we’ve had some feedback about ParGroup and SeqGroup being a bit cryptic, especially for anyone not familiar with SMIL (which is pretty much everyone). ParallelGroup would be more readable but it’s a lot to type for something we expect authors to use a lot. I wonder if just Parallel would make sense? Perhaps this could be a named constructor for ParallelGroup? If you have any suggestions we’d love to hear them. Either respond here, or, better yet, send a mail to public-fx@w3.org with subject starting [web-animations].

The mapping of timing groups to SVG and CSS has yet to be worked out.

Future extensions to timing groups

One common request that arises in regards to timing groups is the ability to set the duration of the group and specify the duration of the children as fractions of that parent. That sort of adaptive duration is something that’s quite useful but also can easily become complex—like CSS flexbox in the temporal domain. It’s something we’ll look at in a future version but for now we’re comfortable it can be added to the model and API fairly naturally.

If you want to read up on the detail, have a look at the spec. As always, your comments are welcome at public-fx@w3.org with subject starting [web-animations].

Introducing Web Animations

Wed, 26 Jun 2013 00:00:00 GMT

Today we finally shipped the First Public Working Draft of Web Animations!

Working Draft: https://www.w3.org/TR/web-animations/
Editor’s Draft: https://drafts.csswg.org/web-animations-1/

Over the coming weeks I’d like to introduce some of the key concepts as well as some of the issues that need your input.

First, I’d like to give an overview of where the spec comes from and what it covers.

Why Web Animations? A summary of happenings until now

On the Web today we have CSS Animation (including Transitions) and SVG Animation and they both have their problems. For example, CSS is so simple it doesn’t even support synchronization and SVG is pretty hairy when it comes to interval negotiation and syncbase timing—and it’s SVG-only. Most of all, though, they’re completely separate.

Also, Microsoft don’t support SVG Animation. They have consistently maintained that they want to see a single model for animation on the Web (e.g. minutes) and that that model should have an API. That’s a very reasonable position in my mind, albeit frustrating for authors who want to use SVG Animation now.

The story since then is as follows:

On several occasions throughout 2011 and 2012 I proposed various alternatives (#1 – presentation, #2, #3) for harmonizing the two such as importing SVG features into CSS and vice versa. People mostly just nodded in agreement and nothing happened.
In January 2012, Adobe wisely suggested I go away and prepare a concrete proposal so people can get a feel for what is might look like. Adobe also offered to assist where they could.
At the end of January 2012 I invited a contact from Google to join in since he had some great ideas about state machines.
In March 2012 folks from Adobe, Google and I (Mozilla) got together in Tokyo and hacked out a first version of the spec.
In May 2012 we got approval from the CSS and SVG working groups to continue this work as an official work item.
In September 2012 we presented a demo of the work at the Graphical Web conference in Zurich (video recording).
In June 2013 we got approval from the CSS and SVG working groups to publish a FPWD.
Today (25 June 2013) we finally published something!

What’s in the box?

Basically, this:

Web Animations is essentially a common model for animation that underlies CSS and SVG. It covers the common features of both plus a few only found in one or the other.

It also has a few extra features not currently found in either:

Timing groups – This is the primary means of synchronization. It’s quite powerful but I’ll leave the details and justification for this to a separate post.
Speed control (#1 and #2) – This is a requested feature for SVG2 and may be useful for achieving reversing effects such as exposed in CSS.
Custom effects (API) – This allows the Web Animations timing model to be used to drive animations of HTML canvas etc. by registering a script callback.
Iteration start – This is a minor but much-requested feature that allows you to start an animation part-way through its interval.

What’s not included?

Bear in mind that Web Animations is essentially a model. It’s not a declarative syntax. That’s something left to other specs. The API happens to be bundled with the model simply because that makes it easy to keep the two in sync.

The arrangement is as follows:

The CSS-specific features required for CSS animations and transitions will be covered in a separate specification, possibly called “CSS Animations/Transitions level 4” which expresses its features in terms of the Web Animations model.

Likewise, current SVG features such as syncbase timing, or targetting attributes (not just CSS properties) will be covered by a separate specification (my next task) expressed in terms of that model. That specification may be called something like “SVG Animation” but I suspect not since quite a few people have expressed interest in allowing it to apply to HTML content too.

Other features that are not included:

Bounce/spring timing functions – we really wanted to make this possible and have a couple of simple extensions to timing functions to allow this but we haven’t yet reached agreement about which one is best so we’re leaving them both out for now.

The plan is to follow up with a separate specification which provides additional timing functions anyway.

(In fact, with the current working draft, you can’t even do more than one timing function over an animation currently but that will be fixed in the next draft when we introduce chained timing functions).
Media integration – this is something a lot of people have been asking for but we decided to postpone it in the interests of progressing the spec along.

The good news is this used to be part of the spec so we know it integrates very cleanly.

For now we’ll work on it in a separate spec and if that comes along quickly enough we might merge it back in.
State machines – this is something that is very useful when you start programming UI interactions but something we decided is not critical for the first version of the spec.

Again, we’ll probably work on this as a separate spec.

API?

Originally I opposed the idea of adding an API because I think declarative solutions are generally preferable. However, the API is useful in a few cases:

It lets you inspect the state of all animations in the document. Anyone can build developer tools that present you with a timeline of all the running CSS animations/transitions/SVG animations in the document for debugging.
It lets you make runtime changes to declarative animations—for many apps a combination of declarative and procedural approaches is the best fit and lets you achieve effects that might not be possible using purely declarative features.
For some problems a procedural approach is suitable and in those cases using the API is both simpler than writing the animation loop yourself and also means the browser can optimise the animation for smoother performance and less battery consumption.

Implementations?

Work has started on implementation in Blink and is on the radar for Gecko. Until then a polyfill is coming along in leaps and bounds and covers nearly all of the FPWD.

That’s it for now. I’ll follow up with posts explaining specific features and issues needing input but if you have any feedback on the spec, don’t hesitate to send it along to public-fx@w3.org with subject [web-animations]. Thanks!

Help with math(s)

Tue, 15 Jan 2013 00:00:00 GMT

UPDATE: I originally prepared this post before others working on the Web Animations spec assured me they would find a solution. I posted it password-protected for their sake not realising it would show up on planet! Sorry! Anyway, here is the original post for those who were curious. There are already some folks working on this, but other input may still be useful!

One of the limitations of CSS and SVG animations is that you can’t do a bouncing effect. That is, you can’t easily do this:

Bouncing in SVG. Click the circle to restart.

You can emulate it (as above), but it really should be the job of the timing function to do this kind of easing.

In Web Animations we’ve been trying to address this. At first I tried creating a simple smoothing function where you’d specify a series of points and it interpolates smoothly between then. This proved more complex than expected so I narrowed the problem down to just spring-like animations.

It’s easy to generate a spring-like function—I found a sine wave plus exponential dampening plus some scaling of the period does ok, but in terms of parameterisation I think you probably want the following handles:

overshoot – How far past the target value to reach on the first cycle of the spring-like motion. 1.5 means overshoot by 50% (when exposed to CSS and SVG, this parameter might be exposed as just ’50%’ instead of 1.5). This is particularly useful if, for example, you’re animating something inside a container and want to be sure the effect won’t fall outside the bounds of the container.
elasticity - How much should it bounce back and forwards before converging on the target value? Higher numbers mean more bouncing. After discussing with the others working on Web Animations spec, this may or may not be the most suitable parameter. If at all possible however we want to reduce the number of parameters to avoid being as complex as QML.

Parameterising the spring function in those terms proved a bit beyond my mathematical abilities. I made the following prototype but it’s all kinds of clumsy.

Overshoot: Elasticity:

Problems:

Doesn’t work in all ranges. For example, for an overshoot of 5, the second peak is higher than the first. An overshoot of 1 also doesn’t work.
The first part of the curve (on the initial path to the overshoot value) seems wrong—sometimes there are lumps or kinks in it.

Rough requirements for the function, f(x):

overshoot is a value in the range [1,∞)
elasticity — not even sure if this is the right parameter. It would probably be ideal if elasticity of 1 simply made the animation go to the overshoot value and then return to 1 without any bouncing. A value of 2 might make it overshoot once, dip below 1, then return on 1.
For 0 ≤ x ≤ 1 the global(?) maximum of the function is overshoot and this should also be the first maximum in the range
f(0) = 0 and f(1) = 1
When elasticity is high or overshoot is high it should probably reach the overshoot value sooner since the bounce component will take longer to complete
The function should probably not go negative initially, unless overshoot > 2 in which case it might be ok.
Not sure if the first part should be ease-in.

As I said, there are already some folks working on this, but if you want to have a try you can fork the fiddle above and hack away. Alternatively, there is an Excel spreadsheet or OpenDocument spreadsheet version.

On the other hand, if you think this is not the most useful function or something more general is possible, feel free to suggest that too!

Web Animations

Wed, 31 Oct 2012 00:00:00 GMT

It must be time for my biannual blog post and this time I’d like to introduce a new development in animation for the Web, called, creatively enough, Web Animations.

Some of you may have heard rumblings of an attempt to overcome some of the limitations with both CSS and SVG animations and unify them at the same time. Well, that’s what some folks at Google, Adobe and myself (Mozilla) are trying to do.

I’ve put together a video of some of the ideas we have so far:

An in case the video gets synderadicated here’s a Youtube link: https://www.youtube.com/watch?v=VvNQNtIfXXI

If you’re interested in the details, the latest version of the spec is here:

https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html

A few points to bear in mind:

There are still lots of holes. The behaviour of pausing and reversing is particularly in flux at the moment and the integration with media is still just thoughts, yet to be fleshed out and spec-ified.
The integration with CSS and SVG will be specified in separate documents (just placeholder text for now).
If you’ve got suggestions, please feel free to send feedback to the public-fx W3C mailing list with the subject [web-anim] at the start of the subject.
Progress from my end has slowed down recently due to some workshops I’ve been involved in but I’ll hopefully be back into it by the end of November.
We have a shim in the works (that’s what the video uses) but it’s currently awaiting approval for release. Should be ready soon.

Parapara Animation

Fri, 27 Jan 2012 00:00:00 GMT

About a week ago Mozilla Japan put on a two-day event in Tokyo called Mozilla Vision 2012. It was a great weekend with several hundred people coming to talk about what it means to be Open, and, in very Japanese-style, see some cool robots (courtesy of Takahashi Tomotaka-san).

Personally, I was involved in running the Parapara Animation Workshop* where kids enjoyed drawing simple frame-based animation on a tablet which was then added to a much bigger animation projected on the walls. The purpose of the project was to teach kids the basics of animation as well as to encourage them to be not just web spectators but web makers.

It’s a workshop that was originally done by a group of Keio University Students and they helped run it again this time. The main difference is that last time it was mostly iOS-based, this time it was all Web.

Christian Heilmann has written up a great summary of this part of the program including a quick interview where you can see how it worked.

Japanese kids are really creative so it was a really fun time. But not only was the event fun, the technology side was really fun too.

Some of the technology used

SVG—heaps of SVG. The hand-drawn paths, UI widgets, all of the animation, all of it is SVG. In particular we used a lot of SVG Animation and even SVG applied to HTML to provide the glowing effect on the form text (as per the designer’s prototype—not my idea!)
Fennec (Firefox for Mobile)–Just a regular release build (version 9), plus Matt Brubeck’s Full Screen add-on and a few config tweaks.
Touch events
CSS calc
CSS transitions

What went well

SVG’s native motion on a path (<animateMotion>) saved us so much time. The auto-rotate feature (rotate="auto"), path APIs (getPointAtLength), and ability to calibrate the path length (pathLength="1") also made it easy to position animations at just the right place so they would appear on the screen as soon as the user pressed “send”.
Using SVG made it really easy to do the drop shadows. Just a transform and a blur filter and we were done.
SVG animation was surprisingly fast. I expected it to be really slow but it was the fastest of the alternatives we tried. That said there’s still a lot more work to be done (see below).
Overall SVG just proved really versatile. Being able to show a faint greyed outline of previous frames just by setting an attribute was great. Likewise being able to do all the animation work on the client-side and then just serialise the subtree and send it to the server was so much simpler than the previous version.
Deployment over the Web was great. Just refresh the page to pick up the bug fixes! Likewise when we ran out of tablets at one point we could just load up the editor URL on a laptop and keep drawing.

What didn’t go so well

The app marketplace. We badly wanted to package it all up as a Web app using the framework developed by the Mozilla Labs Apps project. We hoped that would give us full-screen display and stop the user from accidentally navigating to other pages. We had high hopes but were shattered to find the Android runtime launched the app in a Webkit runtime which didn’t even support SVG.
Going full-screen. Due to some technical reasons we were stuck with an old version of Fennec and old UI which took some coaxing to go full-screen and stop the chrome from flying in when the user was drawing. Fortunately the bugs that stopped us from using a more recent version of Fennec appear to have been fixed so next time we can hopefully use the Fullscreen API and multi-touch for drawing with all your fingers at once (something the really young kids really wanted to do!)
CSS and UI layout. Countless hours were sunk into trying to convince CSS to layout widgets on the screen. In the end I gave up and did half of it in script. I’m told CSS flexbox can help a lot here but I spoke to one implementer of flexbox who said that some of the things we were trying to do weren’t possible even with flexbox.
Graphics performance. For the combined animation we badly need a boost to our SVG rendering performance. On Windows the performance was generally ok (if you don’t have a loud fan!) but occasionally got jittery. On Mac it looked terrible. We still have a way to go here. Apart from the graphics performance there’s still lots of room to optimize SVG animation itself too. For the editor running on the tablets, I have one patch awaiting review which I hope will make using SVG’s path APIs faster and speed up the drawing and erasing operations.

The result

The gallery of animations

The editor

And, of course, the code is waiting for your help at github!

Feedback

“That’s a web page?!?” I’m certain that most people who used the demo were oblivious to the fact they were using the Web and that’s probably the greatest success of this demo. Without exception, everyone who asked about the technology was surprised it was Web-based. Everyone assumed it was a native Android app or otherwise Flash.

“That’s SVG?!?” The web developers who came were also surprised at the use of SVG. Most had never really thought of making use of it. They assumed we were using canvas.

“I want to cry, this is the first time I’ve seen Fennec used for something other than reading the news”

Although a lot of the features we used are still in development it was very rewarding to see how much is already possible with Open Web technologies. We’ve had many requests to run this workshop elsewhere and, with your help, it will hopefully get better each time. Thanks very much to the Parapara Animation team and to everyone who contributed to Fennec, Gecko and the Web standards that this is built on.

* For anyone wondering what “parapara” means, it’s the sound of flipping paper and its use here comes from “parapara manga” which means “flipbook comic”. It’s also the name of a kind of hand dancing so we might have to reconsider the name so as not to disappoint the kids.

It’s about time…

Wed, 13 Oct 2010 00:00:00 GMT

Firefox 4 is going four dimensional! Time dimensional! (Ok, for those who know physics, just pretend 🙂)

There’s CSS transitions for all sorts of animated eye-candy, major JS speed-ups to give scripted animations a boost and mozRequestAnimationFrame to get keep them smooth and in sync, and a whole host of other graphics and video improvements. Oh, and SMIL in SVG!

Speaking of which, I thought I’d bring you up to speed on some of the recent progress on the SMIL front.

Event timing

One of the more recent additions to our implementation is the ability to key animations off DOM events such as mouse clicks and key presses.

This paves the way to creating widgets of questionable aesthetic value:

You’ll need to be running a recent nightly to experience this button is all its tacky glory. With the latest Firefox 4 beta the motion will be jerky due to bug 557885.)

However, SMIL animations need not only be keyed off SVG events but any event in the current document is fair game. So, for example, suppose we want to add a tape animation that runs whenever a certain video is in play, we can do it with this piece of SMIL:

<animate attributeName="stroke-dashoffset" from="0" to="90"
  dur="1s" repeatCount="indefinite" fill="freeze"
  begin="video.playing" end="video.pause; video.ended"/>

Demo of video with SMIL-animated icon synchronised with the video playback state

In addition to events, you can also key animations off:

key presses: <animate begin="accessKey(a)+1s"…
other animations: <animate begin="otherAnimation.begin-2.5s"… (and this is generally a much better choice than event timing when you want to keep animations in sync. Although you can write begin="otherAnimation.beginEvent" you may get surprising results when a seek is performed. Use begin="otherAnimation.begin" instead.)
repeat iterations: <animate begin="otherAnimation.repeat(2)+25ms"…
plain old time offsets: <animate begin="12.3h"…
all of the above! <animate begin="rect.click; accessKey(a)+1s; otherAnimation.begin-2.5s; otherAnimation.repeat(2)+25ms; 12.3s"…

SMIL and script are friends

There are a lot of advantages to using SMIL over script (it’s generally easier for a start!) but sometimes it can’t do everything you need. In those cases you can use both together!

SMIL → Script: To synchronise script with SMIL, just listen for the relevant time events generated when animations start (beginEvent), repeat (repeatEvent), and stop (endEvent). If you need a bit more context you can always query the animation’s start time and current time too.

Script → SMIL: To go the other direction, that is, to kick-start SMIL from script, just use the appropriate time control interfaces beginElement, endElement on the target animation, or seek and pause all animations in the <svg> block as a whole with setCurrentTime, pauseAnimations and friends.

SMIL outside the box

While we’re only supporting SMIL for SVG content that doesn’t mean it’s entirely off limits to your HTML content. Not only can we tie SMIL to HTML events as above but we can also apply various SVG features to HTML, and these places can play host to a bit of declarative animation too.

Woah woah woah! Example of a SMIL-animated SVG filter applied to HTML content. (Hint: try selecting the text)

What’s left?

Still, there are a few features missing in our SMIL implementation that are yet to come. I’m maintaining a somewhat detailed summary, but in short we’re missing:

Mexican waves — There are still a few SVG data types that can’t be animated yet. Paths are very much on the way, but lists of points are yet to come. That means all your squiggling, warping, barrelling, twisting, waving lines and stars will have to wait a little longer to mesmerise the world. Hopefully most of this will be done in time for Firefox 4.
Hyperlinking — The ability to trigger animations from a hyperlink is also yet to come but will probably not make it’s debut until after Firefox 4.0.

What’s not on the radar?

There are also a couple of features that are neither done, nor likely to get done in the foreseeable future. These are:

<animateColor> — So long as <animate> honours color-interpolation then <animateColor> isn’t necessary and only complicates the Web. See bug 436296. We recommend using <animate> instead. (This issue was recently discussed on www-svg.)
Wallclock timing — That is, the ability to set up an animation to begin at 2011-01-01T00:00:00+09:00. Real uses cases for wallclock timing were discussed on www-smil earlier in the year but it seems the syntax provided by SMIL, at least as far as it is used in SVG, is insufficient for these use cases. For the time being, we’d rather not clutter the Web platform by implementing something half-baked. For most use cases, it should be possible to provide this sort of functionality by adding a sprinkling of script to your SMIL.

UPDATE: I just noticed Robert Longson (who’s played a big part in us getting to this point) beat me to reporting much of this news, so for more details on where we’re up to see his post too.

Synchronising SMIL

Wed, 13 Jan 2010 00:00:00 GMT

Our SMIL implementation passed another little milestone yesterday when we landed syncbase timing. We’ve still got a long way to go but this was always going to be the hardest feature for the timing model.

I thought I’d just take this chance to acknowledge some of the people who’ve helped get us here. Particularly Daniel Holbert for his incredible helpfulness and for just being awesome at everything he does; Jonathan Watt for all his help with SMIL recently and for always looking out for me; Robert O’Callahan for his oversight, invaluable input, and support technical and personal; and Chris Double for keeping SMIL moving in the early days.

Also, as alumni of the University of Technology, Sydney (UTS) I used their library a number of times last year as a kind of virtual office. It’s a great library where they really try to help the students, allow you to eat at your desk, and even let you pay for your fines with canned food that is then given to an Australian charity group. Thanks UTS!

Finally, thanks to Solutions First, specialists in Open Source and Linux solutions and a whole lot more, and who have generously provided me with this web space for longer than I can remember. Cheers guys!

Beached as bro

Thu, 22 Jan 2009 00:00:00 GMT

One last post as I race out the door. It appears my attempt to quash the enthusiasm surrounding SMIL doesn’t seem to have worked. It seems like some people are genuinely interested in SMIL and not just for Acid3!

This weeks developments:

<animateTransform>
SVGAnimationElement interface
Fixes to better synchronise the DOM state with the animation state
A couple of other small fixes

Today I ran up against some questions about zero-length intervals so if you have any insights there I’d be glad to hear from you! I’ve adjusted our timing model based on what I think SMIL intends.

That brings to an end my stint with the NZ office. I had a great time with the fellas here—cheers guys! Or as some people here say, “chur!”

Wet blanket

Sat, 17 Jan 2009 00:00:00 GMT

Well, SMIL has finally landed on mozilla-central! It’s been a long road since I first started out on this project nearly 5 years ago but we’ve finally reached the first milestone! Thank you very much to many who have helped or even just offered encouraging comments but thank you particularly to Daniel Holbert, Robert O’Callahan, Chris Double, and Tim Rowley for their massive contributions. It’s been a team job all the way.

But althought we’ve come a long way I want to emphasise that we still have a long way to go. I’ve updated the status page to give you an idea of the features still remaining to be implemented. In particular, integration with SVG and CSS is a massive task (although it makes up only two rows of the chart) and by far the bulk of animation demos and tests won’t work without this. Also, syncbase timing is a big job.

The good news is <animateTransform> is in the pipeline (ready for review any day now) and for maybe the first time ever, there’s a little bit of momentum behind SMIL.

ただ今！

Thu, 01 Jan 2009 00:00:00 GMT

Yay, back to SMIL! This is just a brief update to let you know about the state of SMIL in Mozilla!

Here’s the low-context summary:

Daniel Holbert has been taking on this work and pushing it along steadily (thanks a million Daniel!!)
I’ve joined the Auckland office for my summer break (from December to the end of January) to work full-time on SMIL.
A (very) basic patch is nearly ready to land after it undergoes some final review and rework. After that SMIL should be on the trunk but disabled by default. I’ve updated the status page to reflect the features of this patch.
A proper implementation of <animateTransform> is also ready but needs review. I’ve written up (in painfully boring detail) some spec issues I encountered regarding <animateTransform>.

Next on the agenda I hope to be working on syncbase timing.

Thanks again for all your support and Happy New Year! Godt nytår! あけましておめでとうございます！新年もよろしくお願いいたします！

Farvel

Thu, 05 Apr 2007 00:00:00 GMT

You’ve probably worked it out, but I’m no longer working on SMIL at the moment. tor has very kindly helped out and has been doing some work on this but it will not make it for Firefox 3.

From now on, if you want to track the progress of SMIL in Mozilla I recommend:

As for me, I’m travelling around Asia, so unless someone can sponsor me to work on this in Asia I can’t really offer much time to the project.

Thank you to everyone who helped me to get SMIL this far. I hope that someone else can pick it up.

SMIL

Tue, 25 Jul 2006 00:00:00 GMT

Wow, what a heading! Some would call it lack of imagination, I like to think of it as artistic restraint — it’s just too easy to make puns with “SMILe”!

Progress on SMIL continues, albeit in slow motion. Just a really quick note for those one or two people who want to know what’s going on:

Not only does it compile it now runs too!
All my visual tests pass again
All my unit tests pass again
My early attempt at <animateTransform> is up and running again and seems to work.

I need to do some tidying up before it’s ready for review. Most of all:

Some deCOMtamination
Making better use of Moz utilities (string iterators, nsTArray etc.)
Removing redundant code
Fixing the scope of the animation controller

It’s hard to give a timeframe for this — it depends a bit on my workload with other things (Japanese, Bible college, surfing, life – not to mention my day job). Hopefully a month?

As for new feature work, I’ll have to re-negotiate with work before I can do that. So I’d really appreciate any help at all. The SVG guys have already been incredibly helpful and have begun preparing the SVG code so it can be animated more efficiently. Thanks guys!

SMIL compiles again

Mon, 12 Jun 2006 00:00:00 GMT

Today is the Queen’s birthday public holiday in Australia. In Sydney the weather is freezing and the surf is huge. All this means I’ve finally got my SMIL work to compile against the trunk again. Now to get it working again!

Thanks to the many people who have left very encouraging comments in the meantime. I’ll do my best to get this up and running as soon as possible. One very experienced developer has suggested they might be able to contribute which would really help bring this to reality.

I’ll wait until it’s actually working (and I’ve done some more deCOMtamination) before posting another patch. But thanks for being patient with me!

SMIL Animation in Mozilla report

Mon, 09 Jan 2006 00:00:00 GMT

I’ve published the report I wrote for regarding my project implementing SMIL Animation in Mozilla. At 147 pages and ~700kb it’s fairly detailed but I hope it will be of interest to some. Thanks to all who helped. Here it is:

https://birtles.blog/smil/report/report.pdf

Also, I was invited to represent the Software Engineering faculty by presenting my project at an Engineering project competition run by my university from which I picked up the prize for innovation which means I got paid for working on Mozilla! Stoked!

Finally, I’m taking a bit of a break from this work at the moment. I nearly went crazy finishing the uni project last year and right now it’s summer so I’m getting back into surfing, swimming, running, riding, squash and maybe even some karate! Maybe in a month or two I’ll be ready to look at the code again and I’ll try to tidy up the SMIL Animation code.

SMIL Animation patch

Sat, 05 Nov 2005 00:00:00 GMT

G’day! I’ve produced a new patch to provide SMIL Animation for SVG. Since last time I’ve added:

keySplines
keyTimes
accumulate
restart
min, max
ElementTimeControl DOM interface

I’ve added a status page showing just what’s been implemented and I’ve also updated the test cases.

This represents all the features I intend to implement this year although I may attempt a draft implementation of <animateTransform> for demonstration purposes. The next obvious thing to implement is syncbase timing although none of this will be of much use until we determine how to represent animated values in SVG and CSS!

For now I’ll be working on a report of my attempts and documenting some difficulties I’ve come across with SMIL.

Here are the patches:

smil-anim-2005-11-03-2024.patch
smil-anim-2005-11-03-2024-wo-configure.patch – The same but without the patch to configure—this is much smaller and more likely to work but requires you have autoconf-2.13.

I’ve (hopefully) fixed the paths in the patch so you should be able to apply it from mozilla with:

$ patch -p0 smil-anim-2005-11-05-1539.patch

Known issues:

An SVG image referenced via <object> will remain paused when returning to the page using the back button if the page is in the bfcache. This is because page transition events are not received. If anyone can help me with this I’d really appreciate it!
An SVG document added entirely via script won’t be animated. (See this test case.)

SMIL work: performance and integration

Sun, 16 Oct 2005 00:00:00 GMT

Here’s an updated patch with my latest changes including:

Optimised performance—a lot of unnecessary rendering has been filtered out and the profiling I was able to perform suggests this has made a significant difference, especially when the animation is frozen.
Animation now pauses and resets when the page is cached in the bfcache.
Better thread safety.
Animation now starts at the same time as the SVGLoad event (although this has meant a regression in the deferred tree test case).
Support for pausing via the DOM (see this test case).
Animation is now disabled if the image.animation_mode pref is set to ‘none’ (although I’m not sure if this is a good idea).
Fixed the to-animation prioritisation issue Olaf pointed out.
The frozen to animation test case now produces the correct result in all cases (although there are still unresolved issues with regard to seeking).

The latest patch is at: smil-anim-2005-10-16-1736.patch.

I’ve also put up my configure script as some people have had trouble regenerating the script from configure.in.

You might like to read Twitwi’s comment for some help on applying the patch.

Fill modes (nearly) there

Tue, 04 Oct 2005 00:00:00 GMT

Aided by flat surf but hampered by perfect weather I’ve spent most of the last week tidying up my code and updating the documentation on the wiki. The latest patch is hopefully much better, or at least not quite as hideous as it was in some parts.

Fill modes are now implemented except for one edge case of a frozen to animation that is stopped in the middle of the simple duration. It’s the third case in this test.

I’m putting feature work on hold for a while to focus on a few obvious optimisations such as suspending the timer when it’s not needed.

Here’s the latest patch: smil-anim-2005-10-04-2138.patch

Additive animation

Wed, 21 Sep 2005 00:00:00 GMT

Additive animation appears to be working. The test case I mentioned in the last post works even the nasty tree re-ordering cases. I’ve also extended the additive test case a little to test a bit more of the dynamic behaviour.

In implementing this I’ve tightened up the implementation of the <animate> element somewhat and wrapped each sample in a pair of calls to suspendRedraw and unsuspendRedraw.

I’m putting feature work on hold while I tidy up the code and update the documentation on the wiki.

The remaining features I hope to add this year are:

fill modes
restart
accumulate
min and max
keyTimes
keySplines

I may have a chance to look at adding support for specifying target elements via xlink:href and perhaps CSS values and relative values but I’m not sure. I’ll be focussing more on thread safety, performance, optimisations, DOM interfaces etc.

The latest patch: smil-anim-2005-09-21-2129.patch

Additive animation nearly done

Wed, 14 Sep 2005 00:00:00 GMT

I’ve done most of the work required for additive animation. The remaining part is to correctly order animations in the animation sandwich after changes to the document structure. So in this test case the last two squares don’t behave as they should. (However, ASV fails in the same way.)

Also, I’ve implemented from/to/by animation and animation using a list of values.

I’ve done a lot of tidying up too but the nsSVG(Animated)Length situation is still a nightmare.

By the end of September I hope to have:

cumulative animation, and
fill modes

and maybe:

restart, and
min and max

After that I’ll hopefully add keyTimes and keySplines and calcMode (at least for spline, linear and discrete) but mostly I’ll focus on integration, performance, testing etc. Something should be ready by December.

Here’s the patch for my latest changes: smil-anim-2005-09-14-2043.patch (about 230k).

I haven’t included configure in the diff so you’ll need to regenerate it from configure.in.

Under Cygwin the following works for me:

$ autoconf-2.13 configure.in > configure

Compositing underway

Wed, 07 Sep 2005 00:00:00 GMT

I’ve begun work on implementing compositing. This will take some time. Also I’m no longer sure I’ll be able to deliver syncbase timing this year as instead I may need to focus on integration issues, performance, documentation, thread-safety and so on. Hopefully all this will mean it has a better chance of getting checked in sooner though.

Repeating

Sun, 04 Sep 2005 00:00:00 GMT

I’ve added a basic implementation of repeating. This doesn’t include accumulating or repeat-based timing but this test and a whole lot of other tests seem to work. Also, I’ve added a couple more tests.

I’ve made up a patch of these latest changes and managed to remove the dependency on the changes in the wings for bug 301628 so the patch is a little smaller than last time but still 400k. Most of that is just changes to configure.

Here’s the patch again: smil-anim-2005-09-04-1725.patch

The same instructions and caveats apply as last time except I haven’t tested this patch on Linux like I did the last one.

Intervals

Sat, 03 Sep 2005 00:00:00 GMT

I’ve implemented handling for multiple begin and end values including calculating the active duration, selecting the correct interval etc.

Interestingly Adobe SVG Viewer (6 beta) seems to do things a little differently to what I’d expect based on the SMIL Animation spec. There are a few cases but probably the most important one is when you specify a list of begin times and a list of end times but the latest begin time is after the latest end time. The pseudocode in the spec says this is an error—it’s ok if the end time is not set as it will default to indefinite—but if it is set, then it needs to provide a valid end value for the intervals defined by the begin attribute. The pseudocode isn’t authoritative but I couldn’t find anywhere else where this is spelled out in the spec.

(Content authors can always work around this by adding indefinite to their end specifications, e.g. end="...; indefinite".)

New patch

Mon, 29 Aug 2005 00:00:00 GMT

I thought I’d post this patch which contains my work so far.

This patch contains most of the classes I outlined in my design. It will do very simple animation of lengths using a very limited subset of timing specifiers. Please don’t look at the code in nsSVGLength and nsSVGAnimatedLength. It’s just a hack to get it to work while I wait to hear from others how this should be done in the end. Probably the implementation I included in the previous patch was better.

I wouldn’t really recommend applying it because it also contain’s tor’s patch for bug 301628 but along the way I’ve had to merge it with recent <textPath> and events checkins and I’ve possibly broken something along the way. So you’re better off just to leave it until bug 301628 gets checked-in and I re-create the patch.

If you’re feeling brave however, you’ll probably want to apply it from /mozilla and run: patch -p 3 -u -N < smil-anim-2005-08-29-1947.patch (I’ll fix the absolute paths someday so you don’t need -p 3). You’ll need to add --enable-smil to your .mozconfig and then do a full build.

If you want to try just doing a minimal re-build, the following might work:

mozilla> ./configure (to re-create autoconf.mk, although this will have the effect of touching all the Makefiles meaning that when you run make libs later on it will take a while. You might want to just try and patch up autoconf.mk yourself).
mozilla/dom/public> make (to export the headers and make the IDL definitions)
mozilla/content/smil/public> make (to export the headers required by nsPresContext.h
mozilla/layout/base> make (to update nsPresContext)
mozilla/dom/src/base> make
mozilla/dom> make (not sure if this is necessary)
mozilla/content/smil> make
mozilla/content/svg/content/src> make
mozilla/layout/svg/base/src> make
mozilla/layout> make libs

Like I said, you’re probably better off doing a full build, I’m really not sure that the above approach will work. I’ve tried the patch on Windows and Linux and it works for these test cases.

Here’s the patch again: smil-anim-2005-08-29-1947.patch. It’s about 500k.

Iteration one

Sat, 13 Aug 2005 00:00:00 GMT

Just a quick update in case anyone someone actually reads this page. I’ve implemented most of what I intended to cover in the first iteration and now some very basic animations work. If anyone is at all interested I’ll post a patch, but otherwise I’ll leave it for a while.

Draft design

Tue, 19 Jul 2005 00:00:00 GMT

I’ve added a very draft design to the Mozilla wiki page. If you have any comments, please add them to the wiki page! Thanks to Patrick L. Schmitz for allowing me to use some of the ideas he proposed in his Batik Timing and Animation Support design.

Basic prototype

Wed, 18 May 2005 00:00:00 GMT

I’ve put together a very basic prototype with some of the ideas discussed so far. Please be aware that it’s very limited. The idea was just to help with discussion and to help me try to understand some of the suggestions. So it’s not a serious proposal. I was working on something a bit more solid but I threw it away after I read some of the suggestions on usenet/IRC/wiki.

So there are about a bzillion things wrong with the prototype but I think it should still aid discussion.

I tried to implement Alex’s suggestion for the anim/base value split. It mostly works but produces a lot of assertions and doesn’t function correctly via the DOM (not sure if it’s because a modified QueryInterface is needed or because of vtable magic involved in XPConnect). I won’t look at this too much more because there seem to be a lot of (much more capable) people interested in this. Scooter and I agreed that he’d look at this and I’d look at the timegraph stuff.

This experiment only animates the x and y attributes of elements and only for very simple animations. Basically it runs this test case and probably nothing else.

Here it is: Animation experimenting patch (to be applied from /mozilla, I ran patch -p 3 -u -N < anim-proto-1.patch).

Please email me if you have any comments—or better yet email everyone or write something on the wiki.