The Story of Firefox, for kids

Over the past few years, I’ve been working on and off on a children’s book about Firefox. The project started when my kids wanted to understand what I did at work every day.

The story is a sketch about the evolution of Netscape into Firefox and the power of being open. In terms of historical accuracy, a number of things were simplified in order to keep the messages simple.  For better or worse, it’s already 2500 words. That means it’s not for very young children (I’m thinking 2nd graders and older).

I used readily available imagery of a dragon, a phoenix, Firefox, and Mammon (the god of greed, as I’ve learned). In the story, coders are wizards who cast spells. Naturally, there is also a Chief Lizard Wrangler 🙂  Where possible, I used plot and dialogue, but at times it addresses the reader directly.

The only kid I’ve tested it on so far is my son Oliver (age 8). He loves it, but then he may just be happy that his father spent time to write about a dragon.

If anyone is seriously interested, I’d love to get some help polishing it until it’s good enough to become an actual book.

Advertisement

DotSpots, a cool use of Mozilla technology

DotSpots is launching today. A dot is a “distributed object of thought”, which is like a mini blog post containing rich media, which can be connected to any paragraph in the news. Dots can be authored on the dotspots.com website or via the Firefox extension. They can also developed and polished by teams of collaborators. The secret sauce is distribution: DotSpots will distribute dots to similar paragraphs in articles across the web. There is a video and sign up link on today’s TechCrunch article about DotSpots.

The Firefox extension is central to DotSpots — it really provides the best way to view and create dots in the context of other pages.  The web client is also important and shares a lot of the same features. Of course, the website cannot provide the same benefits as the extension on third party web pages.

The technology is something special. All the major pieces, including the Firefox extension, website and backend, were written in Java.  Google Web Toolkit (GWT) actually compiles our client Java code into compressed JavaScript. This is a great development model.  For one thing, strict type checking definitely helps on a project of this size. It’s also great to be able to stay in the same language on the server. The Eclipse debugger helps out quite a bit, stepping through Java in the server as well as both clients. To communicate with Mozilla components, DotSpots CTO Matt Mastracci developed GWT bindings for XPCOM, which we’ll be open sourcing at some point.

For those who know me as a long time Mozilla contributor, be assured I’m putting that knowledge to good use. And, given the transitional state of the news industry today, it’s an exciting time to be working at Web 2.0 news startup. It will be interesting to watch how the industry progresses.

Cross-browser <video>

My colleague Matt Mastracci from DotSpots has just released support for the HTML 5 <video>tag across browsers. Legacy browsers are also supported. Please see Matt’s post HTML 5 <video> support for older browsers.

Kudos both to Matt and to our employer DotSpots for supporting web standards.

How to hack your app to make contenteditable work

The mission? Build a rich text editor widget using contenteditable. Mark Pilgrim described this contenteditable use case as “alive and well on the web” with the warning that it is still “evolving”. Nevertheless, because of various problems we had using an <iframe> our group decided to switch from using designMode to contenteditable.

Note: this article has been updated several times to add up-to-date information as it becomes available. Please add your tips and tricks or any corrections as a comment.

Most of the issues are in the Mozilla editor implementation. IE and WebKit seem to work fine.

Mark’s document is an excellent resource, but now it’s time for a reality check. Here are some problems I had to work around in Firefox 3.5 beta 4:

1. Large caret,  tiny caret, no caret, or two carets on initial focus.
   Workaround: ensure the magic sequence of <p><br/></p> as end-of-document content. Watch everything that happens to make sure it’s never changed, removed or even selected. (Bonus: this is also the fix for several other items in this issues list). Don’t let the caret go after it. If selection ends up extending past it, then just use window.selection.extend to move just before the caret. If the selection had been “collapsed” (just a caret), then set the caret before it (for example set the start before andthen  use window.selection.collapseToEnd to make the selection match).
2. Many execCommand commands, such as bold, do not work after select all, or may have issues when the caret is at the end of content.
 Workaround: the fix for item #1 above also addresses this.
3. The “indent” and “outdent” execCommand will actually indent the entire contenteditable region! 
Workaround: the fix for item #1 above also addresses this.
4. Caret and selection are not restored when you tab or click out of the contenteditable area and later tab back in.
   Workaround: store selection onblur and onmouseout, and restore onfocus. Unfortunately onblur was not enough, because by the time the user has clicked outside of the editable area, the selection has already been forgotten.
5. Double clicking on any HTML Form input in the same document as a contenteditable no longer selects a word.
   Workaround: you have to cleverly set contenteditable=”false” on all area in the document onmousedown in the inputs, and then set them back to “true” as soon as possible.
