What can SVG learn from Flash?

Regular readers of my blog know that I also worked on the Macromedia Flash Professional authoring tool and the Adobe Flash Player for many years. I learned a great deal about the design of ubiquitous platforms, and the limitations of single-vendor implementations. At a recent meeting with the W3C SVG working group, I shared some of my thoughts on how Flash was able to reach critical mass across the Web, and how SVG can leverage those lessons for the future.

Basically, it boils down to 3 principles:
1. Flash offered expressive design-fidelity across all user agents.
2. Flash authoring was superior to SVG authoring tools for producing content that adheres to principle # 1.
3. Most Flash content is self-contained and atomic in a packaged file format that helped preserve design-fidelity in # 1.

I shared some feedback regarding what I hear from Firefox users about SVG. I also shared what I never hear from Firefox users: “We need more SVG features.”

As the working group ponders new SVG specifications for review, the main gripe I hear from users is the lack of interoperability for the current feature set. That is, I don’t get requests for a new DOM or fancy gradient meshes, I get bugs about basic rendering differences across browsers. As a result, I’ve directed our SVG investment towards these paper cuts that make authors distrust SVG for complex designs. I can see why it’s more tempting to focus on new feature specifications, but adoption is hampered by the legacy of interoperability (or lack thereof.) I’d like to see the group organize around fixing these bugs across all browsers in a coordinated fashion, eg. in a hackathon or bug bash at a future multi-browser face-to-face meeting.

I also talked about how SVG could be a very expressive authoring source format for a modern implementation that is more focused on pixel-fidelity. Unfortunately, I didn’t get a lot of support for that idea from other browser vendors, as the desire to compete for the best implementation seemed to outweigh the benefits of dependable runtime characteristics. I’m really surprised that SVG hasn’t stepped in to replace Flash for more use cases, and I’m quite certain that the 3 principles I mentioned above are the reason why. I do hope that authoring tool vendors step in and help drive the state of the art here. It’s one thing for browser vendors to offer competing implementations, but the lack of strong authoring systems makes it hard to define what it means to be correct.

I spoke with a few people about how the packaged SWF format was an advantage for Flash because it was easy to have this content move across the internet in a viral fashion without losing any of the assets. Flash games, for example, are commonly hosted on multiple servers (often unknown to the original publisher) and still retain all the graphics and logic within the SWF file. The W3C application package proposal is something we could implement as a format that lets HTML/SVG content traverse networks intact. It’s not hard for such HTML/SVG applications to be made up of hundreds of individual assets that are easy to lose track of. Having a packaged format with clear semantics and security rules (eg. iframe in a zip) could be a really good feature for the modern web.

What else are we missing for SVG to gain critical mass? Post a reply below or find me on twitter!

An imposter among you

I’m blessed to live and work with the smartest people I know. I’ve been at it for many years. In fact, I’m quite certain some of them are among the smartest people on the planet. I cherish the knowledge and support they freely share yet I frequently wonder why they tolerate me in their midst.  I’ve experienced Imposter Syndrome from an early age, and I’m still driven to tears when I think about it. Why do I deserve to be in the midst of the greatness I’ve surrounded myself with? It’s worse when I get credit, as I feel like I’ll surely be figured out as the fraud now that everyone’s looking.

I’ll just leave this here as I suspect there are many others around me who have this affliction. If nothing else, I’m right there with you—for real.

FirefoxOS Dev Quick Start

B2G_dev_envI’m posting the steps I took to create the FirefoxOS dev environment for the Flame device. We use the Flame as our reference device on the Platform Rendering team. I had to re-do this recently on a new computer and I figure this might help others in the same boat. These steps assume you can already build the desktop version of Firefox on your computer.

  1. Get ADB
  2. Turn on ADB debugging on your device.
  3. Download the latest base image (v18D_nightly.zip at the time of this writing.)
  4. Unzip the base image archive and run the flash.sh script to update your phone to the latest base image. You’ll need to re-enable ADB debugging after this step.
  5. Clone the B2G repository and follow the prerequisite steps for local builds.
    Note: the device we target for the config.sh step is flame-kk (not the older flame device.)
  6. Get a coffee and wait for the long source download.
  7. Run ./build.sh in the B2G source directory to build.
  8. Run ./flash.sh in the B2G source directory to put your new build on to your phone.

