HTML5 Doctor » Remy Sharp

Introducing Web SQL Databases

Remy Sharp — Wed, 24 Feb 2010 10:15:39 +0000

The Web SQL database API isn’t actually part of the HTML5 specification, but it is part of the suite of specifications that allows us developers to build fully fledged web applications, so it’s about time we dig in and check it out.

What’s in the box?

If you haven’t guessed from the overly verbose specification title, Web SQL Databases is a spec that brings SQL to the client side. If you have a back-end developer’s background, then you’ll probably be familiar with SQL and happy as a pig in muck. If not, you might want to learn some SQL before you start hacking around, Google’s your friend here.

The specification is based around SQLite (3.1.19), but having come from MySQL myself, it’s all pretty much the same (sorry for the sweeping statement!).

For an example of Web SQL Databases working, have a look at the Twitter HTML5 chatter demo I put together. It uses SQL and the WHERE clause to narrow down the recent chat about HTML5 on Twitter (it will work in Safari, Chrome and Opera 10.50).

There are three core methods in the spec that I’m going to cover in this article:

openDatabase
transaction
executeSql

Support is a little patchy at the moment. Only Webkit (Safari, SafariMobile and Chrome) and Opera 10.50 (ATOW alpha on Mac) support web databases. Fellow Doctor Bruce Lawson has told me that Firefox are holding off as they feel there’s a better implementation than SQLite (though I hope it’s similar, whatever they pick). Either way, I’d definitely recommend checking out the SQLite documentation for the functions that are available.

Because of this patchy support and the simple fact that Webkit had implemented the database spec some time ago, the spec on the W3C is now slightly ahead of the implementations in Safari, while Webkit is still catching up. On the other hand, since Opera has only just added support, it’s closer to the spec (I’ll mention the differences as we go along).

Nonetheless, it’s fun to play with, so let’s get playing!

Creating and Opening Databases

If you try to open a database that doesn’t exist, the API will create it on the fly for you. You also don’t have to worry about closing databases.

To create and open a database, use the following code:

var db = openDatabase('mydb', '1.0', 'my first database', 2 * 1024 * 1024);

I’ve passed four arguments to the openDatabase method. These are:

Database name
Version number
Text description
Estimated size of database

The missing feature of openDatabase (I’m not sure when it was added) is the fifth argument:

Creation callback

The creation callback will be called if the database is being created. Without this feature, however, the databases are still being created on the fly and correctly versioned.

The return value from openDatabase contains the transaction methods, so we’ll need to capture this to be able to perform SQL queries.

Estimated database size

From the tests I’ve run, only Safari prompts the user if you try to create a database over the size of the default database size, 5MB. The prompt is shown the image below, asking whether you want to grant the database permission to scale up to the next size of database — 5, 10, 50, 100 and 500MB. Opera, on the other hand, builds the database without complaining, which I expect might change later as it’s still in alpha.

Versions

I could be wrong, but everything I’ve tested so far says that versioning in SQL databases is borked. The problem is this:

If you upgrade your database to version 2.0 (e.g., there are some important schema changes since version 1.0), how do you know which visitors are on version 1.0 and which are on version 2.0?

The version number is a required argument to openDatabase, so you must know the version number before you try to open it. Otherwise, an exception is thrown.

Also, changeVersion, the method to change the database version, is not fully supported in Webkit. It works in Chrome and Opera, but not in Safari or Webkit. Regardless, if I can’t determine which version of database the user is on, then I can’t upgrade the user.

A possible workaround is to maintain a state database, something like the ‘mysql’ database in MySQL. This way, you would only have one version of this state database, and within this you would record the current version of any databases that control your application. It’s a hack, but it works.

Transactions

Now that we’ve opened our database, we can create transactions. Why bother with transactions instead of just running our SQL? Transactions give us the ability to rollback. This means that if a transaction — which could contain one or more SQL statements — fails (either the SQL or the code in the transaction), the updates to the database are never committed — i.e. it’s as if the transaction never happened.

There are also error and success callbacks on the transaction, so you can manage errors, but it’s important to understand that transactions have the ability to rollback changes.

The transaction is simply a function that contains some code:

var db = openDatabase('mydb', '1.0', 'my first database', 2 * 1024 * 1024);
db.transaction(function (tx) {
  // here be the transaction
  // do SQL magic here using the tx object
});

I recently uploaded a demo to html5demos.com that demonstrates a transaction rollback in action: Web SQL database rollback demo

In the nightly builds of the browsers, we also have db.readTransaction, which allows only read statements to run on the database. I assume there are performance benefits to using a read-only readTransaction instead of a read/write transaction, most probably to do with table locking.

