Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   HTML (http://www.velocityreviews.com/forums/f31-html.html)
-   -   Re: HTML5 browser support (http://www.velocityreviews.com/forums/t869638-re-html5-browser-support.html)

Jukka K. Korpela 03-20-2012 09:29 PM

Re: HTML5 browser support
 
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/

idle 03-20-2012 11:25 PM

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

> In article <jkass2$v75$1@dont-email.me>, 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

Gene Wirchenko 03-21-2012 02:22 AM

Re: HTML5 browser support
 
On Tue, 20 Mar 2012 23:29:40 +0200, "Jukka K. Korpela"
<jkorpela@cs.tut.fi> 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

Allodoxaphobia 03-21-2012 08:24 PM

Re: HTML5 browser support
 
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

Jorgen Grahn 03-21-2012 10:20 PM

Re: HTML5 browser support
 
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 .

Gene Wirchenko 03-22-2012 02:17 AM

Re: HTML5 browser support
 
On 21 Mar 2012 22:20:25 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
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

Jukka K. Korpela 03-22-2012 07:01 AM

Re: HTML5 browser support
 
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/

Tim Streater 03-22-2012 11:35 AM

Re: HTML5 browser support
 
In article <jkeiob$8lj$1@dont-email.me>,
"Jukka K. Korpela" <jkorpela@cs.tut.fi> 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

Gene Wirchenko 03-22-2012 04:53 PM

Re: HTML5 browser support
 
On Tue, 20 Mar 2012 23:53:03 +0100, Alfred Molon
<alfred_molon@yahoo.com> 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 03-22-2012 07:20 PM

Re: HTML5 browser support
 
On Thu, 22 Mar 2012 19:41:50 +0100, Alfred Molon
<alfred_molon@yahoo.com> wrote:

>In article <molmm71nk8cf9hc62bimflp0v3vk2er63e@4ax.com>, 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


All times are GMT. The time now is 11:07 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.