A Form of Madness - Dive Into HTML5(diveintohtml5.org)

http://diveintohtml5.org/forms.html

26 comments

Kind of tangential, but I love Dive Into HTML5's style and tone. It's up there with Why's Poignant Guide to Ruby and Learn You Some Erlang for Great Good in my "Awesome documentation that makes me happy when reading it" list.

RyanMcGreal17년 전

I'm reading Dive Into Python 3 right now (yay Christmas) and I'm enjoying the hell out of it, even though I don't plan to write anything nontrivial in Python 3 for some time.

chime17년 전

I read the email and url tags and thought "Cool! Finally the developers have it easy" but when I got to the slider and date section, I suddenly realized how backwards the web-standards really are in comparison to developing desktop-apps. Everything from Visual Studio and Office to wxWidgets has had these tools in their toolboxes for years. I've used the comctl32 date picker for a decade now. I placed a slider control on a VB3.0 form in 1997. Thirteen years later the web still doesn't have either and every single travel website has to implement it on their own (badly).

Instead of feeling excited over the new features of HTML5, I feel kinda sad that there still isn't a way to create live datalinks, sortable/filterable tables, listviews, tree-views, and real comboboxes (editable text + listbox) on the web without having to hack something up. Google made a great push towards replacing desktop-apps by creating a really fast browser but that doesn't make it any easier for web developers to create apps that work as well as desktop-apps. I once spent a week writing my own scrollbar and even as I wrote it, I knew I was wasting resources. However, it was a necessary feature for the project and if HTML scrollbars triggered the different events like those in almost any desktop platform, I wouldn't have had to write one from scratch.

I think it's great that the iPhone/Safari shows the most appropriate keyboard but compare the controls that iPhone SDK app developers can use vs. those that the iPhone web-app developers can call and you will see why HTML still has a very long way to go. And honestly, I don't see why a damn combobox has taken so long when almost every single web-app has a need for it ( http://stackoverflow.com/questions/1278431/why-does-html-5-n... ).

GHFigs17년 전

Bear in mind that HTML wasn't intended to do any of this.

You say it has a "long way to go", but the fact that you're even comparing web apps to desktop apps without talking about ActiveX or Java applets (as we did 10-13 years ago) is a sign that open standard HTML/CSS/JS has come a very long way. Given the challenges of developing cross-platform standards compared to proprietary or platform-specific APIs, I'm personally amazed that any of this stuff works.

scott_s17년 전

In support of your point, we should remember that HTML was originally envisioned as document markup. Now that the web is not really comprised of documents but applications, HTML is changing to represent this. Non-HTML solutions have to lead the standardization process so that the standards committee knows what to standardize. We didn't know ten years ago that it would even make sense to put some of this stuff into HTML.

nicpottier17년 전

You need to look into YUI. It satisfies your requirements and is nicely cross-browser. Their datamodel is also built so as to support tables going against a server for the data etc..

Good stuff.. there's a learning curve there for sure, but it is well built and free.

chime17년 전

I've used YUI, extjs, jqueryui etc. and all of them are good for what they do. My point was that these tools need to be natively supported by browsers so I don't have to worry about incorporating any additional UI library for basic apps. If the listbox (html SELECT) exists as an html element, why not a combo box?

GHFigs17년 전

I recommend reading this, incidentally by the same author: http://diveintomark.org/archives/2009/11/02/why-do-we-have-a...

It won't answer your question, but it will give you insight into the messy way the web evolves, which is about the closest thing to an answer you'll ever get.

ErrantX17년 전

Virtually no one will even notice, except iPhone users, who probably won’t notice either. But the ones who do notice will smile quietly and thank you for making their web experience just a little easier

Yep: I have to say I always notice and say a silent prayer of thanks when this happens :)

GoboGobo17년 전

Amazing, for once the HTML standard seems to make so much sense :)

there17년 전

a quick monkey patch for rails to be able to do 'f.text_field "email", :type => "email"' (though i guess f.email_field would be more appropriate but more code)

     module ActionView::Helpers
       class InstanceTag
         alias :orig_to_input_field_tag :to_input_field_tag
         def to_input_field_tag(field_type, options = {})
           orig_to_input_field_tag(options["type"] || field_type, options)
         end
       end
     end