NYC Indie Web Camp Weekend

Indie Web Camp logo

I’m at the NYC Indie Web Camp this weekend at the beautiful New York Times office in Manhattan. Tantek Çelik joined my team at Mozilla about six months ago to work on various Web Standards initiatives that we push forward on the Firefox Platform team. Although our bread and butter is Web Platform Rendering, Tantek is also passionate about advancing user-sovereignty to enable authorship outside of proprietary corporate silos (see POSSE.) I tagged along with him this weekend to learn more.

The Indie Web movement is in the midst of an exciting creative stage. There are people hacking on the building blocks and other folks dogfooding the code. At this point, I’m in the latter camp, looking to solve 2 problems that I have with my 3 web sites:

  • junglecode.net – this blog for stuff about various things that I do with the geeks I hang out with (dare I say, my network.)
  • junglecode.com – a site to catalog the products I make that happen to also pay my bills.
  • junglecode.org – a site to describe non-profit activities (music and other hobbies) that I engage in. I haven’t found much time to write about this stuff lately.

Problem 1: When I first decided to split my online life into 3 top-level domains, I thought it would help organize my efforts into those 3 top-level buckets. It turns out that, in practice, I’ve just split my online persona into 3 sites in various states of intermittent activity. I’d like to try and organize the 3 buckets so that I can post content in any category (org,com,net) and have the posts go to the right site, while still aggregating on this blog. Fortunately, I met Jeremy Zilar this weekend and he works on the 200+ Blogs for The New York Times. My 3 site problem dwarfs in comparison to what the Times has to scale. I’m loving all the brainstorming going on this weekend.

Problem 2: I’d like to make a few bucks on these sites without the usual ad-generated methods. It’s not that I’m above receiving advertising revenue, I just think my audience is a very narrow slice of the geek population that is also very good at not clicking on ads. I would instead like to sell them my stuff. I might sell a single sweatshirt or an extra torque wrench that I happen to have lying around. I’d like to do this in an Indie Web way as I am, in effect, inviting you to a virtual private garage sale (VPGS?) I’m looking into various Web Payments solutions to do this.

I’ve added the IndieWeb plug-in to my WordPress sites so I can send and receive various notifications over IndieWeb protocols like WebMention. I expect to hack on various bits of the solution to these 2 problems as I learn more. I’ll share the code here, in case others may find it helpful.

I’m also interested in extending the Web Platform to enable more Indie Web capabilities at the core of the Open Web stack. It’s really exciting and fun to work on this stuff. What else can we do to make it easier for user-authors to raise their independent voice?

Platform Rendering Work Weeks in Taipei

The Platform Rendering team is back in Taiwan this month. This time, we’ve split the team across 3 work weeks (Media, Layout, and Graphics.) This lets us focus on the issues specific to each team but still allow for free time to hack and socialize.

Here’s the week’s agenda for the Platform Media team:

10th March
11th March
12th March
13th March
14th March
10:00 – 10:55 Introduction / Lightning talks
Anthony Jones
Platform Decoder Modules, MP4
Chris Pearce
Media Stream Graph Refactoring
Paul Adenot
Stingray – Introduction and demo of TV
Content enablement session
Chris / Ide
11:00 – 11:55 Beginner’s guide to <video> code
Chris Pearce
“MediaCodec for playback”
Bruce Sun
“Video Codec Resource
Blake Wu
“Adjust priority/nice value for media playback threads”
Star Cheng
JW Wang
Stingray – Introduction of hardware
Shumway (Mozilla Flash Player)
Jet Villegas
13:00 – 13:55
14:00 – 14:55 Process reflection
Anthony Jones
Async Decoder Changes
Chris Pearce
Tim Terriberry
Stringray – AV related achetecture
TaskTracer Demo
Shelly Lin
4th floor, Mozspace
15:00 – 15:55 Pre-Discussion about Panasonic TV
Shelly Lin
New Recording Features
John Lin
Video Recording
Randy Lin
Seccomp etc
Paul Terriault
Stringray – GFX related achetecture
Hell Kitty
Chris Pearce
16:00 : 16:55 Manager Session
Anthony Jones
Chaos mode debugging and rr
Robert O’Callahan
Media Source Extensions
Chris Double
Our Proposals for Panasonic TV
Shelly Lin
Chris Pearce
19:00 - Team dinner @ Din-Tai-Fung, Taipei 101