Now that we’ve got our transaction object (named tx in my example) we’re ready to run some SQL!

executeSql

This is the funnel of love for all your SQL goodness. executeSql is used for both read and write statements, includes SQL injection projection, and provides a callback method to process the results of any queries you may have written.

Once we have a transaction object, we can call executeSql:

var db = openDatabase('mydb', '1.0', 'my first database', 2 * 1024 * 1024);
db.transaction(function (tx) {
  tx.executeSql('CREATE TABLE foo (id unique, text)');
});

This will now create a simple table called “foo” in our database called “mydb”. Note that if the database already exists the transaction will fail, so any successive SQL wouldn’t run. So we can either use another transaction, or we can only create the table if it doesn’t exist, which I’ll do now so I can insert a new row in the same transaction:

var db = openDatabase('mydb', '1.0', 'my first database', 2 * 1024 * 1024);
db.transaction(function (tx) {
  tx.executeSql('CREATE TABLE IF NOT EXISTS foo (id unique, text)');
  tx.executeSql('INSERT INTO foo (id, text) VALUES (1, "synergies")');
});

Now our table has a single row inside it. What if we want to capture the text from the user or some external source? We’d want to ensure it can’t compromise the security of our database (using something nasty like SQL injection). The second argument to executeSql maps field data to the query, like so:

tx.executeSql('INSERT INTO foo (id, text) VALUES (?, ?)', [id, userValue]);

id and userValue are external variables, and executeSql maps each item in the array argument to the “?”s.

Finally, if we want to select values from the table, we use a callback to capture the results:

tx.executeSql('SELECT * FROM foo', [], function (tx, results) {
  var len = results.rows.length, i;
  for (i = 0; i < len; i++) {
    alert(results.rows.item(i).text);
  }
});

(Notice that in this query, there are no fields being mapped, but in order to use the third argument, I need to pass in an empty array for the second argument.)

The callback receives the transaction object (again) and the results object. The results object contains a rows object, which is array-like but isn’t an array. It has a length, but to get to the individual rows, you need to use results.rows.item(i), where i is the index of the row. This will return an object representation of the row. For example, if your database has a name and an age field, the row will contain a name and an age property. The value of the age field could be accessed using results.rows.item(i).age.

That’s all you should need to get started with Web SQL Databases. I’m certain that mini JavaScript libraries are going to emerge to help support working with databases. If you want to find out more about SQL databases (shameless self promotion begins) I just finished the storage chapter for Introducing HTML5, which I’m writing with fellow Doc Bruce, so check that bad boy out too!

Demos

Share and Save:

Introducing Web SQL Databases originally appeared on HTML5 Doctor on February 24, 2010.

dd-details wrong again

Remy Sharp — Mon, 12 Oct 2009 12:00:57 +0000

You may recall that I blogged about legend not being so legend as the heading element for details or figure. After enough noise was made the spec was changed so that the heading and contents of these elements can now be marked up using the dt/dd combo.

Although not immediately obvious why it’s the right choice, it appeared to work for our needs…at first. Of course now, it’s been discovered that it’s actually a pretty bad idea.

How we got here

In short, details and figure solve a common design pattern and provide nice new semantic tags to solve that problem. A figure could be an image you’re referring to in an article or chapter of a book, and the details element allows the user to interactively show and hide the details of some piece of information.

Both elements can contain a heading element to label up the contents. For some reason, beyond this author’s understanding, these two elements, completely different in meaning, have been historically tied to using the same solution solve the problem how to markup the heading.

As I mentioned earlier, originally the proposed solution for the headings was to use the legend element, which proved to completely break in every browser (in new and interesting ways).

Skip forward to mid-September, and Jeremy Keith proposes that we solve the legend issue with the dt/dd combo, and Ian Hickson says:

That’s not a bad idea actually. Ok, done.

Before this was proposed there was lots of discussion about why we couldn’t introduce a new element to solve this problem, and Ian points out already 18 (or 22, I forget!) elements that represent some sort of heading. This is the argument for not introducing another new heading type element to solve the details and figure problem.

The problem with dt/dd

Ironically the problem isn’t with the dt part of the solution, it’s actually with the dd.

Dean Edwards (genius behind some very cool JavaScript and something that will soon blow your minds) has been testing these elements in detail and found a very serious issue with the dd in, guess what, IE6 & 7. I want to explain and draw attention to what Dean has found.

Styling a dd within details or figure (and probably other elements) bleeds to the next element.

By styling a dd red, and only the dd, here’s what it should look like (and does in IE8):

Where as in IE7 (and IE6), the red style bleeds in to the following p element (note the “this paragraph shouldn’t be red”):

