Closer To The Ideal

PPK has an unusually harsh post about the way drag-n-drop is being implemented in HTML5.

dragthat and dragsomethingelse

In theory dragenter and dragleave could be great events, since they fire when you enter or leave an HTML element in the middle of a drag operation. If that element is a valid drop target you could change its styles ondragenter and ondragleave to indicate this fact to the user.

With the spec being based on the Microsoft API, I expected dragenter and dragleave to emulate mouseenter and mouseleave. But they didn’t. Not even in IE. They’re based on mouseover and mouseout and suck every bit as badly. And their names are wrong.

Mouseover and mouseout are terrible because they bubble up all the time and make it very hard to distinguish important events from unimportant ones. If I mouse over (or drag enter) a child element of the one that the event is set on, it also fires. And that’s exactly what we don’t want. The events will fire incessantly the whole time the mouse is above the element, and we have to work hard in order to distinguish useful events from useless ones.

Mouseenter and mouseleave, on the other hand, fire only when you enter and leave the element they’re defined on, and they don’t bubble. That makes them much easier to use.

They are Microsoft extensions, by the way, and excellent ones at that. They work only in IE.

Note that originally mouseenter and mouseleave had exactly the same IE only compatibility pattern as drag and drop. Mouseenter and mouseleave are a good idea, drag and drop … isn’t. Guess what the other browsers chose to implement?

No wonder web development is such a fucking pain with fucking morons in charge of the browsers.

Wait, that could be construed as an insult to morons.

Ah, what the fuck.

dragbullshit

Dragover, now, has nothing to do with mouseover. It’s exactly the same as the drag event, except that you can set it on any element instead of just the document. Or something. Whatever.

Why do we need the dragover event if we already have the drag event?

[ ... fume ... ]

To cancel its default action!

If we didn’t have to cancel its default action the dragbullshit event would have no fucking point!

And we can’t have pointless events in our nice specification, now, can we?

So we give it a default action. A very complicated default action.

That has to be canceled. Absolutely, positively has to be canceled.

[ ... crickets ... ]

Anybody LISTENING to what I say?

[ ... drag ... ]

I deserve a fucking MEDAL for this. Above and beyond the call of fucking DUTY.

For much of the last 3 weeks I’ve used Windows laptop running XP (instead of my usual Ubuntu Linux machine) which gave me a chance to try out some of the browsers that have no Linux version.   One of the greatest aspects of the current web development scene is that most of the surviving browser projects are competing on how well they can implement web standards and HTML5 (contrast the current scene with 1996, when Microsoft set out to break the web, with its “embrace, extend and exterminate” strategy).

I’ve already noted that FireFox seems to have surpassed Internet Explorer, in terms of usage. Microsoft will hopefully soon kill Internet Explorer and replace it with something else.

I admire much of what Brendan Eich has done. And for the last several years, FireFox has been my web browser of choice. But FireFox drives me crazy with its demand for resources. Compared to any other browser I’ve tried, it demands more RAM. With just one window open, it will grab 60 to 90 megs of RAM (compared to, say, 14 for Chrome). With several pages open, which is normal for me, FireFox will grab 200 to 250 megs of RAM. Chrome might grab a 3rd of that. (These statements are true for FireFox 2 and 3, and Chrome 1.)

FireFox allows plugins, which is the main reason I use FireFox. The Firebug and Session Manager plugins are essential tools for me. However, FireFox doesn’t police the resource usage of these plugins. They can crash any machine: Macs, Linux, Windows. (Those of you who want to claim “Linux never crashes”, please note that a process can use up most of the memory on the machine, and then the machine becomes unresponsive. For the user, this is the same as a crash, even if in some hair-splitting way it avoids the technical definition of a crash.)

Chrome has the kind of plain, minimalist design that is a signature of most of Google’s products.  I like it a lot, though it has many annoyances. Yahoo Mail normally auto-suggests email addresses as I start to type them, but this doesn’t happen when I use Chrome. Also, when using WordPress, Chrome embeds inline styling, whereas other browsers do not. Also, again with WordPress, Chrome erases all line breaks every time I update a post, so that the text is reduced to one giant paragraph. Basically, most of the Javascript that is out there was not written with Chrome in mind, and Chrome has some kind of conflict with it. Also, surprisingly, I’m not able to log into some of my favorite forums with Chrome.  I get no error message, but I am not treated as logged in, even after giving the correct username and password (I have the same problem in Safari, but not in FireFox).

Scrolling a web page, using the arrow keys on the keyboard, is important to me. I read a great deal online, and for me it seems natural to want to use the arrow keys to move down the page as I read. Here is one area where Chrome is especially good. It scrolls smoothly. FireFox is usually broken in this regard – it tries to move the cursor down the page, but if the HTML is laid out in a way that allows the cursor to skip the main text of the page, then FireFox simply drops to the bottom of the page. This drives me crazy.

Safari 4 seems to be in between Chrome and FireFox in terms of resource use. It is wonderfully standards compliant and leads the way in supporting HTML5. I admire it for that, though until more browsers support HTML5, I can’t imagine using any of the new tags on a commercial web site.

Right now I can see using FireFox when I want to use my favorite plugins, and I can see using Chrome when I want a fast web browser, but I’m not sure what would cause me to use Safari.