stephencelis17년 전

I've added a few HTML5 form helpers to this gem:

http://github.com/stephencelis/rerails/tree/2-3-stable

So something like this would do the trick:

   <%= f.email_field :email %>

rbritton17년 전

The usual caveat applies: no support in IE for the next ten years. I would love to have that date picker universally supported now.

kevinholesh17년 전

True, but why not make the experience better for browsers that support these standards and have a decent, albeit not identical, fallback for IE?

diN0bot17년 전

because if you already have to write javascript for the datepicker, why figure out if the browser supports html5? why not use the datapicker you just wrote (using yui or jqueryui or whatever)?

to do otherwise just adds more work, not only for detecting the browser, but for making sure the page layout and so on works in both versions.

ytinas17년 전

Because everyone who does do this will provide a better user interface than you do. You can choose to make your life easier or your users experience nicer.

Personally, my strategy is simply to not write HTML or CSS. I write to a DSL that is implemented based on what browser is being served, so there are no sniffer scripts in the pages themselves. True, this does mean the same, otherwise static pages, may need to get generated over and over, but this is where caching comes in.

city4117년 전

I now will need to do even further work to see if I am working with a browser that supports the input type, and then provide a fallback if not. Since there is no way all my users will have an HTML5 capable browser (I'm looking at you IE), I will always need the fallback; so why not just use the fallback always for more consistency and simpler code? On the server side I have to validate all the input anyway, regardless of what the client side control is promising to do for me.

With the date input type, don't my non HTML5 using visitors have to enter a string that will match what an HTML5 browser would send me? Otherwise I'll have to deal with two different date formats. I hope HTML5's spec decided on a clean, simple date format that is easy to type.

mseebach17년 전

But now there's a standard. jQuery will (most likely) support this, as will any other javascript library. Just include one file (that you're probably including anyway) and you're good to go. The cool thing is that now people with HTML5 browsers will have access to plugins that can extend the behaviour of these fields.

One plugin I'm missing, that this makes possible, is adding a "recent dates" box to the date-selector: when planning a vacation, I need to enter the same two dates (often 4-6 months in the future) on the websites of airlines, hotels, car rentals etc. over and over. That gets old really fast.

GHFigs17년 전

I hope HTML5's spec decided on a clean, simple date format that is easy to type.

http://tools.ietf.org/html/rfc3339#section-5.6

kevinholesh17년 전

They would either have to type the date input or you could have a fallback date picker using jQuery (or whatever framework) that produces the same format as the built-in date picker.

jamesbritt17년 전

"Since there is no way all my users will have an HTML5 capable browser (I'm looking at you IE)"

Do you not think that IE will support HTML5 by the time the W3C makes it a proper Recommendation?

Microsoft seems to have picked up again on supporting such things, so it may happen, given how long it may be before HTML5 gets the W3C nod.

city4117년 전

Yeah but that's neither here nor there. HTML5 will be used quite a bit before it becomes official, it already has. So really the official nod just doesn't mean much. IE is the (really) long pole here.

jamesbritt17년 전

I get that, but the trouble is that it sounds very much like the stance Microsoft has taken, which is that since they have 90% (or whatever) share of the market, they are the de facto standard so others should get in line with what they do.

And the counter argument had been, no, browsers need to follow formally recognized standard, specifically what the W3C endorses. What's funny is ti see that toss aside now that it has become practical to ignore the W3C.

I expect HTML5 to become a W3C rec at some point, and Microsoft to follow along, but it still seems hollow for people to complain that Microsoft is not be so anxious to jump on an HTML5 implementation.

city4117년 전

Oh sure, technically Microsoft isn't doing anything wrong. So we technically can't hold it against them. But the reality is they are holding back progress on HTML5, and it's no coincidence that that just happens to benefit them.

But, they may need to change their tune sooner than they'd like. Their marketshare is actually down to about 65%, and Firefox and Chrome gain new marketshare every day. HTML5 is very much in Google's interest, and they have the resources to influence things in that direction. I think the Chrome tv ads are just the beginning here.

litewulf17년 전

Even if IE9 supports it, there will be people unable to upgrade.

You can ignore them though, as their numbers continue to dwindle.

_ck_17년 전