6. You can paste the editor back into itself etc. This is arguably a feature, not a bug, since contenteditable could be used to develop web authoring tools. However, it’s something to be aware of.
   Workaround: create styles for all children in contenteditable for overflow: hidden !important. You’ll need to think about what styles to override. Remember that users can drag or paste in comment from anywhere.
7. Can’t select text and do operations such as delete if the text includes the beginning or end of the content.
   Workaround: make sure the root editor element is a <div>. Style it how you want (e.g. display: inline), but if it’s a <span> at least, this bug will occur.

My team is still discovering some issues, but they are harder to reproduce. Sometimes the editor becomes unfocusable and it becomes impossible to do further editing. I’m not sure what gets it into this state.

There are over 70 filed contenteditable bugs, and when I am done filing there will be more. The fact that most of these bugs were not yet filed by anyone else yet seems to indicate that contenteditable just isn’t being used much out there. I can see why, and unless the issues get cleaned up, it will stay that way.

The low quality of contenteditable support is unacceptable, especially for something that shipped in a previous version of Firefox. There was plenty of time between Firefox 3 and 3.5, to circle back, gather what was learned, and fix the most important bugs. Yet, I could only find 7 behavior-related contenteditable bugs fixed since June, 2008. That means it’s mostly being allowed to exist as it is.

I would like to make an observation, after 8 years working on the Mozilla code base, and now as a developer of web applications. Please don’t read on if you are allergic to sports analogies, or if you just want to hear how great Mozilla technology is. Quality would be higher if there were one or two fewer  initiatives for the Next Great Leap, and more concentration on just fixing the old boring bugs. There are obviously a lot of big world-changing initiatives going on at Mozilla, and there should be. However, as a community we should be realistic that three point shots are awesome when they go in, but they are easy to miss. Lots of simple plays, like rebounds and layups, are still necessary. Sometimes I think that fundamental bug fixing gets lost in the drive to make news headlines. Honestly, you don’t have to go that far out on the edge to find problems. I don’t believe this is an engineering issue. I think it’s actually Mozilla’s leadership not wanting to pour resources into what seems like an endless problem where great results don’t provide immediate mind-share benefits. However, as we all know, this stuff is super complicated, and in order for the web to move forward things have to “just work”. Either Mozilla has to fix the behavioral bugs or every web developer who uses the feature has to track down what the problems are and try to find a hack for it.

P.S.  FWIW, other than selection memory, WebKit has worked perfectly so far.  That said, Mobile WebKit for the iPhone has a major issue. It doesn’t actually support contenteditable at all. Worse, it reports that it does — node.contentEditable and node.isContentEditable are true for a node with the attribute contenteditable=”true”, yet . So if you want a fallback, you have to sniff for the user agent rather than use the technique of capability detection, which is better because you never know which future version will support contenteditable.

Frank Hecker, Catalyst for the Web

It’s time to take a moment to thank and congratulate Frank Hecker, winner of the 2009 Catalyst Award, for his work to improve the lives of people with disabilities.

The Catalyst award page describes Frank perfectly:

Catalysts are elements or chemicals that can cause or accelerate reactions but do not, themselves, get used up. They are, in this case, people who make things happen by their presence and by what they do. They don’t necessarily do everything themselves, but they bring out and enable the best in the rest of us. They connect the rest of us, and facilitate our interactions so that we all can do great things. They connect us, and facilitate us so that we all can do great things.

Not only has Frank done a lot for accessibility, he’s behind a lot of the work on the open web, which we all enjoy and appreciate. Frank has helped many individuals live up to their true potential. Please see the 2009 Catalyst Award announcement page for more details on what Frank enabled, and how he did it. This award was an easy choice.

Anything is possible if you don’t care who takes the credit. Thanks again Frank, not only for teaching us that, but for all you’ve done for this community. We could use a few more people like you.

IBM, Open Accessibility and Change

Richard Schwerdtfeger, my mentor and technical lead at IBM, explains why IBM let go of myself and Pete Brunet, and what it says about IBM strategy in open accessibility going forward. Although it was done suddenly, it makes a certain amount of business sense.

To summarize what I’m reading and thinking: IBM realized that our efforts in driving WAI-ARIA and IAccessible2 forward were a success.Things are now at a point where IBM can use these technologies in products without devoting full time employees to drive them. IBM believes browser manufacturers must carry forth any further efforts necessary to make web applications accessible.

