HTML5 makes the world much better. At least in general.

One of the nice features of HTML5 is the possibility to give input fields a type-attribute, which helps browsers determine what kind of input the field is supposed to accept. The Browser can then use this info to both validate input and suppress form submission if the input doesn’t match, but also to offer some additional help for input of valid data. This is especially nice for mobile devices where the device can switch to an appropriate keyboard or show some fancy date input widgets.

But in some cases, this does not fit well with what jQuery (or, I am sure, any other JavaScript Library) provides to enable such things for older as well as current browsers.

The latest nicety I came across was the combination of jQueryUIs datepicker and Chrome’s datepicker when a text input is defined as type=”date”.

This exact combination causes several problems:

  1. You get two datepickers: one from Chrome and one from jQuery. Chrome renders its activation button for the datepicker into the input field, and jQuery renders an additional button right after the input field. So at least the user can choose which one they’d like to use. Of course they’ll be irritated.

    Two datepickers are one too much
    Chrome and jQuery both want to help you enter dates, and the user can even chose who they want to be supported by. In German there is a saying: Too many cooks will spoil the mash…
  2. For some reason, Chrome renders a placeholder text into the text input field, no matter if I sent a valid String as value from the server side (a Smalltalk/Seaside Application in my case), and only if you select a date in one of the two datepickers, you see an actual date in the input field

It is things like this that makes it a hard requierement to test you web application in all browsers that you want to support. And by “all” I really mean all-damnit-%&$%&$ing-versions-of-all-kinds-of-browsers-you-want-your-application-to-look-and-feel-good-on.

Forget about jQuery and cross-browser and one-javascript-to-tame-them-all. It’s all bloody stupid marketing-speak.

So what do we learn from that?

  • Be prepared to find tricky little problems with Ajax / jQuery on some version of some browser that don’t show up anywhere else. You may have tested this stinkin page on IE, FF and Chrome, but be sure that the one Browser you forgot to also test it on can break the whole thing. Sometimes, it is something you may have seen, but never paid attention to, but it will come back as a trouble ticket.
  • Be prepared to accept a looong test period in which you constantly hunt for impossible bugs that can only be reproduced in Version 19.5.105 of Browser X.
  • Be prepared to either make compromises or spend double the estimated time on seemingly irrelevant problems that do not really affect your functionality, but look ugly or are possibly irritating for your users.
  • Always resist equating JavaScript with portability or cross-platformness. You’ll be punished for it, believe me.
  • Forget about the 21st century. We’re back in the mid-80ies.

(Sorry for this post, but I am a bit frustrated today)

4 thoughts on “Chrome, HTML5 and jQuery – welcome to the 21st century

  1. Welcome to world of web development/debugging. At least the upcoming “K****lino” will have more (internet) audiance than writing it as a rich client 😉

    1. Torsten,

      thanks for the link. Actually what I did was to remove type=”date”, because I don’t like to add even more javascript code to the pages, and my server does validation anyways for all cases…

      My complaint is not so much about this one problem, but about the fact that these tiny things cost lots of time and effort, and sometimes it seems like there is no way to do it right – you’ll always lose something…


Comments are closed.