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.

I’ve had the good fortune to work with some truly great designers. These are people who are understand the client’s needs, who understand the users, and who naturally develop web sites that feel intuitive to the people who use the site. Long ago I learned that, when working with such designers, it was important to empower them with the code they needed, but to otherwise stay out of the way. In particular, such designers need access to the HTML of the site. When I hide the HTML away inside of PHP functions, I’m limiting the ability of these maestros to perform.

This has implications when working with a framework like Symfony.

A lot of computer programmers would add an image to a Symfony template by using one of the image helpers:

<?php echo image_tag(’banner.jpg’) ?>

But what if the designer needs to add a CSS class to this? What if they are working late at night, and they are unable to reach me? Or they are working in the middle of the day, but it is a day I’m spending away from my computer?

The designers I work with can read PHP code fairly well. And they can look up the image_tag helper and figure out its syntax. But this is a big waste of their time. It takes them further into the world of programming than they should need to go.

When creating URLs in a Symfony project, it is important to use helpers. The helpers take care of figuring out what the right URL should be for things like images. The helpers allow us to develop on one machine and deploy to another server when we go live, and even if that other server has a completely different directory structure, we don’t need to change any links, because the helpers take care of all that for us. However, managing the URLs is the only thing that the helpers should do.

So we do not do this:

<?php echo image_tag(’banner.jpg’) ?>

Instead we either do this:

<img src=”<?php echo $sf_request->getRelativeUrlRoot() ?>/images/banner.jpg” />

or we do this:

<?php sfLoader::loadHelpers(array(’Url’)); ?>
<img src=”<?php echo public_path(’banner.jpg’) ?>” />

This way the URL is managed by Symfony’s helpers, but the rest of the IMG tag is still free for the designers to work with. If a designer needs to add a CSS class, they don’t need to call me on the phone and get me to do it, and they don’t have to start researching Symfony helper tags, instead they just add the CSS class like they always have:

<img class=”header” src=”<?php echo public_path(’banner.jpg’) ?>” />

This is an important bit of project management. It allows for a correct separation of concerns – the designers get to focus on design, and the programmers can focus on the programming.

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.

Well, maybe “broken” is too strong a word. The CSS failed to load. Which happens sometimes. Which is part of why semantic markup is important. How much does the user experience survive the lack of style sheets? This from the front page of Old Navy:

Just curious, but does anyone know some common reasons why the CSS files might fail to load?

Also curious about the marketing. The front page of the site is aimed entirely at women. Do women buy clothes online more than men?

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.