What still remains to be done? There is more work in W3C to finalize the WAI-ARIA 1.0 standard, and Rich will still be chairing that effort. There is more work to support WAI-ARIA within various JavaScript toolkits and assistive technologies such as screen readers. However, the biggest missing piece in the infrastructure now are solid, consistent, support across all browsers. Firefox support for WAI-ARIA is strong, although some advanced uses such as complex grids with expandable parts will take time to sort out. In addition, consistent support across other browsers will be elusive for some time. Hint: IE 8 betas need work, but are easily beating WebKit and Opera.

But what’s really needed now is WAI-ARIA support in popular web applications. Killer WAI-ARIA applications will drive the need for better browser support, by putting meaning behind the efforts. One would think that a killer consumer application using Dojo’s Dijit or native WAI-ARIA support would emerge, but I haven’t seen one yet (please correct me if I’m wrong). You will still hear this note of resistance when discussing the need for WAI-ARIA with developers of some browser engines. WAI-ARIA bugs in ATs and browsers are simply more likely to get fixed if real users must switch browsers in order to access their web mail, calendar or web-based office application.

The solid Firefox and AT support, and upcoming IE support, are reason enough for developers to rally behind WAI-ARIA. Web application developers, please, implement WAI-ARIA and push browser manufacturers to fix their bugs. Finally, JavaScript front-end developers — please help contribute WAI-ARIA questions and documentation to the free-aria mailing list and codetalks.org wiki.

So in summary, IBM is right. They really did a lot for the community in developing WAI-ARIA and IAccessible2. A major aspect of this was their support for Pete Brunet and myself. We did a great job and IBM will continue to use the results for accessibility in their products. Now, the community will bring these technologies to the next level — mostly, by embracing them.

I want to end by lauding the work Pete did with IAccessible2. Without IAccessible2, advanced web application accessibility would not be available on Windows. IAccessible2 also allows any desktop application to support full accessibility. Like myself, Pete is obviously considering opportunities — he is brunet at us.ibm.com. And hey Pete … open some champagne. Both Rich’s post and our body of work show the facts. We were profoundly successful.

Goodbye IBM

This came as shock to me today, but I was just laid off from IBM. It was not a result of performance. They tell me it was because ARIA and working with external browser vendors is no longer a priority. There is still the chance to find work for another group in IBM, and I will probably be looking into that.

I have enjoyed working there, especially on Web 2.0 accessibility and Mozilla.

But, perhaps this will be the opening of new opportunities. I’m always optimistic.

Update: Some more thoughts … I’ve never been laid off before. In fact, everyone I ever worked for was more than pleased with my output. I know that people who understood my work in IBM really appreciated it. We certainly rocked the accessibility world!

I’m not too worried right now, and I’m very open to hearing about opportunities. Mostly, I just like doing things that benefit society. It doesn’t have to be accessibility, and probably doesn’t even have to be software. Realistically, it may be difficult to be given a great opportunity to move and shake outside of software, but you never know. I do like the kind of projects that Benetech gets going. I’m fascinated in potential in Obama’s plans for using technology to better utilize the public in decision-making. I’ve had some cool ideas around that in the past, which in fact can be more general and could be quite fun to work on.

And, don’t be too surprised if I stay in accessibility or even if I find some new opportunity to work on accessibility within Big Blue itself.

If you have a challenging opportunity to run by me, please send a note to aaron at moonset.net.

Microsoft listens, and addresses WAI-ARIA concerns

A few months ago, I blogged that Internet Explorer 8 beta 2 was not using standard syntax for WAI-ARIA properties. The syntax actually varied depending on the mode chosen for the page, which was confusing. Sometimes the standard worked, and other times you had to use non-standard camelCase for WAI-ARIA.

Microsoft has listened and is correcting WAI-ARIA property support in IE 8 RC1. Here’s a big thank you. It’s important to have a healthy portion of WAI-ARIA work the same across both browsers. Many look forward to test-driving the WAI-ARIA support in IE 8 final.

Math accessibility continued

After collecting a lot of information about math translation libraries we found a lot of overlapping effort. There are at least 3 major open source math Braille translation projects, each supporting multiple Braille math codes (there are over a dozen types of Braille math worldwide).

This raises many questions. Which open source library should screen readers like NVDA and Orca use for Braille display support? Should they just use liblouisxml, since they already use liblouis for translating ordinary text into Grade 2 contracted Braille? Liblouisxml currently supports MathML but not TeX, so how would TeX be supported? Since that is used in WikiMedia equation images, it seems important. And, perhaps proprietary screen readers can take advantage of some of these libraries as well.

There is potential collaboration here. If you’re interested in working on these problems or in these projects, please join the new free-math mailing list.

Looking back … and forward

