For the past three-and-a-half years of my life, I have devoted a large portion of my time and creativity to the creature known as SVG. Whether that was a good choice or not, I do not know. But here I am. However, I'm not really sure where I'm going to go next. And I'm even less sure where SVG is going next. So I sat down to write out my thoughts about the future of SVG, and instead wrote about how I came to be so tangled up with it.
It started with data visualization. I was looking for a niche skill that I could use to distinguish myself as a journalist. The previous year had been particularly bad for me health-wise, and I found that writing was particularly difficult when I was tired. I was enjoying photography and photo-editing, but photojournalism requires the ability to hop in a car and head to where the story is, when the story is. I don't even drive. I needed a job that I could work remotely, on a flexible schedule.
But I have a background in computer science, which most journalism grads can't claim. (I have a B.Sc. in Bioinformatics, and at the time I was procrastinating on finishing my Master of Journalism thesis.) And my goal with journalism was always to improve the communication of technical and scientific data in the news. I loved the idea of using our new communication media to improve the understanding of data and scientific evidence. Data visualization was just right for me.
I started learning D3.js, after a little research convinced me it had the best mix of flexibility and convenience. I read Mike Bostock's and Scott Murray's tutorials. Eventually, I started stalking the d3 tag on StackOverflow: not asking questions, but answering them. I'd see a problem that I thought should be easy to answer, and I worked on it until I could.
Of course, you can't go far with D3.js without learning something about the fundamental web technologies that it builds on: JavaScript, HTML, CSS, and SVG. Just when I was busy trying to figure out basic CSS layout, I came across the CSSOff challenge: recreate an over-designed Photoshop comp layout as a responsive, progressively enhanced website. The final submissions were submitted via CodePen. I wasn't ready to commit until I was sure I'd have something to submit, so I didn't sign up until the last minute. By then, it was too late for the "free Pro-account for the duration of the contest" offer, and I had to host all my images on a site which apparently no longer exists, but you can still sort-of get a feel of the design. I made heavy use of SVG clip-paths and filters to implement the graphical effects.
Now that I had the CodePen account, I started using it now and then. Eventually (aka the first half of 2014), I started creating detailed tutorial-style pens (this was before CodePen blog posts existed), explaining things like how quadratic Bézier curves are constructed.
(Aside: A moment of laughter for the note at the end of that tutorial, about how animations and cubic curve discussion are still "under construction".)
These tutorials somehow caught the eye of David Eisenberg, who was working on the Second Edition of SVG Essentials for O'Reilly Media. The First Edition had been published in 2002 and it was the reference book on SVG. I was commissioned to do a technical review.
I dove into the job a little too deep. Instead of just pointing out errors, I gave detailed comments suggesting new wording, or additional topics of dicussion (particularly regarding browser compatibility issues that I'd come across). When David started integrating my suggestions, and realizing how much of my words he was using verbatim, he had the decency to suggest that I'd be listed as a co-author, with a corresponding slice of the royalties.
But me being that type of person that I am, that only dragged me deeper. My name was going to be on the cover, now: I had skin in the game. I wanted this to be the book I was looking for when I was learning, and started working on some of those additional topics I'd felt were missing.
There were a few months of vigorous back-and-forth between the two of us that summer. The manuscript was considerably re-organized. My Master's thesis was delayed yet again. But by October, it was published! A classic O'Reilly animal-themed tech book, with "Amelia Bellamy-Royds" as an author.
Shortly thereafter, I got another offer from the editor at O'Reilly that we'd been working with. They had another manuscript, and it needed some help. The author (Kurt Cagle) had since moved on to other things, and wasn't able to finish it. Would I be interested in taking it on, polishing it up for publication?
I warned that I wouldn't take on any new commitments until the thesis was done (finally! in December 2014), but I'd read over what they had and make a proposal.
At that time, the book was title HTML 5 Graphics. But the manuscript was mostly about SVG, with one very out-of-date chapter on CSS 3, and nothing about HTML canvas. Kurt had been working on it for five years, and the tech had moved on from under him.
It was going to need a lot of work to get it ready for publication. It was going to need even more work to make it something that wasn't just a duplication of SVG Essentials.
In my opinion, the best and most unique aspects of Kurt's manuscript were that it focused on SVG integrated with other web technologies (HTML and CSS), and that it used complex, visually compelling examples. (As much as I love the simplicity of the examples in David's book, most of them aren't exactly eye candy.)
So I proposed working with that: a book about SVG on the web, with big full-colour illustrations to show off SVG's full potential. It would have lots of warnings about browser support, and practical workaround strategies. It would also be future-focused, with information about new proposals or experimental features. And it would emphasize how SVG compared and contrasted—and collaborated—with CSS in web design.
We re-named it Using SVG with CSS3 and HTML5. I was going to be working with Kurt's manuscript and examples, but fleshing them out and re-arranging them as need be.
I estimated it would take me 4–6 months working full time (or as close to full time as I was able). I arranged for four $1000 advances to be paid out as the manuscript was completed, in return for a reduced royalty rate. It wouldn't be a proper wage, but it would be enough to get by. I was doing a little bit of freelance technical writing, and I had some money in the bank that my grandfather had left me. And my husband had just got a job after most of the year on disability—it was out of town, but that was kind of a good thing at that point. The book would be a change of direction after the Master's thesis, as I decided what to do next.
I am notoriously bad at estimating project timelines. Six months later, I was slightly more than halfway through my planned topic list, and nearly twice my planned page count.
Some re-calculation was required. Clearly, my book couldn't be everything to everyone. The breaking point was when I spent a week and a half on the SVG text layout chapter, and realized at the end I had over 100 pages. That could be a book in itself. And it was.
After discussing with my editors, the decision was made to slice off some of the more in-depth sections of the manuscript into their own books. They would be aimed at developers who already work with SVG, but wanted to explore some of the lesser-known features.
Out of everything I'd already written, there were two topics that I decided had the potential to stand on their own: SVG text and SVG paint servers (patterns and gradients). Since they were already mostly written, they would be the focus. Get them published, then go back to the rest of the book. Using SVG would be streamlined for a more general audience
Summer 2015 was spent on the two books: SVG Colors, Patterns & Gradients came out in October, and SVG Text Layout was published in November. More beautiful O'Reilly animal books with my name on the cover! These ones even had colour figures. But I couldn't really celebrate, because I still had the longer book waiting to be finished.
And I'd now spent a year on the books, with very little income during that time. My husband and I had separated in September, and I was now carefully counting my budget every month. When O'Reilly sent me beautiful framed copies of the two books' covers, I cried thinking of how much they cost to frame and ship, and what else I could have done with that money. I still haven't even opened the second box.
Winter 2015–16 was not a good time for me. I'd been working full-tilt on the books, and needed a bit of a break. I'd also spent the previous year not avoiding any long-term plans until I could decide whether those plans would involve my husband or not, and now that that had been decided, there was a giant gaping "What next?" left in its wake. As we hit the dark days of winter here in the far Northern hemisphere, my chronic fatigue was taking over. One month break from the book turned into two, turned into three.
In spring 2016, I asked Dudley Storey to join the book as a co-editor, after an SVG book that he'd been writing (and I'd been tech-reviewing) for another publisher was cancelled. In addition to just having another pair of hands to lighten the load, I hoped that working with someone else would help keep me on track. But by that time, half my attention was barelling down a completely separate track.
Let's rewind a bit…
The books weren't the only way I was getting tangled up with SVG.
Over the time I had been working on the books, I had become involved with SVG standardization work. When I first decided that Using SVG would include forward-focused discussions of new proposals, I figured that I'd better find out what new proposals there were. I signed up to the W3C's www-svg mailing list to keep track of work on the highly-anticipated SVG 2 spec.
A month later (December 2014) a call went out for participants in a new task force on SVG Accessibility. Now, as I mentioned at the top, my interest in SVG comes from an interest in technical communication. SVG's accessibility issues are communication barriers. If SVG is going to be an effective communication medium, that needs to be fixed. I replied that I would be following their work, and would contribute in whatever unofficial capacity I could.
But of the people who were joining up in an official capacity, there weren't really that many with significant SVG knowledge. W3C staff rep (at the time) Doug Schepers asked if I'd like to join the task force officially, as a W3C Invited Expert.
I had gotten to know Doug earlier in 2014 from contributing to the Web Platform Docs project, a (now defunct) effort to create a browser-neutral reference for web developers. (It's defunct because MDN shifted to serve the purpose, and WPD wasn't able to shift fast enough to any purpose that distinguished it from MDN, so the other browser & tech companies eventually stopped funding it.) So he knew I had no problem jumping in and getting work done if I knew how to help.
A W3C "Task Force" can't invite its own experts, so I was assigned to the main SVG Working Group. I initially wasn't planning on doing any work for the main group, but I did start listening in to the weekly teleconferences. Even before joining the group officially, I had already been participating on the mailing list threads. And inevitably, when you bring up problems that need fixing—and especially if you start proposing solutions—people start asking you to do the work. Over the course of 2015, I slowly but steadily became a more active member in the group. I even got to meet some working group members in person, at the Libre Graphics meeting in Toronto in April 2015 and at the Graphical Web conference in Pittsburgh in September 2015.
Late 2015 to early 2016 was also not a good time for the SVG Working Group. The deadline for finishing SVG 2 kept on getting pushed back: from August 2015, to February 2016, to maybe mid-2016, or as soon as possible, anyway.
The problem was that there weren't a lot of people able and interested in doing the work. The two chairs, Cam McCormack and Erik Dahlström, had both switched jobs (Cam by choice, Erik by corporate layoff at Opera) and were no longer involved in SVG implementations. They were replaced as chair by Nikos Andronikos, but they were never properly replaced as active representatives of the Gecko and Blink SVG implementation teams. Adobe reps had also pulled back on their involvement in specs and in contributing to the open-source browsers. Apple hadn't been very active in SVG during the time I was there. At a February 2016 meeting, the Microsoft team were very openly frustrated with the delays.
I was not at the meeting in person (nobody had offered to fly me to Australia for a week), but I was participating by teleconference. It was also my first good week in months as far as energy levels go. I was feeling optimistic. When people started talking about a spring meeting, I piped up that I was going to be in the UK around the time of the April 2016 Libre Graphics Meeting outside of London. My mother had invited me for a week on a canal boat, and had reminded me of the conference. Up until that moment, I hadn't 100% decided I would go, but now it was fixed. I'd be there, and then we'd have an SVG 2 editor's meeting to tidy up the final spec issues.
By the time the April meeting arrived, the working group had lost almost all participation from the major browser representatives. There were some developers from the browser teams who were active in the issues, but most weren't the official working group reps. And they weren't editing the specs. Most of the edits were being done by Nikos (who works at Canon's research branch) and Tavmjong Bah (a stay-at-home dad and lead developer on the all-volunteer Inkscape team). And by me.
I was trying to keep my focus on the SVG Accessibility specs that I was lead editor for, but with so much work to do on SVG 2, I started agreeing to do it.
The book was completely on hold. Dudley had done some work, but I wasn't getting back to him. And it turns out that Dudley isn't any better than I am when it comes to self-motivating on major long-term projects without a lot of feedback. And I always had just one other thing left to do on SVG 2. I kept on thinking that if we just got SVG 2 finished, then the book would be much better for it. I'd actually know what was coming next for SVG, and could focus the book accordingly.
As we worked on the SVG 2 spec, however, it became clear that more work was required than we'd anticipated. The SVG spec is huge, and the SVG 2 work had been divided up between editors by chapter. It was up to each editor to raise issues with the group for their chapter. Edits were being made without review or coordination. And there were large sections of the spec that no one was worrying about because they hadn't been changed since SVG 1.1. But large sections of SVG 1.1 had never been fully implemented or properly tested.
Doug was getting pressure from W3C management to produce an SVG 2 spec. He and Nikos were trying to get the browser teams back involved, but at least one team (allegedly—I'm getting this all second-hand) told him that they wouldn't participate until the spec was published.
So Nikos and the unpaid volunteers (Tav and I) worked to patch up the most gaping holes in the leaky ship SVG, and SVG 2 was published, to minor fanfare, in September 2016.
SVG 2 is not a great spec. It might not even be a good spec. But I am at least convinced that it is a better spec than SVG 1.1. And because of the W3C's multi-level publishing structure, it could improve over time. This was only a Candidate Recommendation, a request for implementations. As feedback from implementers was received, it could be revised and re-published.
The next focus (which should have been a much earlier focus, in my opinion) was to create a proper test suite—a set of web pages that could be used to demonstrate whether software actually correctly implemented. Building that, and working on the implementations, would help identify the remaining problems with the spec.
But instead, when Doug and Nikos were finally able to get representatives from the major browsers on a teleconference, the feedback was that they really weren't sure about implementing a lot of this stuff. Could we kindly remove all the new features from the spec, so that only the fixes to old features remained?
I will write about the specific issues and problems with SVG standardization separately.
This post is personal. And personally, that was a kick in the guts. Tav reacted the same way. We'd both put in a lot of unpaid labour on this, with the only anticipated reward being the potential to actually make an impact.
Lots of changes could have been made, if issues had been raised sooner. Lots of changes had been made based on browser requests up until the browser reps stopped talking to us. I'd spent more than two weeks in June/July 2016 working on defining SVG use elements in terms of Shadow DOM, because the Blink team had half-implemented the change the year before, and I didn't want the spec to be published without it.
Now maybe we should have known better. Maybe we should have recognized no later than April 2016 that the SVG working group was in dire straits and a major intervention was required. But nobody had specifically told us that they had a problem with the spec. So it was easy to interpret the lack of involvement as a bad confluence of individual circumstances. Individual devs were too busy to contribute to the spec work, but if the spec was magically completed for them, then they'd be on board.
Meanwhile, the W3C's process meant that they needed their member companies to agree to a new charter for the SVG Working Group by January 2017, and that was looking less and less likely. Doug was leaving the W3C, and Nikos was going to be leaving because Canon didn't want to pay W3C dues any more (the dues are based on company size, and Canon is a big company with only a tangential interest in web standards). Tav wasn't going to take the lead with no support from browsers on the features he had been working so hard to spec and implement in Inkscape.
On the SVG Accessibility Task Force: one retirement, one layoff, and a variety of people with too many obligations means that nothing is happening there, either. I am still editor and chair pro tempore, but there's no point chairing meetings when there is no work being done to discuss.
After 10 months of saying that I really needed to pull back from standards work, to focus on the book and on proper paying work, I finally found myself with no one left dragging me back in.
I'm an Invited Expert to a group that no longer exists. An editor of specifications that no one wants to implement. And I'm still trying to finish up a book on Using SVG on the web, with lots of future-focused notes about upcoming new features and the likelihood (or not) that they'll ever make it to web browsers.
Administration at the W3C is still trying to revive the SVG working group, but they are doing it via quiet negotiations with browser reps. Nothing is being said on the www-svg mailing list. Members of the CSS working group have been keeping me in the loop. I've promised them that I'll write up a summary of the issues as I see them. This post was supposed to be that, but that'll have to be something separate instead.
I have mentioned to multiple people that I'd be willing to work on the spec or test suite if someone was willing to pay me to do it.
I've also been wondering about crowd-funding support from SVG developers to create a proper suite of SVG 2 polyfills. A few people have been working on bits and pieces of what's needed, but not the full package, organized in a way that's useful to end developers.
But I've also be seriously thinking about switching gears completely after the book is done (June-ish, if Dudley and I can keep going until then).
Since last summer, I've been doing some general web development freelancing. It's not grand, exciting work, but it's a nice team and it's helped ease the constant stress over money. I could focus on that kind of work for a few years, start putting some money in my savings accounts instead of taking it out.
I also still get a little wistful whenever I see cool data visualizations and interactive journalism projects. That was what I was supposed to be working on. But I'm not sure who I'd work on them for. The Canadian news industry has completely imploded in the not-quite-a-decade since I first signed up for my Master of Journalism degree. And the well-paying, dependable jobs have never been the remote-friendly, flex-schedule jobs that work for a woman with chronic fatigue.
Or there are a dozen other ideas for tools or projects of my own that I'd like to build, if only I could figure out a way to make them pay.
And not just computer dev projects. My ex keeps asking whether I've been keeping up with practicing music. (I haven't.) I've got 15 years' worth of notebooks full of song lyrics, some of which I still even remember the melodies for, and a much-delayed promise to myself that I'll teach my hands how to create the music in my head, at least well enough to put together a set of song-writer's demos. But really taking that seriously means even more time without meaningful income, and no expectation that anything would come of it beyond the ability to say that I did it.
I am torn: I have invested this much of my life into SVG. Do I build on that? Or do I write it off and start afresh with lessons learned and no regrets?
I've spent three and a half years becoming an expert, maybe the expert on SVG on the web. On all its features, and all its bugs. On the workarounds that sort of work for now, and on the proposals for better solutions, if they ever get implemented. But I never cared about SVG itself. It's just a tool. I cared about what I could build with it.
But I hate working with broken tools.
Do I keep trying to fix it, or do I throw it away?