I’m comfortable making this prediction: IE will continue to fade, and Microsoft will continue to fade, and FireFox, Safari and Chrome will all have more browser share a year from now than they currently do. So it is time for designer to start checking their designs in all of these browsers.

This project is tracking all the new upcoming web technologies, like CSS 3, which will allow us to have rounded corners without having to use images. Also, elements such as Canvas. Also, other technologies, such as transparency in PNG images.

Right now, none of these technologies are usable because at least one major browser doesn’t support them. But clearly, over the next year, most of these technologies will become usable in all major, newer browsers. Then the question becomes, at what point do these features have enough market share that you’d want to use them on a commercial site?

The reality that a new version of HTML will soon come out makes me aware of how stagnant things have been for the last 6 or 7 years. Compared to the incredible speed with which things evolved during 1994 to 1999, the last few years have been one of consolidation:

I’ve younger friends who’ve become web designers in the last 4 years and who’ve never seen an evolution of the technology. They learned CSS 2 and HTML 4, and that is what they are still using now.

Universities now offer classes in something called “web design”.

There is now a profession called “web design”.

This profession is now in control of the standards around which the profession does its work.

The usual  balance-of-power conflicts between for-profit corporations and the professions, have become normal for the field.

Consolidation has been the rule. Perhaps it was necessary.

The web is in desperate need of new element options. My friend Chris Clarke likes to joke that HTML 5 will bring web forms up to the level of interaction offered by Visual Basic 1.0. I am hopeful that this next year will rekindle the forward momentum of innovation.

Via Sam Ruby, we are pointed to this in the comments at Intertwingly:

Btw, if you want CSS rules to apply to unknown elements in IE, you just have to do document.createElement(elementName). This somehow lets the CSS engine know that elements with that name exist.

This could be a viable strategy for using HTML5 and styling the results in IE, even if IE does not support certain tags.

I am struggling to accept what Anne van Kesteren announces as the future of the web:

People are slowly starting to realize what HTML5 means and start arguing about individual things:

* No SGML
* No DOCTYPE
* No formal schema
* No versioning
* Defined error handling

It’s hard to grasp that all you ever thought was right — is wrong.

Why am I strugling to accept this? I guess because learning all this stuff was hard and now, having learned it, it is tough to let go. As she says, it is tough to accept that all you ever thought is now wrong.

On the bright side, HTML 5 will have some new tags. Kesteren has been documenting them as part of the draft proposal:

section – represents a generic document or application section. It can be used together with h1-h6 to indicate the document structure.

article – represents an independent piece of content of a document, such as a blog entry or newspaper article.

aside – represents a piece of content that is only slightly related to the rest of the page.

header – represents the header of a section.

footer – represents a footer for a section and can contain information about the author, copyright information, et cetera.

nav – represents a section of the document intended for navigation.

The input element’s type attribute now has the following new values:

* datetime
* datetime-local
* date
* month
* week
* time
* number
* range
* email
* url

While using Google to look up some of Kesteren’s old posts, I stumbled across an older discussion of HTML5, XHTML, and how best to serve these files on the web:

Sam Ruby wrote that insisting on a valid XHTML web page was too hard for people who wanted to create SVG images (that’s Scalable Vector Graphics) as part of their pages. This made no sense to me because Ruby has SVG images on his page and I know he is very smart and can surely work out any problems with validity that he might run into (even making sure his page is valid XML). But then, in the comments, he explained what he wanted and it all made sense:

The world in which I would like to live is one where my daughter could view one of the ever-growing number of SVG images that are hosted on wikipedia, and could select-copy-paste one onto her MySpace template. I would have no problem with the requirement that the SVG image itself be locally well formed, but the requirement that the enclosing page must also be well formed and served with a non-forgiving and not-universally supported MIME type is a non-starter.

Oh, yeah, now I get it. MySpace is a disaster and there are lots of websites out there that are just as bad, yet a JPEG or GIF image will still show up correctly on any of those sites. Ruby wants a world in which SVG images are as portable as JPEG or GIF. That means they have to be allowed to work on invalid pages.

On that same page, in the comments, Ruby raises the question of why the WHATWG weblog is running WordPress, which serves XHTML. Since the WHATWG exists to tell the world about HTML 5, shouldn’t its blog run HTML 5? Lachlan Hunt then explained:

Regarding the WHATWG’s WordPress blog installation and the problems with it, I have attempted to get it to output HTML5 instead of XHTML, but the major problem is that there’s XHTML empty element syntax, string-based processing and other nasty surprises littered throughout the code, that it’s just just as simple as writing a new template for it.

It’s such a fundamental flaw in the way WordPress and many other CMSs have been built. The best option is to write a CMS from scratch that uses real XML tools on the back end and serialises as HTML to output; but the amount of time and effort that would take to set up compared with the one-click installation of Word Press is just too much.

I just posted this to the wp-hackers mailist, and Alex Günsche replied:

It is true that there are XHTML snippets hardcoded in the WP core. But it would be a matter of a couple hours to find and replace that code. (This would also be required on each upgrade.) Then you would need timeto create the template, which can also range from a couple hours whentaking and adapting a simple existing theme, up to a week and more whencreating a new and sophisticated theme.

WordPress is not MVC, which is, without a doubt, its greatest flaw.