Re: HTML5 browser support

Discussion in 'HTML' started by Jukka K. Korpela, Mar 20, 2012.

  1. 2012-03-20 20:32, Alfred Molon wrote:

    > I tried out the input type=date HTML5 tag, which is very useful for an
    > application I'm designing, but only Opera supports it, not Firefox 11 or
    > IE8.


    Support is getting more widespread. The real problem is that features
    like this are much less useful that they look like on first sight.

    The idea is that type=date makes the browser create a nice date
    selection widget. But how many authors want that? Do authors want
    widgets that vary by browser rather unpredictably? Those authors who
    want nice widgets are already using them, e.g. some nice JavaScript- and
    CSS-based widget, perhaps even using Ajax to communicate with a database.

    Moreover, the idea is that browsers implement it using the locale
    (language and cultural conventions, like week structure, perhaps even
    calendar) of the browser. This is rather questionable. Think about a
    user who is visiting a web page in English and then starts filling out a
    form, with all labels and explanations in English of course, and when
    then has to enter a date, a date selection widget in German or Finnish
    or Arabic pops up. It would be rather normal to suspect a bug and go
    shopping elsewhere.

    It gets worse with type=number. A user who enters 1,500 just can't tell
    whether it will be taken as one and a half or as something else.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Mar 20, 2012
    #1
    1. Advertising

  2. Jukka K. Korpela

    idle Guest

    On Tue, 20 Mar 2012 23:53:03 +0100, Alfred Molon wrote in alt.html:

    > In article <jkass2$v75$>, Jukka K. Korpela says...
    >> The idea is that type=date makes the browser create a nice date
    >> selection widget. But how many authors want that? Do authors want
    >> widgets that vary by browser rather unpredictably? Those authors who
    >> want nice widgets are already using them, e.g. some nice JavaScript- and
    >> CSS-based widget, perhaps even using Ajax to communicate with a database.

    >
    > I created a small application which needs to read an expiry date. The
    > company is international, but the official company language is English,
    > so the problem of multinational formats does not exist.
    >
    > It does not matter if the widget looks different in different browsers.
    > It's anyway better having a widget than allowing free text input in a
    > date field.
    >
    > Regarding CSS, how would CSS be capable of creating a nice calendar
    > widget for date entry? CSS is powerful, but not that powerful.
    >
    > By the way, I hear that HTML5 also offers a slider input. I haven't
    > given it a try, but also this is a welcome addition.


    You only style with the CSS ;)
    You may be better off looking at droping a widget into a div that looks
    right and that's that.

    --
    idle
    http://www.youtube.com/watch?v=t7X9MQi7uOU
    idle, Mar 20, 2012
    #2
    1. Advertising

  3. On Tue, 20 Mar 2012 23:29:40 +0200, "Jukka K. Korpela"
    <> wrote:

    >2012-03-20 20:32, Alfred Molon wrote:
    >
    >> I tried out the input type=date HTML5 tag, which is very useful for an
    >> application I'm designing, but only Opera supports it, not Firefox 11 or
    >> IE8.

    >
    >Support is getting more widespread. The real problem is that features
    >like this are much less useful that they look like on first sight.


    And someone might already have a solution. I wrote one.

    >The idea is that type=date makes the browser create a nice date
    >selection widget. But how many authors want that? Do authors want
    >widgets that vary by browser rather unpredictably? Those authors who
    >want nice widgets are already using them, e.g. some nice JavaScript- and
    >CSS-based widget, perhaps even using Ajax to communicate with a database.


    Quite. I want a control that is text only. For my app, it needs
    head-down DE. Switching from keyboard to mouse to keyboard is bad.
    YMMV, and who gets what he wants?

    >Moreover, the idea is that browsers implement it using the locale
    >(language and cultural conventions, like week structure, perhaps even
    >calendar) of the browser. This is rather questionable. Think about a
    >user who is visiting a web page in English and then starts filling out a
    >form, with all labels and explanations in English of course, and when
    >then has to enter a date, a date selection widget in German or Finnish
    >or Arabic pops up. It would be rather normal to suspect a bug and go
    >shopping elsewhere.
    >
    >It gets worse with type=number. A user who enters 1,500 just can't tell
    >whether it will be taken as one and a half or as something else.


    I think that minor compared with the war between the MDYists, the
    DMYists, and the YMDists. I am in the YMD camp (specifically ISO
    8601). I wrote my own input handling, in JavaScript, for a YYYYMMDD
    format date.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Mar 21, 2012
    #3
  4. On Tue, 20 Mar 2012 23:53:03 +0100, Alfred Molon wrote:
    >
    > I created a small application which needs to read an expiry date. The
    > company is international, but the official company language is English,
    > so the problem of multinational formats does not exist.


    Really!!?? I did not know there was an "english language date format".

    So, you encounter no confusion amonst the english-speaking
    countries and/or entities of American Samoa, Anguilla,
    Antigua and Barbuda, Ascension and Tristan a Cunha, Australia,
    Bahamas, Barbados, Belize, Bermuda, Botswana,
    British Virgin Islands, Cameroon, Canada, Cayman Islands,
    Christmas Island, Cocos Islands, Cook Islands, Dominica, Eritrea,
    Ethiopia, Falkland Islands, Federated States of Micronesia, Fiji,
    Gambia, Ghana, Gibraltar, Grenada, Guam, Guernsey, Guyana, Hong Kong,
    India, Ireland, Isle of Man, Jamaica, Jersey, Kenya, Kiribati,
    Lesotho, Liberia, Malawi, Malta, Marshall Islands,
    Mauritius, Montserrat, Namibia, Nauru, New Zealand,
    Nigeria, Niue, Norfolk Island, Northern Mariana Islands,
    Pakistan, Palau, Papua New Guinea, Philippines,
    Pitcairn Island, Puerto Rico, Rwanda, Saint Helena,
    Saint Kitts and Nevis, Saint Lucia,
    Saint Vincent and the Grenadines, Samoa,
    San Anrés y Proviencia, Seychelles, Sierra Leone,
    Singapore, Sint Maarten, Solomon Islands, Somaliland, South Africa,
    South Sudan, Sudan, Swaziland, Tanzania, Tokelau, Tonga,
    Trinidad and Tobago, Turks and Caicos, Tuvalu, Uganda, United Kingdom,
    United States, U.S. Virgin Islands, Vanuatu, Zambia, & Zimbabwe?

    Interesting.

    (Tho', I wonder if Pitcairn island is web-connected, anyway....)
    Jonesy
    Allodoxaphobia, Mar 21, 2012
    #4
  5. Jukka K. Korpela

    Jorgen Grahn Guest

    On Wed, 2012-03-21, Allodoxaphobia wrote:
    > On Tue, 20 Mar 2012 23:53:03 +0100, Alfred Molon wrote:
    >>
    >> I created a small application which needs to read an expiry date. The
    >> company is international, but the official company language is English,
    >> so the problem of multinational formats does not exist.

    >
    > Really!!?? I did not know there was an "english language date format".
    >
    > So, you encounter no confusion amonst the english-speaking
    > countries and/or entities of American Samoa, Anguilla,
    > Antigua and Barbuda, Ascension and Tristan a Cunha, Australia,

    ....

    Sarcasm aside, it can be a fatal mistake to assume language => date
    format, or => decimal point/comma, or ...
    Beware.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Mar 21, 2012
    #5
  6. On 21 Mar 2012 22:20:25 GMT, Jorgen Grahn <>
    wrote:

    >On Wed, 2012-03-21, Allodoxaphobia wrote:
    >> On Tue, 20 Mar 2012 23:53:03 +0100, Alfred Molon wrote:
    >>>
    >>> I created a small application which needs to read an expiry date. The
    >>> company is international, but the official company language is English,
    >>> so the problem of multinational formats does not exist.

    >>
    >> Really!!?? I did not know there was an "english language date format".
    >>
    >> So, you encounter no confusion amonst the english-speaking
    >> countries and/or entities of American Samoa, Anguilla,
    >> Antigua and Barbuda, Ascension and Tristan a Cunha, Australia,

    >...
    >
    >Sarcasm aside, it can be a fatal mistake to assume language => date
    >format, or => decimal point/comma, or ...
    >Beware.


    And then, there is just plain personal preference. I maintain a
    client billing system used mainly in the U.S.A. My boss prefers YMD
    format so that is what is used, not MDY. Since I happen to prefer YMD
    myself, I am happy to do so.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Mar 22, 2012
    #6
  7. 2012-03-21 0:53, Alfred Molon wrote:

    > I created a small application which needs to read an expiry date. The
    > company is international, but the official company language is English,
    > so the problem of multinational formats does not exist.


    In addition to many other issues with this, it exactly demonstrates why
    type=date is not the right approach. It can be useful in prototyping and
    testing, for example, but for any production use, it normally needs to
    be replaced by something that works reliably.

    If someone in the company is using, say, a French-language version of a
    browser, he would see the widget in French, with French names or
    abbreviations for months and days etc. - even though the application is
    in English

    > It does not matter if the widget looks different in different browsers.
    > It's anyway better having a widget than allowing free text input in a
    > date field.


    Hardly. Entering a date by typing is faster, often much faster, than
    using any date selection widget.

    > Regarding CSS, how would CSS be capable of creating a nice calendar
    > widget for date entry? CSS is powerful, but not that powerful.


    I wrote "JavaScript- and CSS-based widget", and that's how they are
    done. JavaScript handles the functionality of course, CSS does the painting.

    > By the way, I hear that HTML5 also offers a slider input. I haven't
    > given it a try, but also this is a welcome addition.


    It suffers from a different problem. Try it and you'll. For example, use
    <input type=range min=0 max=100 step=0.01>
    and ask someone else use it on Chrome without peeking at the source code.

    The point is that it's useless unless you add information about the
    range in the visible text, and the usability is questionable unless you
    add JavaScript that monitors changes in the value and shows the
    currently selected value as a spelled-out number. Doing this, you are
    more than half way creating your own widget. And really creating your
    own widget gives you something that works across browsers, not just on
    those that have some experimentatal implementation of type=range.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Mar 22, 2012
    #7
  8. Jukka K. Korpela

    Tim Streater Guest

    In article <jkeiob$8lj$>,
    "Jukka K. Korpela" <> wrote:

    > 2012-03-21 0:53, Alfred Molon wrote:
    >
    > > I created a small application which needs to read an expiry date. The
    > > company is international, but the official company language is English,
    > > so the problem of multinational formats does not exist.

    >
    > In addition to many other issues with this, it exactly demonstrates why
    > type=date is not the right approach. It can be useful in prototyping and
    > testing, for example, but for any production use, it normally needs to
    > be replaced by something that works reliably.
    >
    > If someone in the company is using, say, a French-language version of a
    > browser, he would see the widget in French, with French names or
    > abbreviations for months and days etc. - even though the application is
    > in English


    I would have thought that both the application and the browser should be
    using whatever the system settings are, although whether there is access
    to that I don't know. In any case, that's what I would expect type=date
    to do.

    > > It does not matter if the widget looks different in different browsers.
    > > It's anyway better having a widget than allowing free text input in a
    > > date field.

    >
    > Hardly. Entering a date by typing is faster, often much faster, than
    > using any date selection widget.


    Except that a date-selection widget would hopefully also be telling the
    user what the day-of-week would be for their choice of day. And perhaps
    the week number too. I agree that normally typing would be faster but
    then you have a variety of formats to imagine. And there's nothing more
    irritating than having to follow someone else's weird date format.

    > > Regarding CSS, how would CSS be capable of creating a nice calendar
    > > widget for date entry? CSS is powerful, but not that powerful.

    >
    > I wrote "JavaScript- and CSS-based widget", and that's how they are
    > done. JavaScript handles the functionality of course, CSS does the painting.
    >
    > > By the way, I hear that HTML5 also offers a slider input. I haven't
    > > given it a try, but also this is a welcome addition.

    >
    > It suffers from a different problem. Try it and you'll. For example, use
    > <input type=range min=0 max=100 step=0.01>
    > and ask someone else use it on Chrome without peeking at the source code.
    >
    > The point is that it's useless unless you add information about the
    > range in the visible text, and the usability is questionable unless you
    > add JavaScript that monitors changes in the value and shows the
    > currently selected value as a spelled-out number. Doing this, you are
    > more than half way creating your own widget. And really creating your
    > own widget gives you something that works across browsers, not just on
    > those that have some experimentatal implementation of type=range.


    True enough.

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
    Tim Streater, Mar 22, 2012
    #8
  9. On Tue, 20 Mar 2012 23:53:03 +0100, Alfred Molon
    <> wrote:

    [snip]

    >I created a small application which needs to read an expiry date. The
    >company is international, but the official company language is English,
    >so the problem of multinational formats does not exist.


    Not so fast. Localisation -- or would you prefer "Localization"?
    -- can still bite.

    The in-house client billing app that I support uses only one
    language: English. I did have a change request to correct some
    spellings. The words were spelled correctly, sort of. I am in
    Canada, and I use British spellings. The app is used in the U.S.A.
    Naturally, they use U.S. spellings.

    >It does not matter if the widget looks different in different browsers.
    >It's anyway better having a widget than allowing free text input in a
    >date field.


    If I were a user of your system, I would be *EXTREMELY* irked.
    Typing is much faster than fiddling around with some cutesy widget.

    The company I work for uses a cloud app for a bit of the work.
    Apparently, it takes twice as long to do data input using it as it
    would with a desktop app.

    [snip]

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Mar 22, 2012
    #9
  10. On Thu, 22 Mar 2012 19:41:50 +0100, Alfred Molon
    <> wrote:

    >In article <>, Gene Wirchenko
    >says...
    >> If I were a user of your system, I would be *EXTREMELY* irked.
    >> Typing is much faster than fiddling around with some cutesy widget.

    >
    >And yet all flight booking sites use date widgets.


    You have checked every one of them?

    I have had to enter dates using the three dropdown method. It
    slows DE to a crawl. If I were using an app that was that
    inconsiderate of my time, I would be complaining loudly.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Mar 22, 2012
    #10
  11. On Thu, 22 Mar 2012 19:40:20 +0100, Alfred Molon
    <> wrote:

    >In article <jkeiob$8lj$>, Jukka K. Korpela says...
    >
    >> If someone in the company is using, say, a French-language version of a
    >> browser, he would see the widget in French, with French names or
    >> abbreviations for months and days etc. - even though the application is
    >> in English

    >
    >I don't know how the widget looks in different browsers, but I don't
    >think that would be a problem.
    >
    >> Hardly. Entering a date by typing is faster, often much faster, than
    >> using any date selection widget.

    >
    >Good luck processing that input. I can't imagine anybody would prefer


    Why would I need luck? I know how dates work. I have just
    written a bunch of date handling code in JavaScript. It is pretty
    easy.

    >free text input when a calendar widget is available.


    Improve your imagination. Users do not come in one flavour only.
    My boss sets a high priority on head-down data entry. We are
    developing a Web version. Were I to use a widget for date entry, I
    would be told to change REALLY FAST.

    I coded keyboard date entry handling with right-to-left entry
    overwriting the previous value and backspace restoring it on YMD
    dates. Since much, but not all, of the date entry is within the same
    month, this means that users will be able to enter many dates by just
    entering the day of the month, and it is still easy to enter a full
    date. This is an example of thinking of how the users will be using
    the system and making it easy for them to use it.

    Your users may have different requirements so my solution may not
    fit your users' problem. Your solution might not either.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Mar 22, 2012
    #11
  12. 2012-03-22 20:41, Alfred Molon wrote:

    > In article<>, Gene Wirchenko
    > says...
    >> If I were a user of your system, I would be *EXTREMELY* irked.
    >> Typing is much faster than fiddling around with some cutesy widget.

    >
    > And yet all flight booking sites use date widgets.


    Not the one I worked on; or, rather, it allows both text input and
    widget input. Incidentally, British Airways has similar dualism: when
    you focus on a date field, a calendar widget appears, but you can still
    type the date, too. And United has dual input with text input as primary
    (calendar widget only appears if you click on the calendar icon).

    Most flight booking sites use widgets, and most of them have problems
    with them, and they use specialized widgets, not something that you
    could do with <input type=date>. Some sites (like Qantas) still use
    dropdowns. Norwegian has a dual method: dropdowns and calendar widget.

    They may involve a database query that checks, after a route has been
    selected, which dates are operational (i.e., have flight connections on
    the route). Flight booking is also special because there is less than
    one year range that can be used, and most booking is made some days or
    or some weeks ahead. This means that date widgets (properly implemented)
    are much less clumsy than in general date input - compare selecting a
    day in this month or next with selecting your birthday via a date
    widget. The same applies to dropdowns: they are generally a bad idea for
    date input, but if the user will likely select something in the current
    month, or maybe next, then dropdowns aren't too bad.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Jukka K. Korpela, Mar 22, 2012
    #12
  13. Jukka K. Korpela

    dorayme Guest

    In article <>,
    Alfred Molon <> wrote:

    > In article <>, Gene Wirchenko
    > says...
    > > If I were a user of your system, I would be *EXTREMELY* irked.
    > > Typing is much faster than fiddling around with some cutesy widget.

    >
    > And yet all flight booking sites use date widgets.


    Used it the other week when booking flights from Sydney to an even
    wetter part of Australia, worked fine and was useful *for me*. Beat
    fiddling about finding a calendar.

    But, realising that my one experience was not a basis for website
    making recommendations, I determined to contact all the other users of
    it. I started on the plane as soon as the seat belt lights went out
    by going up and down the aisle to question the passengers closely.
    Apparently it was not well received and, in the end, I was overpowered
    (by two toddlers actually, they are now national heroes) and
    handcuffed back in my seat. Not sure I will continue now after that
    experience.

    btw, when I become ruler of the world, all toddlers will need to be
    held on leads.

    --
    dorayme
    dorayme, Mar 22, 2012
    #13
  14. Jukka K. Korpela

    dorayme Guest

    In article <>,
    Alfred Molon <> wrote:

    > In article <>, dorayme
    > says...
    > > But, realising that my one experience was not a basis for website
    > > making recommendations, I determined to contact all the other users of
    > > it. I started on the plane as soon as the seat belt lights went out
    > > by going up and down the aisle to question the passengers closely.
    > > Apparently it was not well received and, in the end, I was overpowered
    > > (by two toddlers actually, they are now national heroes) and
    > > handcuffed back in my seat. Not sure I will continue now after that
    > > experience.

    >
    > You did that??


    Yes, of course, would I make any light-hearted remarks or jokes on
    such a serious subject?

    By the way, the case came up today, I have just been released on bail.
    My lawyer appealed the sentence:

    "You will be taken down to a desk with a
    phone and you will attend that phone for a
    year, 10 hours a day, 6 days a week answering
    questions about dates, you will also be
    required to be online and provide every kind
    of help about future dates in every possible
    format in every possible language."

    My lawyer thinks I can get the lighter alternative:

    "You shall be taken to the place from whence
    you came, and thence to a place of lawful
    execution, and there you shall be hanged by
    the neck until you be dead, and afterwards
    your body shall be buried in a common grave
    within the precincts of the prison wherein
    you were last confined before your execution;
    and may the Lord have mercy on your soul'."

    --
    dorayme
    dorayme, Mar 23, 2012
    #14
  15. On Fri, 23 Mar 2012 13:17:04 +1100, dorayme <>
    wrote:

    [snip]

    >Yes, of course, would I make any light-hearted remarks or jokes on
    >such a serious subject?


    Satirists do so.

    >By the way, the case came up today, I have just been released on bail.
    >My lawyer appealed the sentence:
    >
    >"You will be taken down to a desk with a
    >phone and you will attend that phone for a
    >year, 10 hours a day, 6 days a week answering
    >questions about dates, you will also be
    >required to be online and provide every kind
    >of help about future dates in every possible
    >format in every possible language."


    Imagine some of the questions about dates:

    "Why does the computer put 4/5/12 before 5/4/12?" (The dates may
    be reversed in other parts of the world.)

    "My programmer just said 'ISO 8601' and smirked at me. What is
    he on about?"

    "Does the cafeteria have any dates without added sugar?"

    "Why can't I get a date?"

    >My lawyer thinks I can get the lighter alternative:
    >
    >"You shall be taken to the place from whence
    >you came, and thence to a place of lawful
    >execution, and there you shall be hanged by
    >the neck until you be dead, and afterwards
    >your body shall be buried in a common grave
    >within the precincts of the prison wherein
    >you were last confined before your execution;
    >and may the Lord have mercy on your soul'."


    Choice is important.

    Sincerely,

    Gene Wirchenko
    Gene Wirchenko, Mar 23, 2012
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. cwdjrxyz
    Replies:
    15
    Views:
    1,023
    cwdjrxyz
    Oct 8, 2010
  2. idle

    Re: HTML5 browser support

    idle, Mar 20, 2012, in forum: HTML
    Replies:
    4
    Views:
    648
    Tim Streater
    Mar 20, 2012
  3. cwdjrxyz

    Re: HTML5 browser support

    cwdjrxyz, Mar 20, 2012, in forum: HTML
    Replies:
    0
    Views:
    488
    cwdjrxyz
    Mar 20, 2012
  4. RobG

    Testing for HTML5 attribute support

    RobG, Apr 5, 2011, in forum: Javascript
    Replies:
    7
    Views:
    231
Loading...

Share This Page