![dd styled in IE7](

What’s more, if you look back at the screen shots you can see the last paragraph says “Contents of first

”. The result of that test is being generated by the following JavaScript:

document.getElementsByTagName('dd')[0].innerHTML

Notice how in IE7, the contents of the first dd’s innerHTML is empty.

The problem here is that:

IE7 and below can’t style a dd properly without it breaking and the style bleeding in to adjacent elements.
JavaScript, randomly, can’t see the contents of the dd.

Is there hope?

There is a hack that fixes this issue. It’s pretty mad, but it does fix the styling issue. However the side effects from this hack are outright unacceptable and are so serious I would argue that the hack solution itself is a bug.

The hack is over at the public-html of W3.org, and involves stuffing an open object tag just before we close the head tag.

This isn’t a clean solution for including in HTML by hand, authors won’t remember or might get it wrong, so it needs to be perhaps automated as part of the HTML5 enabling script, right? It would have to be inserted using document.write() as the last part of the head element.

Dean went on to test this, and he found:

There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the . If there are any scripts following the document.write() then they are not executed.

The really freakin’ important bit:

If there are any scripts following the document.write() then they are not executed

So, to answer the question: is there hope? No, not for the dd/dt combo. It can’t be styled properly and hacks will break JavaScript.

We want the details

We, as authors, want to make use of details and figure today. Waiting for IE7 to fall out of circulation before we start using these elements (as it’s been proposed a number of times on the IRC channel and mailing boards) is outright not going to happen. IE6 & 7 are going to be around for a good more number of years, certainly IE7 (IE6 has at least another 5 years in the beast).

We are going to start enabling the details interactive UI pattern using JavaScript whilst we wait for vendors bake it in to the browser, so the final proposed markup needs to work in all the browsers, including IE6 and IE7.

What are our current options?

Give new meaning to an existing element (as we’ve already tried to), legend, label and dt/dd have been tried, tested and failed. What else could we use?
Repurpose one of the existing new elements (keeping in mind that the dt/dd was repurposed so it should be a consideration).
Create another heading element to solve this problem.

The problem is that the conversation seems to have lost steam (or certain Dean was starting to see the conversation go in circles). If you want to see these two elements make it the final spec, and correctly, head over to either the IRC channel or the mailing list, and get heard.

Reference links

Dean’s original details test (my modified tests to fire the innerHTML on load: details, figure)
Litmusapp browser screenshots of the results: details, figure
whatwg mailing list thread: September, October
Related Posts:

Share and Save:

dd-details wrong again originally appeared on HTML5 Doctor on October 12, 2009.

September HTML5 spec changes

Remy Sharp — Thu, 17 Sep 2009 12:00:20 +0000

September being one month before the HTML5 spec goes to last call in October, there’s been a few significant changes to the HTML5 spec that we wanted to briefly share with our patients.

Clarification over `section` and `article`

The spec has been clarified to help authors correctly choose between when to use section and when to use article, and Bruce’s section post has also been updated.

`footer` now works like `header`

This was a big one and causing confusing to people coming to HTML5 for the first time. Originally you couldn’t include a nav element inside a footer, or a section.

Now the spec has been changed to match the header element.

`details` and `figure` saved

Instead of using legend, which didn’t work, Jeremy suggested (although slightly tongue in cheek) to use dt for the title and dd for the body. Ian Hickson agreed, and it’s in

Example:


 
 
Exhibit B. The Rough Copy trailer.

`aside` has better examples

The documentation has been updated to specify better examples of how the aside element can be used.

Better examples help us authors understand how it can be used.

Dropped Elements

The following elements have been dropped from the HTML5 spec (though bb and datagrid were some time ago, and datagrid has been postponed rather than dropped entirely):

dialog
bb
datagrid

Ch-ch-changes

We’ll be posting in more detail about some of these changes, and as further changes come out of the editing process we’ll no doubt keep you all up to date, either via our Twitter account (which you should follow) or feel free to let us know too!

Share and Save:

September HTML5 spec changes originally appeared on HTML5 Doctor on September 17, 2009.

Legend not such a legend anymore

Remy Sharp — Fri, 31 Jul 2009 12:00:26 +0000

Lately I decided I was going to recreate the interactive features of the details element using JavaScript (apparently the same day as fellow Brightonian Jeremy Keith).

However I ran in to some very serious issues with the tag, so serious, in it’s current state, it’s unusable.

Overview of the details element

The details element, by default, is a collapsed element whose summary, or label, is the first child legend (if no legend is used, the UA provides a default, such as “Details”), with a triangular button to indicate it’s current open state.

If you include the open attribute, then the element is open by default. In theory, you could attach a click event to the legend, and switch the open attribute.

The markup would roughly be this:


  Terms & Conditions
  You agree to xyz, etc.

Here’s the details test page I was working from: HTML 5 details test

The issues

The biggest problem, and the show stopper for me, is that the browser’s treatment of the legend element completely breaks this markup pattern – this is true for all the major browsers: Opera, Safari, Firefox and IE (tested in all the latest and some older browsers). I’ll go in these issues in detail in a moment.

Legend treatment

Surprisingly Firefox is the worst one out in these issues, the rest of the browsers have fairly same treatment of the issue. In the screenshots, I’ve included a fieldset and nested legend for reference.

Internet Explorer

IE7 & IE8 closes the legend element it encounters when it’s not inside a fieldset element and move it’s contents out to an adjacent text node.

What’s also strange, is that looking at the DOM it also creates another empty(?) closed legend element after that text node. It doesn’t have any effect, but just looked odd:

Opera

Opera (9 & 10b) is very similar to IE in it’s treatment of the legend in the details element, except it doesn’t create the second closing legend node. It just closes the legend, and creates the adjacent text node.

Safari

Safari simply strips the legend all together out of the DOM. So much so, that if you open the web inspector, then the error console, you’ll see it warning out that it’s encountered an illegal element, ignoring it, then encountering the closing tag, so it ignores that too. You’re left with just the text node.

Firefox

The best for last. Firefox goes one step beyond the other browsers. It assumes you’ve forgotten to include the fieldset element. So when it hits the legend element, Firefox inserts an opening fieldset up until it finds (I believe) the closing fieldset element, which obviously it doesn’t so the result is the rest of the DOM, after the first illegally placed legend ends up eaten by fieldset element, which leaves my DOM in a mess:

Impact on other elements

details isn’t the only element that reuses the legend element for labelling, the figure element also is supposed to support the legend element. The result is obviously going to be the same.

Conclusion

We can’t style the legend element when the text is being thrown out by all the browsers, and Firefox’s DOM mangling is just too painful to look at.

This basically means that we can’t, in any reasonable amount of time, use the legend element inside both the details and figure element in the spec’s current state.

For me, I’ll be using an alternative element, probably just a p element styled to look like a legend, but that’s really not the point. Ideas anyone?

It turns out we weren’t the only ones looking at this and Ian Hickson has responded on the issue:

My plan here is to continue to wait for a while longer to see if the parsing issues can get ironed out (the HTML5 parser in Gecko for instance solves this problem for Firefox). If we really can’t get past this, we’ll have to introduce a new element, but I’m trying to avoid going there.

It’s fine to think that Gecko will update, but it’s IE that I’m worried about, they won’t turn out their render engine, and the result is we’ll have to avoid using the legend in any element other than fieldset.

Share and Save:

Legend not such a legend anymore originally appeared on HTML5 Doctor on July 31, 2009.

Accessibility & Native Drag and Drop

Remy Sharp — Thu, 23 Jul 2009 13:30:32 +0000

A few days before my native drag and drop article came out Gez Lemon wrote about accessibility in drag and drop, and touched on HTML 5.

I then promised to look at implementing accessibility with native drag and drop, and here’s my findings.

ARIA Support

This was quite easy to add, though only by following Gez’s article. Since I already had events for drag start, I just needed to add drag end to clean up and remove the ARIA effects.

I added the following to the dragstart event:

addEvent(dragItems, 'dragstart', function (event) {
  // via ARIA say the element has been grabbed
  this.setAttribute('aria-grabbed', 'true');
  // code continues...

The added a new dropend event:

addEvent(dragItems, 'dragend', function (event) {
  // remove the ARIA grab attibute when we're not dragging
  this.setAttribute('aria-grabbed', 'false');
});

The effectAllowed and dropEffect combo was difficult to work out at first, though probably because I was playing with link and reference, whereas I should have been playing with move or copy. That said, a note about move and copy, move is a type of copy, with a clean up function to delete afterwards. Once I had this combo correct, the drop effects worked.

The changes required were to:

On drag: on all the drop targets add: setAttribute('aria-dropeffect', 'copy')
On drag: set the allowedEffect on the drag event: event.dataTransfer.effectAllowed = 'copy';
On drop: say what we’ll accept: event.dataTransfer.dropEffect = 'move';
On dragend: remove the drop effect from the drop targets: removeAttribute('aria-dropeffect')

The big problem for me was that I couldn’t truely test this.

Update: between the time I had finished my code and writing this article, NVDA (the Windows open source screenreader) announced that they recieved support from Yahoo!, and that ARIA drag and drop support is in their development roadmap.

The full working version of native drag and drop with ARIA support is available here: native drag and drop with ARIA support (source code)

Keyboard Support

Keyboard, sadly, is a whole different story.

I was able to replicate a lot of the keyboard features that Gez included in his demo. This included setting the tabIndex = 0 to allow the elements to tab to (superb trick by the way), included highlighting the drop targets as we drag.

However, the problem was: I wanted the user to be able to start the drag operation using the keyboard. Initially looking at the spec I couldn’t see that it was supposed to be supported (which it turns out, it is).

I started going down the path of using the keyboard to trigger drag events. I was able to replicate the drag event being triggered from the keyboard (like space starts the event), however, and this is a biggie, I couldn’t replicate the dataTransfer object. I tried faking it. I tried giving it nothing. I tried all kinds of random attempts to trick the browser in to giving me the object. It’s a no goer.

As it turns out, there is keyboard support written in to the spec (though in my personally opinion it’s not completely obvious to an author reading). The drag and drop operations should work like a copy and paste operation.

This is very clever, and I like it. Tab round to the dragable element, copy using the keyboard, which triggers the dragstart event, which I can then add classes to the drop targets, and make them tabbable. The user then tabs round to the drop targets, and pastes. This triggers the drop event and we’re all good.

No browsers support this keyboard event model.

I’ve raised bug for Mozilla and Webkit. They’ve both had comments on, and in both cases I’m not 100% sure what the comments mean, but speaking to the people involved via IRC, they’ve both said if it’s in the spec, it should be in the browser.

Let’s hope they do something about it. Now, how do I report a bug in IE…?!

Share and Save:

Accessibility & Native Drag and Drop originally appeared on HTML5 Doctor on July 23, 2009.

2022, or when will HTML 5 be ready?

Remy Sharp — Tue, 21 Jul 2009 14:19:00 +0000

Aside from being the year Queen Elizabeth II will celebrate her Platinum Jubilee, assuming she’s still kicking around, 2022 is the year that’s been inappropriate linked with HTML 5 in the minds of a lot of our community.

I understand why someone might think that, but it’s wrong. 2022 was misinterpreted as the year HTML 5 would be ready. That’s wrong. HTML 5 is ready today.

In an interview by Tech Republic, for a techie audience, Ian Hickson, the editor of the HTML 5 working draft, was asked to give a timeline of the HTML 5 recommendation.

One date should have come out of that interview, but another, much further away did instead: 2022 – the date of the final proposed recommendation, which actually translates to:

require at least two browsers to completely pass [HTML 5 test suites]

Let’s put this in context of another spec that has taken a very long time: CSS 2.1.

CSS 2.1 is CSS that I’m certain you’re familiar with. I’m certain you use it day to day without any thought as to whether it’s a completed spec.

It’s been in development for over 10 years, and it’s only just become a candidate recommendation (23rd April 2009).

That said, it doesn’t have two browsers completely supporting it. Only Internet Explorer 8 supports the full CSS 2.1 spec.

Did that stop you from using CSS 2.1? I suspect not. Will that stop us from using HTML 5? It certainly shouldn’t. HTML 5 is available and ready to be used today.

What is the important HTML 5 date?

October 2009.

This October is the last call for the HTML 5 working draft.

That means, that issues with the spec, enhancements, bugs, anything, it all needs to be in and submitted and written in to the spec for October this year (it can go through reiterations, the this is the main deadline).

The WHATWG is completely open for anyone to contribute their ideas and suggestions.

You can sign up to the mailing lists, look through the backlog of mailing list. You can communicate directly using IRC and there’s even a complete log of all the IRC history. All available from http://whatwg.org.

Share and Save:

2022, or when will HTML 5 be ready? originally appeared on HTML5 Doctor on July 21, 2009.

HTML5 Boilerplates

Remy Sharp — Fri, 17 Jul 2009 13:30:45 +0000

Without going into the discussion of why HTML 5 is available today and not 2022, this article is going to give you a series of HTML 5 boilerplates that you can use in your projects right now.

HTML 5 in 5 seconds

It’s über easy to get your markup to validate as HTML 5 — just change your DOCTYPE from whatever it is now to this:

That's it! It doesn't require anything more than that.

Google are doing it already. Check out their homepage, written all in one line:

HTML 5 - Google Search

Note: the included h5utils.js script is a small library to trigger HTML 5 elements and to give me cross browser event binding.

Currently the elements can be dragged, but they can’t be dropped (this is the browser’s default).

To drop elements we need to:

Tell the browser that the element can be dragged over a specific point
Handle the drop event

To tell the browser we can drop in this element, all we have to do is cancel the dragover event. However, since IE behaves differently, we need to do the same thing for the dragenter event.

Here’s the code for basic drop handling:

var drop = document.querySelector('#drop');

// Tells the browser that we *can* drop on this target
addEvent(drop, 'dragover', cancel);
addEvent(drop, 'dragenter', cancel);

addEvent(drop, 'drop', function (event) {
  // stops the browser from redirecting off to the text.
  if (event.preventDefault) {
    event.preventDefault();
  }

  this.innerHTML += '' + event.dataTransfer.getData('Text') + '';

  return false;
});

function cancel(event) {
  if (event.preventDefault) {
    event.preventDefault();
  }
  return false;
}

Note for this code, I’m using addEvent where you’d normally see element.addEventListener, it’s from the h5utils.js library to support IE.

In the JavaScript we are:

Searching for the drop target in the DOM using document.querySelector (which returns the first result only)
When dragover event is fired (when the user drags the element over another), it will trigger the function called ‘cancel’ (at the bottom of the code above) which will prevent the default browser action
Do the same for dragenter to support IE
Bind the drop event, and within there grab some data about what was dropped.

dragover & dragenter

By cancelling this event, we’re telling the browser this element that we’re over is the one you can release and drop upon.

I’m still not entirely sure why there’s a difference here, but Firefox and friends needs preventDefault on the event, and IE requires the return false. Note that the examples out in the wild that use inline JavaScript (yuk, bad), the preventDefault is supposed to be implicit, so you won’t see it in the code.

drop

To show what was dropped, we need to do two things:

Cancel the default browser action. This is to ensure that if we drop a link, the browser doesn’t go off and surf to that location
Get the contents out of the dataTransfer object

The cancelling of the browser default is, again, done using the preventDefault and return false.

If we don’t set the dataTransfer data manually (which I’ll show you later), the default key is set to Text. So this might be the value of an href of an element, or it might be src address.

Doing More with Drag’n Drop

There’s a number of extra bits in the spec other than just dragging images.

Here’s a few bits that I can see being useful:

Being able to drag any element
More complex data types, other than text
Set a different drag icon/image when dragging the element

Dragging Anything

If we change the to

tags with background images, I still want to be able to drag them around the page, and drop them in to my container.

The HTML 5 spec says it should be as simple as adding the following attributes to the markup of the elements in question:

draggable="true"

However, this doesn’t work completely for Safari or Firefox.

For Safari you need to add the following style to the element:

[draggable=true] {
  -khtml-user-drag: element;
}

This will start working in Safari, and as you drag it will set a default, empty value with the dataTransfer object. However, Firefox won’t allow you to drag the element unless you manually set some data to go with it.

To solve this, we need a dragstart event handler, and we’ll give it some data to be dragged around with:

var dragItems = document.querySelectorAll('[draggable=true]');

for (var i = 0; i < dragItems.length; i++) {
  addEvent(dragItems[i], 'dragstart', function (event) {
    // store the ID of the element, and collect it on the drop later on
    event.dataTransfer.setData('Text', this.id);
  });
}

Here’s a working demo of drag and drop anything (source code)

More Complex Data Types

You’ve already seen how we can use dataTransfer.setData(format, string) to associate some data in the example above.

You can also use this key/value pair to store more data, but you’re limited to storing strings only.

One way I would get around this is to have a data lookup, where the key of the lookup may be the ID of the element, and then I can de-reference the data on the drop event.

For example:

var people = {
  rem : {
    name : "Remy Sharp",
    blog : "http://remysharp.com"
  },
  brucel : {
    name : "Bruce Lawson",
    blog : "http://brucelawson.co.uk"
  }
  // etc...
}

var dragItems = document.querySelectorAll('[draggable=true]');

for (var i = 0; i < dragItems.length; i++) {
  addEvent(dragItems[i], 'dragstart', function (event) {
    // store the ID of the element, and collect it on the drop later on
    event.dataTransfer.setData('Text', this.id);
  });
}

addEvent(drop, 'drop', function (event) {
  // stops the browser from redirecting off to the text.
  if (event.preventDefault) {
    event.preventDefault();
  }

  var person = people[event.dataTransfer.getData('Text')];

  this.innerHTML += '' + person.name + '';

  return false;
});

Here’s a working demo of drag and drop with associated data (source code)

Obviously this isn’t the most ideal situation, but there’s also the possibility to set other content types in the drag data, which should produce some interesting apps in the future.

Drag Icon

Along with several other options with the dragstart event, you can also set a drag image, i.e. what you see under your cursor.

You can create a DOM fragment, and then associate the fragment with the dataTransfer using setDragImage(element, x, y).

So we can add the following to our example to use a custom drag image:

var dragIcon = document.createElement('img');
dragIcon.src = 'http://twivatar.org/twitter/mini';

Which creates an image element, and how within the dragstart event, we’ll set the drag image:

addEvent(dragItems[i], 'dragstart', function (event) {
  // store the ID of the element, and collect it on the drop later on
  event.dataTransfer.setData('Text', this.id);
  event.dataTransfer.setDragImage(dragIcon, -10, -10);
  return false;
});

This sets the custom drag icon 10 pixels below the cursor, as seen in this example: drag and drop with custom image (source code)

Native Drag

There’s lots of Drag and Drop JavaScript libraries available, but what I’d like to see, is native DnD support falling back to library based. However, I know for a fact that some libraries, including jQuery, construct a custom event when passed in to the event handler which means, currently, you can’t use the dataTransfer object, so you’ll have to rely on binding the events yourself. I’m sure this will change soon.

There’s lots more in Drag and Drop but this should be enough to go and play with now!

As for me, I'll be updating the Drag and Drop demos on HTML5demos.com to see if I can add ARIA support and capture a screencast of it running. Watch this space!

Further Reader

Share and Save:

Native Drag and Drop originally appeared on HTML5 Doctor on July 9, 2009.

How to get HTML5 working in IE and Firefox 2

Remy Sharp — Sat, 20 Jun 2009 08:05:45 +0000

HTML 5 may be the latest and greatest technology, but some browsers don’t have native support for the new semantic elements. Let’s momentarily forget about the really sexy functionality, like full control over the element, and just focus on getting the elements rendered.

The problematic A-grade browsers include IE 8 and below, Firefox 2, and Camino 1 (these last two browsers both use the Gecko rendering engine, which is why they’re both affected).

Let’s start with Internet Explorer.

IE doesn’t believe in HTML 5 elements

Quite simply, IE doesn’t even see HTML 5 elements, much less style them.

This is actually the same issue that we had before HTML 5, where the element couldn’t be styled in IE 6, resulting in all manner of workarounds. (Let me add that we’ll also fix the element while we convince IE to recognise HTML 5 elements).

The fix

There is hope! The trick, discovered by Sjoerd Visscher, is simply to create the new element using JavaScript, and voilà, IE is able to style it:

document.createElement('header');

John Resig has also written about this HTML 5 shiv.

For example, say you wanted to style the element in italics:




  Header test
  


  my birthday

This screenshot shows the rendering in IE before we apply the fix:

To apply the fix, add the indicated line of code:




  Header test
  
  
  
  


  my birthday

Now after we’ve applied the fix, it’s correctly styled in IE:

One hit solution

For everyone’s convenience, I wrote a single JavaScript file that can be included to create all the HTML 5 elements (and the element) for IE.

Download the IE HTML 5 enabling script

Include the script in your tag, and you’ll be able to style the elements appropriately in IE:

Note that I’ve used a conditional comment to only apply this to IE 8 and below. It’s my hope that IE 9 and onwards will support HTML 5 elements, but when that day comes, make sure to double check the conditional!

Conditions & Gotchas

There are a couple of things to be aware of when using the HTML 5 shiv.

JavaScript required

This obviously means that your design now depends on JavaScript. Personally, I feel that if you’ve used semantic markup for your site and the elements can’t be styled, the content is still completely readable.

Here’s a screenshot of the Full Frontal web site, written using HTML 5 elements, rendered in IE with and without JavaScript enabled:

You can see in the second screenshot that the content isn’t perfect, but it’s still readable — it cascades down correctly, much as if CSS were disabled.

A little head is always good

If you create the new element and don’t use a tag (which is perfectly valid HTML 5), IE will put all those created elements inside the tag. Pretty crazy, but you can easily avoid this by always using both the and tags in your markup. Leif Halvard explains further with demos.

Firefox 2 and Camino 1 rendering bug

Both Firefox 2 and Camino 1 have a bug in the Gecko rendering engine (specifically versions prior to 1.9b5):

Firefox 2 (or any other Gecko-based browser with a Gecko version pre 1.9b5) has a parsing bug where it will close an unknown element when it sees the start tag of a “block” element p, h1, div, and so forth.

According to the W3 Schools stats, Firefox 2 only has around 3% of the market — perhaps low enough to justify ignoring it. It’s safe to assume that Camino 1 commands an even smaller percentage of the market.

By ignoring this issue, however, a site can look quite bad in these browsers. So how can we fix it?

The bug surfaces when Gecko doesn’t recognise an element. Explained roughly, when Gecko parses an unrecognised element, it removes the element’s contents and puts them next to the element.

Take, for example, the following code:


  Title
  ...

This will be parsed in Gecko (prior to version 1.9b5) as if the markup were actually as follows:


  
  Title
  
  ...

The visual result is similar to the above screenshot of IE running without JavaScript (though subtly different, as the DOM tree is actually in a different order than you as the author intended).

The fix

There are two approaches to fixing this issue, and so far I've only successfully used the non-JavaScript approach.

The JavaScript solution

The first approach is to use JavaScript to traverse the DOM tree, rearranging elements as issues are encountered. Simon Pieters has a small working example of how this can be done (towards the bottom of the page). In practise, however, I personally found it didn't work for my markup. The problem is definitely solvable using JavaScript, but this solution still needs work to handle all permutations of markup.

The XHTML solution

The second approach is to serve Gecko XHTML. I've found this to be the easier approach if you're either generating a page dynamically (using something like PHP) or if you can create your own .htaccess file to use Apache's mod_rewrite.

The first change to your markup is to add the xmlns attribute to your tag:

Next, we need to sniff the user agent string (typically a bad approach, but justifiable when targeting such a specific group of users). If the Gecko build is less than 1.9, then we need to set the Content-type header to application/xhtml+xml.

If you want to use mod_rewrite in an .htaccess file (or the httpd.conf file), you need the following rules:

RewriteCond %{REQUEST_URI} \.html$
RewriteCond %{HTTP_USER_AGENT} rv:1\.(([1-8]|9pre|9a|9b[0-4])\.[0-9.]+).*Gecko
RewriteRule .* - [T=application/xhtml+xml]

This rule sends the proper Content-type header to all Gecko based browsers where version is less than 1.9, or "rv:1.9pre" or "rv:1.9a" or "rv:1.9bx" where x is less than 5.

If you don't want to use the mod_rewrite approach, you'll need to manually send the header in your server side scripts. Here's a solution for a PHP script:

if (preg_match('/rv:1\.(([1-8]|9pre|9a|9b[0-4])\.[0-9.]+).*Gecko/', $_SERVER['HTTP_USER_AGENT'])) {
  header('Content-type: application/xhtml+xml');
}

This snippet needs to be included before anything has been printed by your script — i.e., as early as possible.

Gotcha: Yellow Screen of Death

The Yellow Screen of Death shows up whenever there's an XML error on the page. If we're serving markup as XML and telling the browser to interpret it strictly as XML, then we can't serve any characters it doesn't recognise or else it's going to bork:

Below are a few ways to avoid XML parsing errors.

Create strict markup

You need to ensure your markup is squeaky clean — but that's easy, because you're already a Markup Jedi, right?

Use XML entities

HTML entities are a no-no. Sorry, but • isn't going to fly anymore. You need to use XML entities, the numerical representation of these characters.

I've built an entity lookup tool that shows the HTML entity and the XML value of that entity. For example, • is 8226, so the XML entity is •.

Sanitise user generated content

If your site relies on any user generated content (e.g., blog comments), then you need to sanitise the output to ensure there are no validation issues to trigger the Yellow Screen of Death.

This issue alone may justify further investigation of a JavaScript solution.

Worth the trouble?

All that said, Firefox has a very good automated upgrade path. Looking at the stats on W3Schools, it's safe to say that the number of users with this Gecko bug is rapidly diminishing.

HTML5 Doctor » Remy Sharp

Introducing Web SQL Databases

What’s in the box?

Creating and Opening Databases

Estimated database size

Versions

Transactions

executeSql

Demos

Related Posts:

dd-details wrong again

How we got here

The problem with dt/dd

Is there hope?

We want the details

Reference links

Related Posts:

September HTML5 spec changes

Clarification over section and article

footer now works like header

details and figure saved

aside has better examples

Dropped Elements

Ch-ch-changes

Related Posts:

Legend not such a legend anymore

Overview of the details element

The issues

Legend treatment

Internet Explorer

Opera

Safari

Firefox

Impact on other elements

Conclusion

Related Posts:

Accessibility & Native Drag and Drop

ARIA Support

Keyboard Support

Related Posts:

2022, or when will HTML 5 be ready?

What is the important HTML 5 date?

Related Posts:

HTML5 Boilerplates

HTML 5 in 5 seconds

dragover & dragenter

drop

Doing More with Drag’n Drop

Dragging Anything

More Complex Data Types

Drag Icon

Native Drag

Further Reader

Related Posts:

How to get HTML5 working in IE and Firefox 2

IE doesn’t believe in HTML 5 elements

The fix

One hit solution

Conditions & Gotchas

JavaScript required

A little head is always good

Firefox 2 and Camino 1 rendering bug

Title

The fix

The JavaScript solution

The XHTML solution

Gotcha: Yellow Screen of Death

Create strict markup

Use XML entities

Sanitise user generated content

Worth the trouble?

Further reading

Related Posts:

Clarification over `section` and `article`

`footer` now works like `header`

`details` and `figure` saved

`aside` has better examples