Everyone who’s ever messed around with dates knows that they are terribly user-hostile — not only for software developers, but also for users. True, users will be able to tell you their date of birth or today’s date without trouble, but ask them to fill them out in a web form and they will encounter problems.

Month first, day first, or year first? And what about slashes, dashes, and other separators? Usually the website engineer has a strong personal preference and enforces it religiously upon unsuspecting users with stern and incomprehensible error messages in a lurid shade of red that are too tiny for anyone over 25 to read.

(This article was originally published on Samsung Internet’s Medium channel. Since I do not believe Medium will survive in the long run I re-publish it here.)

continue reading

During my research of modern input types such as email, date, and number I stumbled upon the Hello World JavaScript detection technique. After fairly extensive testing I concluded that it should be added to the customary type === 'text' detection, mostly in order to cater to Android WebKit, although it also solves a few other problems.

continue reading

From last Thursday to earlier today I held a simple one-question poll about which advanced input types such as date and number web developers are using.

The results are surprising, while I expected date and number to end in first and second place, the most popular type was actually email.

continue reading

Yesterday Mark Zuckerberg said (paraphrased):

The biggest mistake we made as a company was betting too much on HTML5. While building native apps that were basically just a wrapper for the mobile web standard let it experiment quickly, it made the apps run way too slow. We burnt two years.

Two quick notes:

1. This seems to be not about HTML5 as a whole, but specifically about Android. And the Android 2.x default browser is just not very good. I wouldn’t want to create a cutting-edge HTML5 app on Android 2.
2. You can’t use the web to emulate native. You should use the web in a webby way. Which I guess means a simpler interface with less flourishes.

So all in all, this remark doesn’t say as much as you’d think; only that Facebook will switch from web to native on Android because the Android browser does not allow web to emulate native.

But will they also create BlackBerry, Windows Phone, Symbian, bada, and S40 apps? I think not.

BTW: here is the full quote. Facebook to forget about HTML5? Nah.

Oh, and one reason Zuckerberg said this is because investors want to hear this. Investors are a bunch of clueless people who only run after buzzwords, and Facebook’s delicate position on the stock market makes it necessary to placate them.

On Monday and Tuesday I did some heavy-duty research into the new HTML5 input types and attributes, and I published a desktop and a mobile compatibility table.

Let’s start with some good news. The readonly attribute, which makes a form field read-only, is supported by all browsers, both mobile and desktop. Even IE9. Cool, huh?

The rest of the input story is worse. Much worse. Let’s put it like this: Obigo WebKit, a browser nobody but me has ever heard of, outperforms iPhone and Android.

continue reading

Months ago I concluded that “HTML5” means whatever you want it to mean. This week, Jeffrey Zeldman and Jeff Croft took up the discussion, with Tantek Çelik and Bruce Lawson commenting.

continue reading

A while ago I asked what HTML5 means to you. I got a lot of replies, but would like to gather more. That’s why I’m repeating the question today. What’s in your HTML5 spec? Please add your personal top three of cool new features to the comments.

continue reading

Right now nobody’s interested in a mobile solution that does not contain the words “iPhone” and “app” and that is not submitted to a closed environment where it competes with approximately 2,437 similar mobile solutions.

Compared to the current crop of mobile clients and developers, lemmings marching off a cliff follow a solid, sensible strategy. Startling them out of this obsession requires nothing short of a new buzzword.

Therefore I’d like to re-brand standards-based mobile websites and applications, definitely including W3C Widgets, as “HTML5 apps.” People outside our little technical circle are already aware of the existence of HTML5, and I don’t think it needs much of an effort to elevate it to full buzzwordiness.

Technically, HTML5 apps would encompass all websites as well as all the myriads of (usually locally installed) web-standards-based application systems on mobile. The guiding principle would be to write and maintain one single core application that uses web standards, as well as a mechanism that deploys that core application across a wide range of platforms.

continue reading

Last Friday I found evidence for increasing confusion about what the HTML5 spec actually is. I don’t have any doubts on that score: HTML5 is anything you want it to be as long as it’s new and cool.

continue reading

After spending about a day and a half in testing I am forced to conclude that the HTML5 drag and drop module is not just a disaster, it’s a fucking disaster.

The module should be removed from the HTML5 specification straight away, and conforming browsers should disable it at their earliest opportunity pending a complete rewrite from the ground up.

Web developers MUST NOT (in the sense of RFC 2119) use HTML 5 drag and drop. They should use old-school scripts instead.

Before we continue I’d like to say that in general I thoroughly approve of the HTML5 specification. Exactly because the spec has such an overall quality I was so surprised (and, frankly, a bit confused and hurt) to find drag and drop a steaming pile of bovine manure.

In fact, it’s so outrageously bad that I’ve gone on strike. I refuse to do any more research on drag and drop. Go do it yourself. Or don’t bother. Whatever. I don’t care.

What follows is a rant laced with profanity. No apologies. Drag and drop deserves no better.

continue reading

I have started an HTML5 compatibility table today. For now it only contains a test of HTML5 Storage in all desktop browsers, and a short report is in order. I also retested the DOM HTML; no changes.

continue reading

The HTML 5 spec introduces the <time> element to mark up a date or time. Although I support the inclusion of these semantics in HTML, I believe that the current specification of the <time> element is vague because it avoids the question whether the element is safe for historians. Right now it hurts historical research more than it helps. In this entry I’ll explain why.

Although I will concentrate on the HTML5 syntax here, what I have to say also applies to the microformats datetime design pattern. The Microformats site adds one important detail to the discussion that the HTML5 spec overlooks: the point of having a <time> element (or a datetime design pattern) at all:

Use the datetime-design-pattern to make datetimes that are human readable also formally machine readable.

Who needs machine readable dates? As far as I can see there are two target audiences for this operation. The first is obviously social applications that have to work with dates, and where it can be useful to compare dates of two different events. An app must be able to see if two events fall on the same day and warn you if they do.

However, as a target audience social applications are immediately followed by historians (or historical, chronological applications). After all, historians are (dare I say it?) historically the most prolific users of dates, until they were upstaged by social applications.

This raises the question whether the <time> element should be tailored for historical use at all. When I started writing this entry I was convinced that it should.

In keeping with the definition of its purpose I the see the <time> element as a tool for an Internet-wide chronological search-and-compare system. Such a system will be a boon to historians, who would be allowed to quickly and easily look up events that happened around the same time as the event they’re writing about.

In history, just as in other academic disciplines, serendipitous discoveries are the meat of exciting new theories. A history-compliant use of the <time> element that allows automatic search and compare would broaden the horizons of historians.

However, now that I’ve reviewed some of the more common problems that have to be solved in order to decrease potential harm, I’m starting to doubt whether the <time> element can easily be made to fit history.

Right now, though, the specification is a vague compromise that doesn’t make the <time> element useful for historical research, but still allows it to be used historically.

I feel this ambiguity should be removed. I feel that the specification should clearly state whether the <time> element is meant for historical use or not. The current vague, implied “No” should be changed to a clear answer. I prefer Yes, but I can live with No.

If the <time> element should be made safe for historians, there’s quite a bit of work to be done; some of which is discussed in this article. If it should not be made history-safe, we have to add a cut-off date to the specification. Dates before this cut-off date would be ignored.

continue reading