So this whole thing started for me back in 2000. It began as a one way trip from Chicago to Netscape’s Mountain View offices, traveling through small towns and past the Grand Canyon, up through California and finally into the fog of the bay area. This was to be the last major trip for my mini-Cadillac (a 1986 Chrysler New Yorker).

Netscape barely knew what accessibility was. But they gave me an apartment to live in, and an office. I was working for a Braille note-taker manufacturer who needed web browsing capability. My coding skills were all home grown, in straight C and not in C++. I had never touched something as immense as the Mozilla codebase, and still had not grasped the true power of dynamic content. But what I did have was passion and the belief that open source was a beautiful place — and the best place to implement accessibility the right way.

Eventually Netscape hired me to integrate accessibility into the core product. There was a lot to do — not just to make Mozilla communicate XUL and HTML content and events to screen readers via MSAA, but also to add full keyboard support. I also added some special features for all users, like caret browsing and type ahead find (later enhanced by Blake Ross to become the find bar).

Then in July of 2003, Black Tuesday arrived. The Netscape browser team was laid off. I’d like to thank Asa Dotzler and others for their optimism very early on, even before this. Asa knew that Mozilla needed to be free to develop its own vision, Firefox. The truly passionate found a way to continue working on Mozilla. A year after I was laid off, IBM hired me finish the accessibility work. Yay!

All in all, I got married, had two children, went through three jobs, lived in three cities and fixed over 1000 bugs since it all started …. and we have a very accessible Firefox. Mozilla has a major role in leading the charge for accessibility of Web 2.0, not to mention accessibility on the Windows and Linux desktop.

These days, Marco Zehe, Alex Surkov and David Bolter have taken over the core accessibility work. These are the right guys to bring the quality and polish we need. It’s not all boring; there are also new features to implement. In 2009 we hope to become accessible with VoiceOver on OS X, continue to improve our support for WAI-ARIA and Web 2.0 accessibility, and address advanced topics such as accessible math, diagrams and custom widgets. It’s a bit unfortunate that these are still considered advanced topics in accessibility, when they are so basic to the mainstream. However, when Mozilla addresses new accessibility topics, it tends to pave the road with standards and documentation. This makes things much easier for implementers that come after us.

Although I’m no longer coding I work as hard as ever. I still advise in the codebase and act as module owner. I want to help make sure that decisions of the past are understood by anyone working in the code. Documentation is helpful but ultimately not enough.

What am I working on now?

• The WAI-ARIA standard and everything around it. Right now, making Web 2.0 accessible means using a narrow set of technologies which support WAI-ARIA well. The browser must currently be Firefox, and some ARIA features are only supported in certain newer assistive techologies, and definitely not on OS X. And, you’ll either need to develop your own widgets or use Dojo’s Dijit toolkit. Fortunately, these inflexibilities are slowly but surely fading away. IE, Opera and WebKit are all working on WAI-ARIA support. Numerous JavaScript toolkits, such as YUI, GWT and JQuery, are moving forward as well. Assistive technologies are improving support for cutting edge areas like AJAX accessibility via WAI-ARIA live regions. But ultimately, Web 2.0 accessibility will arrive for real when a “killer app” arrives which requires a WAI-ARIA compliant browser. That’s what will finally drive things forward.  In the meantime, I’ll try to make things as clear for other implementors as I can.
• Finding talented individuals and cowriting grant proposals for worthwhile accessibility projects that benefit the web. One example is Silvia Pfeiffer‘s project to add captioning and audio descriptions for HTML 5 video and audio. I’m also working with Eitan Isaacson, a great programmer who helps us in too many ways to count. He developed Speclenium, a tool to allow the accessibility implementations in two browsers to be compared for differences. I plan to use it to help other browsers improve their support for WAI-ARIA.
• Enabling projects to add basic accessibility testing into Firebug and develop a Firebug extension for more advanced accessibility testing. This will bring awareness of accessibility issues to a wider authoring community, finally bring the test tool development community together on a common strategy, and allow us to address Web 2.0 accessibility testing.
• Advancing the accessibility of math, diagrams and custom widgets.
• Participating in efforts such as AIA, to create a cross-platform accessibility API. Today, developing accessibility for native cross-platform applications is a nightmare because each platform has a different solution. It’s best for the web if the entire industry works together on common accessibility solutions — Mozilla, IE, Opera and WebKit.

I’m very lucky to work with the community that has developed around Mozilla accessibility. I think we follow the model of the Mozilla project as a whole, enabling each other to do great things. This is a good opportunity to thank IBM and Mozilla, and in particular Frank Hecker, for the opportunity to work as more of a leader and organizer. It’s a less direct approach than just writing the code yourself, but when the timing is right it’s the right role to take on. You’ll produce far greater results.