One of the reasons this bugged me so much this week is that I’ve been patiently waiting for Dojo to fix a persistent bug in the rich text editor (editor 2) for more than a year now. I’m working this week to upgrade the wiki code I had embedded Dojo’s editor into, and finding that for some reason the original version 1 editor no longer works. In fact, it’s also broken in IE and Firefox. I was hoping to build editor2 into it instead, but now… Tom, you suggested I submit a bug report. In fact, there has been one on the Trac there for a full year… See See Ticket #377. Last action was to assign the bug to Alex.

At the very least, if you can’t get editor2 working in Safari, you could code the widget to degrade gracefully to the previous version, since that one did work in a textarea in Safari. And you’re absolutely wrong about Safari 2.0 being slow and buggy… it’s far from that, which you’d know if you used it on a daily basis. (If it slows down, Safari usually just needs to have its cache emptied, which is easy to do: “Safari/Empty Cache”) That characterization is just a way of rationalizing not including it in Dojo’s coverage, which just feeds my suspicion about the direction Dojo has been taking with respect to the dominant Mac OS X browser platform.

Leaving Dijit aside, if you’re not supporting Safari 2.x in the current shipping version of Dojo (as you say you are in your browser support page), you really should change that statement, which would (for what it’s worth) lower Dojo’s cross-browser rating, which I’d previously scored as an “A”. And no, I’m not planning to post any articles about this… but I did want to get your attention.

Unfortunately, as a minority platform, it takes loudmouths like me to ensure support for our favorite browser. Whereas Windows users of the incredibly buggy, slow, and non-standards-compliant IE 6.x (still accounting for an ungodly share of the market) don’t have to worry that developers will bend way over backward to accommodate its quirks. In comparison with the quirks in IE 6 (and probably 7, since I gather its CSS support is still very poor), those in Safari and Opera are quite tame. But they do require that the Dojo team include someone, for example, (a) with a Mac OS X system and (b) running Safari 2.x daily with the latest builds and addressing bugs. I wouldn’t imagine finding someone like that would be too hard these days.

Yup, I meant that Dijit won’t support Safari 2.0.4, but rather we’ll support the Safari that will be released imminently (or so I am told).

About Opera – we can certainly revisit that after the 0.9 release. But I needed the Dijit spec to be clear about what Dijit 0.9 supports (that is the purpose of a spec, after all; it’s like a contract), and for 0.9 we won’t have time to test and fix Opera (on Konqueror) issues.

There’s also a lot of other things we aren’t supporting (or at least not testing), like FF1.5, IE5.5, Mozilla, mobile devices. Just a question of time and resources.

Bill

First, please don’t invent malice where none is intended. It might make for a good story arc, but it doesn’t help any of us get the right answer.

Leland, you and I have discussed Dojo’s Safari support at length in the past and the only thing that has changed to date is that time has passed and that we’re setting the bar higher for ourselves. The current *shipping* version of Safari, for rich text editing, is both so slow as to be unusable and so buggy as to be pointless. The Safari/Webkit devs have spent a great deal of time improving this and it really shows in the webkit nightlies. We added the fixes needed to make our editor work there *last year*, and we’re continuing to track that development and ensure that everything else works as well. For instance, we’re ensuring that dojo.gfx works on Webkit Nightlies despite the fact that there’s no official ship date for that browser. And of course, we support that kind of bleeding-edge feature in Opera already.

Our browser support policy has always been “latest Safari, latest Opera”, and while the widget system hackers are pulling their hair out trying to make accessible widgets in Opera, the system does everything short of that quite well indeed. What the widget team *isn’t* committing to right now (and this is still up for discussion) is saying that we’ll have 100% feature support (mostly a11y related) for Opera. Please note that what we’re saying here is that we’re gunning for something that other toolkits aren’t even promising today and that we’re encountering critical bugs in reaching *that* goal in Opera. Will things work there in general? Of course. I’m still pressing the case with that team that 100% support is an important goal, but we have to ship and our resources are constrained. We’ll be revisiting this discussion SRTL, and you are always invited to get involved in the discussion and help us by submitting patches and test cases. We do everything in the open.

As for Core, we’re testing on Opera and Safari on a daily basis. They are certainly first-class citizens, despite their relatively minor desktop market share. Webkit seems to be winning the marketshare race on smartphone platforms, so we’re actually testing Core there as well.

As for thenote regarding the webkit nightlies (taken out of context and misinterpreted), we’ll be presenting at WWDC on some of the new webkit features that we’re *already* supporting. The discussion about whether or not to try to backport things for Safari 2.0.4 is a calculation that revolves around our anticipated ship dates and when Apple had said their next OS version would be available (which we are anticipating will include an updated webkit). This is a question about what “latest Safari” means given those timelines. Not a question of whether or not features will be supported on Safari.

Choosing to cast our browser support goals in a poor light is clearly your choice, but I suggest that it’s not representative of reality nor does it reflect well on you.

Regards

Further, the same Dojo page, which gives an overview of Dijit, makes a mindbogglingly dumb statement about WebKit, leading me to question Dojo’s commitment to that platform as well:

Before Dijit is released, Webkit will be released and pushed to all macs, or so I am told.

How can someone responsible for a project as important as Dijit not be technically conversant about WebKit? WebKit is already–and has always been–a part of Safari. WebKit is the core of Safari… it’s the HTML and JavaScript rendering/parsing engine for Safari… and new builds of WebKit are “pushed to all macs” regularly with new builds of Mac OS X (I’m talking about the point releases here, not the major ones… and no, 10.4 is not a point release… 10.4.9 is). Further, any Mac user today can download WebKit and run it inside Safari, taking full advantage of the advances in JavaScript and CSS that the newer builds off. They don’t have to wait to have it pushed to them.

One last concern I have with Dojo is that the current rich text editing widget (editor2) has, for about a year, contained a bug that keeps it from working in Safari when instantiated within a field. This bug persists even in the latest builds of WebKit and Safari 3.0 (for Leopard), which now have full, stable support for the contentEditable property. So what gives here? Why hasn’t this bug been fixed by now? In December 2005, I selected the Dojo editor for my organization precisely because it had full cross-browser support when few did. Now I’m probably going to guide us to TinyMCE or some other editor that actually works in Safari.

Alex, where are you? Dojo was so great!

Sadly,
Leland

Actually dojo already a centralized hosting (provided by AOL):
http://dev.aol.com/dojo

But I tend to agree with Richard: I’d hate to rely on some other site.

What would be very cool would be some sort of failover mechanism so if the central site is not available, it gets the libraries locally.

mikael – Dojo itself isn’t hosting their libraries. But AOL is providing it via their CDN…Ajaxian wrote about it back in January and November. Kinda makes more sense since companies like AOL have the high-scale hosting infrastructure and Dojo foundation doesn’t.

http://dojotoolkit.org/dojo-0-4-2
http://ajaxian.com/archives/including-dojo-via-the-aol-cdn
http://ajaxian.com/archives/hosting-javascript-on-cdns-aol-announces-the-hosting-of-dojo
http://dev.aol.com/dojo

In addition to the caching benefits you mentioned…linking to the dojo libraries in this way also saves you from bandwidth costs. One obvious downside – this won’t work if you are using your own Dojo custom-build…

The reason I like this is that if each version of the library has a unique URL the browser can be made to cache a single copy of the file for a long period of time. This means the file is downloaded once and used with multiple sites… the user only has to wait for the download the very first time their browser sees it.

I love that library sizes are being kept to a minimum, but I think if libraries were centralized and reused it might not be as large of a concern.