Here’s the week’s agenda for the Platform Layout team:

Monday Tuesday Wednesday Thursday Friday
9am SVG buffered-rendering (small group) Elephant Mountain walk
10am lightning talks (jet) Shipping CSS Variables (heycam) Vertical Text (smontagu) OMTA (birtles)
11am position:sticky (kip) CSS scroll snapping (roc) Platform Priorities (jet) CSS flexbox (dholbert)
Noon Lunch Lunch Lunch Lunch Lunch
1pm free vsync/refresh driver Platform Priorities (jet)
2pm Intro to Layout (roc/dbaron) rr & chaos (roc) use of performance tools demo (dbaron) SVG performance work (small group requested by Taiwan based employees) (jwatt) wifi display demo (kenchang)
3pm Selection (roc) competitive & standards landscape (dbaron) XPCOM and String classes (dbaron) (hopefully 4th floor) B2G Layout Discussion (jet)
4pm free Moz2D (small group) Platform Priorities (jet) tbd
5pm Restyle performance patch testing (heycam,vilin,cjku) tbd
6pm Team Dinner tbd

This morning, the Layout team decided to take a walk up to Elephant Mountain near the office. A walk in the park with the Layout team has equal parts of viewing the scenery, and discussing rendering issues for Chinese text (both horizontal and vertical!) It was quite fun.


I’ll post the Platform Graphics team agenda in two weeks after they’re in Taiwan for their work week. Apologies for the use of acronyms and unfamiliar jargon as the Rendering teams often use these terms to describe complex features. Send me a comment if I can help clarify anything.

The Taiwan teams have been very gracious and welcoming as always. See you all again soon!

Planet Mozilla Rocks!

My last two posts didn’t make it on to planet.mozilla.org due to a recent junglecode server move. I asked Robert Accettura to update the entries in the planet database so that server-side redirects aren’t necessary. This post is just testing those changes. It’s also a plug for Planet Mozilla, a most excellent public resource for the Mozilla community.

If you missed these two posts on planet, here you go:
Software Project Estimates: Go Fly a Kite!
Mozilla Platform Rendering in Asia

Software Project Estimates: Go Fly a Kite!

Building Open Source software presents challenges to engineers and managers that differ greatly from proprietary systems. Open Source doesn’t eliminate the need for proper estimates and the predictability of costs that accurate estimates bring. Open Specifications like the W3C web standards add additional complexity to the estimation process. How are you supposed to know how long a project will take, when the specifications are frequently modified by authors and editors who aren’t under your control?

An estimation method that I often use at Mozilla is based on the Niagara Falls Suspension Bridge project. The Niagara Falls Suspension Bridge was the world’s first working railway suspension bridge. It was over 800 feet long, which was a length that was difficult to accurately measure back in 1847, before bridge construction started. The rapid waters and 225-foot high shear cliffs made a direct crossing impossible. The bridge construction must begin by stretching the first wire across the violent stream.

The Niagara Falls Bridge project shares many similarities with a complex software project: multiple stakeholders, unknown scope, dangerous obstacles and difficult terrain. How do you start when you can’t see how far you need to go? In January 1848, fifteen-year-old Homan Walsh flew a kite from the Canadian side of the river and was able to crash the kite into a tree on the New York side. The kite string was used to pull a thicker line back to Canada, then a rope, then metal wire, and construction progressed until a temporary suspension bridge could be built.

The truth is that Homan had a very difficult time getting the kite to fly to the other side! Weather and other unexpected problems left him stranded on the Canadian side for eight days and several failed attempts. Despite the difficulties, his initial kite was essential to the larger goal. When I first talk to engineers about a new software project, I often get estimates that sound like “two or three months, if we’re lucky.” When I hear that, I ask them to go fly a kite.

