Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > Re: HTML5 browser support

Reply
Thread Tools

Re: HTML5 browser support

 
 
Jukka K. Korpela
Guest
Posts: n/a
 
      03-20-2012
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/
 
Reply With Quote
 
 
 
 
idle
Guest
Posts: n/a
 
      03-20-2012
On Tue, 20 Mar 2012 23:53:03 +0100, Alfred Molon wrote in alt.html:

> In article <jkass2$v75$(E-Mail Removed)>, 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
 
Reply With Quote
 
 
 
 
Gene Wirchenko
Guest
Posts: n/a
 
      03-21-2012
On Tue, 20 Mar 2012 23:29:40 +0200, "Jukka K. Korpela"
<(E-Mail Removed)> 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
 
Reply With Quote
 
Allodoxaphobia
Guest
Posts: n/a
 
      03-21-2012
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
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      03-21-2012
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 .
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      03-22-2012
On 21 Mar 2012 22:20:25 GMT, Jorgen Grahn <(E-Mail Removed)>
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
 
Reply With Quote
 
Jukka K. Korpela
Guest
Posts: n/a
 
      03-22-2012
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/
 
Reply With Quote
 
Tim Streater
Guest
Posts: n/a
 
      03-22-2012
In article <jkeiob$8lj$(E-Mail Removed)>,
"Jukka K. Korpela" <(E-Mail Removed)> 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
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      03-22-2012
On Tue, 20 Mar 2012 23:53:03 +0100, Alfred Molon
<(E-Mail Removed)> 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
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      03-22-2012
On Thu, 22 Mar 2012 19:41:50 +0100, Alfred Molon
<(E-Mail Removed)> wrote:

>In article <(E-Mail Removed)>, 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: HTML5 browser support idle HTML 4 03-20-2012 10:57 PM
Re: HTML5 browser support cwdjrxyz HTML 0 03-20-2012 08:51 PM
Testing for HTML5 attribute support RobG Javascript 7 04-05-2011 09:02 PM
HTML5 <video> and <audio> support for several browsers cwdjrxyz HTML 15 10-08-2010 07:03 PM
Does anyone have a browser that will view this html5 page properly? cwdjrxyz HTML 11 10-01-2010 07:59 AM



Advertisments