category archives | futuraprime: blog

visit»
Be Wrong As Often As Possible

7 Oct
It’s an entertaining rant, but it’s the bit at the end—“Programming is an exercise in overcoming how wrong you’ve been in the past”—that’s particularly noteworthy.
- Flash
- Javascript
- Random
- 0 comments
Browser Incompatibility 5

13Jul2009
- filed under
- Browsers
- Javascript
- Web Design
There’s been some contentious debate about the advent of HTML 5, and we’re now (with Safari 4 and Firefox 3.5) getting our first go at actually working with it.

I’m sorry to say it’s not going well.

Others have covered some of the ridiculous issues the new “standard” has brought, like the video standard-that-isn’t and the mess of unnecessary, non-backwards-compatible, semantic tags. I’m going to get into Javascript, here.

One of the key purposes of HTML 5 is to move the browser towards creating richer interfaces. A number of features have been added to the standard. Two I’ve been working with recently are the drag-and-drop functionality and the contentEditable property. Drag and drop is new; contentEditable is much older (it’s a Microsoft invention in IE 5.5 that’s slowly spread to the other browsers).

contentEditable

contentEditable turns an element into a rich-text editable element, but the spec on this offers no particular guidance on how to implement the things it’s supposed to do. execCommand is inconsistent among browsers, and so is the styling: Safari, for example, tosses in <b> and <i> tags where Firefox dumps in <span style="font-weight: bold;"> and <span style="font-style: italic;">.

Drag and Drop

Drag and Drop is even more bizarre. The spec here is much more prescriptive about how the Javascript behind it should work, but there’s still plenty of room for silliness. Ideally, you’re meant to just stick draggable="true" ondragstart="/* drag function here */" on a element and it becomes draggable. It works in Firefox, but not in Safari, which requires an extra CSS element(!?) be applied to the draggable items. Moreover, in Firefox, text is draggable, but in Safari, it’s not. For example:

This is draggable!

You’ll notice in Firefox 3.5, the above rounded box is completely draggable (though you can’t drop it anywhere). In Safari 4, however, it’s only draggable if you click on the healthy padding—click on the text itself and you’re just selecting text instead.

Drag and drop also leaves a lot of mess on the HTML itself: there are a lot of events firing. Shapeshed has a great little overview here.

You’ll notice to create a drop zone requires this lovely markup:
```
<div id="trash" ondrop="drop(this, event)" ondragenter="return false" ondragover="return false></div>
```
Cancelling ondragenter and ondragover are currently required. That’s a bit of a mess. (And all the event attributes! Ugh.)

Firefox 3.5’s drag events also bubble in the wrong order: events fire on the lowest elements first, and only then up to the elements they contain. If you stick a dropzone on the <body>, it’s the only dropzone on the page that will fire. Ever.

Worse Together

There’s a note at the beginning of the “User Interfaces” section of the HTML 5 spec (here):

“Would be nice to explain how these features work together.”

Alas, in the case of contentEditable and drag and drop, fact is they don’t, at all. I’ve spent some time hacking the two of them together, and I’ve come up with something that’s almost workable in Firefox 3.5, though not in Safari 4, which (of course) has different behaviors. I worry it’d take me another week at least to figure out the further idiosyncrasies of Safari 4’s implementation; frankly it’s not worth it as I sincerely hope both implementations will be replaced with something better in a future version—which will render my version broken and useless.

Right now, to drop an element into a contentEditable region in Firefox, you have to parse it to HTML (not actually a trivial task). contentEditable has its own idea of what dragging and dropping is and does and it’s got no awareness of HTML 5’s new thoughts on the matter, so it doesn’t interact in any especially controllable (or sensible) way with the dataTransfer features of HTML 5’s drag and drop. In a number of ways, it seems the whole implementation is set to just do what it decides it wants to do and that’s that.

In Firefox 3.5, dropping an element on an editable area dumps text/html or text/plain out of the dataTransfer, which is immutable. (It prefers text/html.) You can drop an HTML element this way by rendering it into HTML, and at least this allows you to drop it at the cursor.

Safari 4, by default, does nothing at all when you drop an element into an editable area, which makes it very hard to select a spot in the text for insertion based on the cursor location.

In neither implementations does there appear to be a model for figuring out where in the contentEditable text you might be dragging something in to; Firefox just happens to handle this by default so long as you’re doing something reasonably compatible with its basic functionality.

In all, it’s a frustrating experience. These new features have a lot of bugs to iron out, and it doesn’t help that browser manufactures are happily pushing out products based on unfinished specs that will leave behind inconsistencies web designers will have to plan around for years to come.
- 0 comments

Be Wrong As Often As Possible

Browser Incompatibility 5

contentEditable

Drag and Drop

Worse Together