A “Kite” is just enough code to learn just enough new information about the project so that intelligent estimates can be made. I should note that this code can be very flimsy (like a kite) but functional enough to illuminate the unknown. It’s important that the engineer understands that we will not be shipping the kite! The goal with the kite exercise is to come with estimates that are in multiple pieces of work that each span days or weeks. Estimates that are still measured in weeks may require more kites to break down into days.

Getting that first kite across the gorge can be a very exhilarating experience, and may be just enough motivation to continue the difficult path forward. As an example, a big bridge project for us is Vertical Text and the first kite looked like this. A second kite looked like that.

Mozilla Platform Rendering in Asia

I’ve spent the last 3 weeks traveling in Asia for Mozilla and W3C business. On May 20 to 24, my team was in Taiwan for a series of meetings on Platform Rendering (Layout, Graphics, and Media.) It’s always an enlightening experience for me when I spend time with such a talented group of people:

The Mozilla Firefox Platform Rendering Team on location in Taiwan.

Going to Taiwan was a very special event. The local Taiwan office was awesome, and the local staff was very wonderful, taking great care of us while we were there. Beautiful and fast rendering requires a deep understanding of the underlying hardware, and if you’re serious about hardware, you eventually have to go to Taiwan. Meeting and working with the local Taiwan team was great. They’re so smart, and eager to learn about the Firefox Platform. We spent a lot of time getting them caught up on Rendering infrastructure, and various Mozilla-specific topics (Open Source, Open Specs, Code Review, etc.)

I’ve pasted the calendar we followed for the week, below. The links point to raw notes from the sessions (where available.) I apologize for the lack of context in some notes, as they’re meant for the attendees. They’re in this blog post to give you an idea of what the Rendering Team does when we get together in a large group every few months.

Taiwan Rendering Sessions

Monday Tuesday Wednesday Thursday Friday
9am Lightning talks Graphics: SkiaGL Canvas (snorp) Graphics:WebGL (Vlad) Layout/Media: Implementing WebVTT CSS features (rillian/dbaron)
10am Free Graphics: SkiaGL Content (Jeff M.)
Layout: Intro to Style System (dbaron)
Graphics: WebGL (Vlad)
Media: libCubeb/Audio Latency (Kinetik)
Platform:Cycle Collection 101 (khuey) Graphics: Timing Attacks (bjacob)
Layout:Layout Documentation – Conf Room B (jwir3)Media: ???
11am Free Graphics: Async Canvas (Vlad, snorp)
Layout: Intro to Dynamic Changes in Layout (dbaron)
Graphics: WebGL (Vlad)
Media: Web Audio (padenot)
Layout: CSS Masking
Media: Fixing MediaStreamGraph video propagation (roc)
Graphics: Imagelib (joe)
Other: WebGL (Vlad)
Layout: ???
Media: ???
Noon Lunch Lunch Lunch Lunch Lunch
1pm Graphics: OMT-Compositing (Nical – “D”)
Layout: Layout 101 (Elika – “C”)
Layout: APZC Graphics: Moz2D/Player2D (Bas) Layout:Layout fuzzer status (multicol security bugs, etc.) – Conf Rm. A Graphics:Intro to Gecko Graphics (mwoodrow)
Layout: ???
Media: ???
2pm Graphics: Layers and buffers (bjacob) Layout:Web Animations (birtles)
Media: MediaSource Extensions (kinetik)
Graphics: OMT Canvas Layout: Web Animations contd. (birtles) Graphics: ???
Layout: Standardization and Mozilla (dbaron/abr) «IETF Slides»
Media: ???
3pm Graphics: Gralloc
Layout:CSS Variables / CSS Cascade (heycam, dbaron – “C”)
Layout: CSS Graphics Graphics: OMT Animation
Layout: (see graphics)
Media: Media Decoding (cdouble) OMX Codec (sotaro)
Graphics: B2G/Android Graphics Testing
Layout:CSS Writing Modes – Vertical Text (fantasai)
Graphics: ???
Layout:Layout Performance (jet)
Media: ???
4pm Media: WebVTT/TextTrack (rillian) The Mozilla Way (roc) Graphics: CSS Filters
Layout:CSS3 Fonts
Code Reviews – The Mozilla Way (roc) Work Week Wrap-up (jet)