6 ms·

A Form of Madness - Dive Into HTML5

161 points by SlyShy 17y ago

clofresh 17y ago
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 17y ago
  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.
_ck_ 17y ago
Wow HTML5 is powerful. I hope Firefox 3.6 will get more of it? I can see us telling children "back in our day you had to use 100k of javascript to do what you're doing in one line of HTML5 !"
there 17y ago
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 17y ago
  I've added a few HTML5 form helpers to this gem: http://github.com/stephencelis/rerails/tree/2-3-stable http://github.com/stephencelis/rerails/tree/2-3-stable So something like this would do the trick: <%= f.email_field :email %>
GoboGobo 17y ago
Amazing, for once the HTML standard seems to make so much sense :)
rbritton 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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 17y ago
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 17y ago
  "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 17y ago
    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 17y ago
      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.
chime 17y ago
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-not-have-editable-combobox-or-local-menus-built-in http://stackoverflow.com/questions/1278431/why-does-html-5-n... ).
- nicpottier 17y ago
  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.
  - chime 17y ago
    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?
ErrantX 17y ago
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 :)

161 points by SlyShy 17y ago

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 17y ago
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.

_ck_ 17y ago

Wow HTML5 is powerful. I hope Firefox 3.6 will get more of it? I can see us telling children "back in our day you had to use 100k of javascript to do what you're doing in one line of HTML5 !"

there 17y ago

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 17y ago
I've added a few HTML5 form helpers to this gem: http://github.com/stephencelis/rerails/tree/2-3-stable http://github.com/stephencelis/rerails/tree/2-3-stable So something like this would do the trick: <%= f.email_field :email %>

GoboGobo 17y ago

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

rbritton 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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 17y ago

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 17y ago
"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 17y ago
  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 17y ago
    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.

chime 17y ago

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

nicpottier 17y ago
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.
- chime 17y ago
  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?

ErrantX 17y ago

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