

A Form of Madness - Dive Into HTML5 - SlyShy
http://diveintohtml5.org/forms.html

======
chime
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...](http://stackoverflow.com/questions/1278431/why-does-html-5-not-
have-editable-combobox-or-local-menus-built-in) ).

~~~
GHFigs
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_s
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.

------
clofresh
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.

~~~
RyanMcGreal
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.

------
ErrantX
_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 :)

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

------
there
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

~~~
stephencelis
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 %>

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

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

~~~
diN0bot
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.

~~~
ytinas
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.

------
city41
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.

~~~
jamesbritt
"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.

~~~
city41
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.

~~~
jamesbritt
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.

~~~
city41
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.

