Microsoft and IE9 New Features


G

Garrett Smith

A colleague of mine recently informed me with the emphatic title:
"HTML5, CSS3, and omg finally AddEventListener in new IE9!"

With a link to:
http://ie.microsoft.com/testdrive/

And from the getgo, anyone who is not both stupid and ignorant would
notice some major problems there.

For example: Under "HTML 5" category is a link to "DOM Events" (where my
colleague had directed my attention). To most anyone who can use google
and read, DOM Events is not part of HTML 5, but a completely separate
specification. Apparently nobody at Microsoft can search the web and
read, which would explain why D3E is categorized under HTML 5.

I replied to my colleagues email, but then decided to post my replies
here. My response to that email below (I edited it up a bit to be less
obnoxious).

BEGIN EMAIL REPLY:
I have no doubt that they totally f**ked it up.

My first glance at the Events; the first thing you're directing me to:
http://ie.microsoft.com/testdrive/HTML5/13DOM_Events/Default.html

http://validator.w3.org/check?uri=h...(detect+automatically)&doctype=Inline&group=0

They are serving invalid html document, w/XHTML doctype, as content-type
"text/html". Documents served with XHTML doctype should be sent with an
xml content type header. Sending XHTML as text/html forces browsers to
error-correct. The document at the following URL explains well enough:
http://hixie.ch/advocacy/xhtml

So MS does not know html. This is news or what?

I reformatted their example code. They posted a mix of tabs spaces. I
reformatted it to use space indentation. Have a look:

| var addSummaryListeners = function () {
|
|
| // Call "showSummary" on mouseover
| addEventListener("mouseover", showSummary,
| false);
|
| // Call "hideSummary" on mouseout
| addEventListener("mouseout", showSummary,
| false);
| }
| }
| }

The first most obvious things are:
1) Why is the EventTarget the global object?
2) Do they think that global object implements MouseEvents?
3) Why are there three closing curly braces for the function?
4) Why is the ExpressionStatement, a FunctionExpression not terminated
by a semicolon?
5) What is "..." in the function body?

The answer to all of these questions can be explained by the fact that
Microsoft does not hire competent individuals.

The extra semicolons and "..." can be explained as a formatting errors.
Relying on ASI (automatic semicolon insertion) is a beginner mistake or
careless mistake; it can taken be a sign of being under qualified.
Suggesting that the global object implements MouseEvents is
demonstration of a nonstandard feature.

The #1 mistake in the example is that the example is used to support
claims support of DOM events but instead provides a proprietary
(non-standard) example of MouseEvents on the global object. Classic
Microsoft. Virtually every example on MSDN uses code that will function
only in MSIE, often using things such as IE's global scope polluter,
document.all, and usually invalid HTML.


The Consequences.

Javascript library authors will likely end up believing that the global
object implements MouseEvents and EventTarget and expecting those things
to work. At least, those will be used for IE-only sites.

Microsoft should hire competent individuals to write unit tests to
ensure that the APIs they are producing are standard, valid, and
functional in known modern browsers (at least including Safari 2, IE7,
FF2).

Microsoft gets acknowledgment for trying. Unfortunately the effort falls
short of being acceptable.

The rest of the code tends to be worse. For example, they attempt to
provide a "fallback" for IE8 that requires javascript:

| // should probably do something similar for
| //IE7 but it's a lot more work
| if (_isIE8) {
| var xhtmllinks =
| document.querySelectorAll("a.noIE8");
|
| for (var i = 0; i < xhtmllinks.length; ++i){
| xhtmllinks.removeAttribute("href");
| xhtmllinks.style.color = "#ccc";
| xhtmllinks.setAttribute("title",
| "This page does not work in "
| + "Internet Explorer 8");
| }
| }

This is the most absurd piece of code yet. The removal of the href
attribute is likely to not work cross browser. The concept of basing a
fallback strategy on javascript is a demonstration of misunderstanding
what a fallback is, which is also demonstrated that the fallback is
targeted specifically for IE8 and IE8 only. The author did seem to
recognize at least the significance of IE7, else he would not have
included the comment: "for IE7 it's a lot more work.").

There is also the message to the user, written in English, not
localized, and appearing directly in the source code.

This is the most absurd code I have seen in quite a long time.

END EMAIL REPLY.
 
Ad

Advertisements

D

David Mark

Garrett said:
A colleague of mine recently informed me with the emphatic title:
"HTML5, CSS3, and omg finally AddEventListener in new IE9!"

Oh boy.

Screw them. I'll look at their latest BS when they release it.
And from the getgo, anyone who is not both stupid and ignorant would
notice some major problems there.

For example: Under "HTML 5" category is a link to "DOM Events" (where my
colleague had directed my attention). To most anyone who can use google
and read, DOM Events is not part of HTML 5, but a completely separate
specification. Apparently nobody at Microsoft can search the web and
read, which would explain why D3E is categorized under HTML 5.

As I said, screw them. Their explanations are never worth reading.
I'll see for myself what the stupid thing does when it comes out.
I replied to my colleagues email, but then decided to post my replies
here. My response to that email below (I edited it up a bit to be less
obnoxious).

Is f**ked really less obnoxious than fucked? I don't think so.
BEGIN EMAIL REPLY:
I have no doubt that they totally f**ked it up.

My first glance at the Events; the first thing you're directing me to:
http://ie.microsoft.com/testdrive/HTML5/13DOM_Events/Default.html

http://validator.w3.org/check?uri=h...(detect+automatically)&doctype=Inline&group=0

No need to check that. But I see you have the game summary below. :)
They are serving invalid html document, w/XHTML doctype, as content-type
"text/html". Documents served with XHTML doctype should be sent with an
xml content type header.

Which you should NEVER do on the Web (unless you are writing a library
test page of course).
Sending XHTML as text/html forces browsers to
error-correct. The document at the following URL explains well enough:
http://hixie.ch/advocacy/xhtml

So MS does not know html. This is news or what?

Nope. Which raises a question...
I reformatted their example code. They posted a mix of tabs spaces. I
reformatted it to use space indentation. Have a look:

| var addSummaryListeners = function () {
|
|
| // Call "showSummary" on mouseover
| addEventListener("mouseover", showSummary,
| false);
|
| // Call "hideSummary" on mouseout
| addEventListener("mouseout", showSummary,
| false);
| }
| }
| }

The first most obvious things are:
1) Why is the EventTarget the global object?

Because their Web developers are a bunch of incorrigible incompetents.
Of course, that describes most Web developers anyway, but MS is
particularly awful, considering how much money they have to spend on
talent (see also Google).
2) Do they think that global object implements MouseEvents?

No, they think that window is the Global Object, which is almost as
stupid as why would a window object support mouse events?
3) Why are there three closing curly braces for the function?

Key got stuck?
4) Why is the ExpressionStatement, a FunctionExpression not terminated
by a semicolon?

You are asking a bit much from that bunch.
5) What is "..." in the function body?
Where?


The answer to all of these questions can be explained by the fact that
Microsoft does not hire competent individuals.

Yes, what else is new?
The extra semicolons and "..." can be explained as a formatting errors.

I still don't see the ellipsis.
Relying on ASI (automatic semicolon insertion) is a beginner mistake or
careless mistake; it can taken be a sign of being under qualified.

It's easy to do while pounding out code, but also easy to use a verifier
like JSLint. And, of course, this is one _example_ function.
Suggesting that the global object implements MouseEvents is
demonstration of a nonstandard feature.

And just a flat-out insane idea.
The #1 mistake in the example is that the example is used to support
claims support of DOM events but instead provides a proprietary
(non-standard) example of MouseEvents on the global object. Classic
Microsoft. Virtually every example on MSDN uses code that will function
only in MSIE, often using things such as IE's global scope polluter,
document.all, and usually invalid HTML.

Well, they are consistent if nothing else. :)
The Consequences.

Javascript library authors will likely end up believing that the global
object implements MouseEvents and EventTarget and expecting those things
to work. At least, those will be used for IE-only sites.

As we've seen, Javascript library authors will likely do about anything.
I could publish code here to delete the window object and it would show
up in some library six months from now.
Microsoft should hire competent individuals to write unit tests to
ensure that the APIs they are producing are standard, valid, and
functional in known modern browsers (at least including Safari 2, IE7,
FF2).

They don't want compatibility. It doesn't fit their business plan.
Microsoft gets acknowledgment for trying.

Not from me.
Unfortunately the effort falls
short of being acceptable.

In the same way that jQuery falls short of competence. Those two should
be very happy together. ;)
The rest of the code tends to be worse. For example, they attempt to
provide a "fallback" for IE8 that requires javascript:

| // should probably do something similar for
| //IE7 but it's a lot more work

That looks like a Dojo apology comment.
| if (_isIE8) {
| var xhtmllinks =

They really think they are using XHTML. :)
| document.querySelectorAll("a.noIE8");
|
| for (var i = 0; i < xhtmllinks.length; ++i){
| xhtmllinks.removeAttribute("href");
| xhtmllinks.style.color = "#ccc";
| xhtmllinks.setAttribute("title",
| "This page does not work in "
| + "Internet Explorer 8");
| }
| }


Those rebels. :)
This is the most absurd piece of code yet. The removal of the href
attribute is likely to not work cross browser. The concept of basing a
fallback strategy on javascript is a demonstration of misunderstanding
what a fallback is, which is also demonstrated that the fallback is
targeted specifically for IE8 and IE8 only. The author did seem to
recognize at least the significance of IE7, else he would not have
included the comment: "for IE7 it's a lot more work.").

And it wouldn't have been a lot more work (unless you were using jQuery
or otherwise had no clue what you were doing). Yes, the more I think
about it, MS and jQuery are perfect together. Just like Apple and My
Library (hint).
There is also the message to the user, written in English, not
localized, and appearing directly in the source code.

This is the most absurd code I have seen in quite a long time.

Have a look at virtually any file in Dojo. Just throw darts at them...
You're sure to hit some absurdity.
 
S

S.T.

For example: Under "HTML 5" category is a link to "DOM Events" (where my
colleague had directed my attention). To most anyone who can use google
and read, DOM Events is not part of HTML 5, but a completely separate
specification. Apparently nobody at Microsoft can search the web and
read, which would explain why D3E is categorized under HTML 5.

I doubt they were expecting somehow to so carefully analyze their
categorization on a demo page.
I replied to my colleagues email, but then decided to post my replies
here. My response to that email below (I edited it up a bit to be less
obnoxious).

BEGIN EMAIL REPLY:
I have no doubt that they totally f**ked it up.

My first glance at the Events; the first thing you're directing me to:
http://ie.microsoft.com/testdrive/HTML5/13DOM_Events/Default.html
I reformatted their example code. They posted a mix of tabs spaces. I
reformatted it to use space indentation. Have a look:

That's not sample code. It's filler text.
| var addSummaryListeners = function () {
|
|
| // Call "showSummary" on mouseover
| addEventListener("mouseover", showSummary,
| false);
|
| // Call "hideSummary" on mouseout
| addEventListener("mouseout", showSummary,
| false);
| }
| }
| }

The first most obvious things are:
1) Why is the EventTarget the global object?
2) Do they think that global object implements MouseEvents?
3) Why are there three closing curly braces for the function?
4) Why is the ExpressionStatement, a FunctionExpression not terminated
by a semicolon?
5) What is "..." in the function body?

The answer to all of these questions can be explained by the fact that
Microsoft does not hire competent individuals.

The extra semicolons and "..." can be explained as a formatting errors.
Relying on ASI (automatic semicolon insertion) is a beginner mistake or
careless mistake; it can taken be a sign of being under qualified.
Suggesting that the global object implements MouseEvents is
demonstration of a nonstandard feature.

You're analyzing fillertext -- it wasn't intended to be a tutorial. Just
some text they stuck up there - a snip of part of their code. It could
have been the Gettysburg address or some 'ipsum lorem'. Probably just
looked more appropriate to through some code'y looking text on screen
when giving a presentation to a techie audience.

Here's the actual code -- maybe it'll calm at least some of your wrath?
--------------------------------
var init = function () {
preventSelection();
hideSummaries();
addSummaryListeners();
}

// Abstraction layer for event registration differences
var addListener = function (obj, event, handler) {
if (obj.addEventListener) {
obj.addEventListener(event, handler, false);
} else {
obj.attachEvent("on" + event, handler);
}
}

// Call "init" on page load
addListener(window, "load", init);

//
// Initialization Methods
//

// Add listeners to show/hide summaries when needed
var addSummaryListeners = function () {
var links = document.getElementsByTagName("a");
for (var i = 0; i < links.length; i++) {
var next = links.nextSibling;
if (next && next.className == "summary") {
links.summary = next;
// Call "showSummary" on mouseover
addListener(links, "mouseover", showSummary);
// Call "hideSummary" on mouseout
addListener(links, "mouseout", hideSummary);
}
}
}
---------------------------
.... and a couple more functions called in the init()


I mean... sheesh!! It's a basic demo site intended for a presentation
and posted online. They probably weren't too worried about being
cross-browser since it's a site specifically targeted for people to test
with an IE9 preview release. When you open the preview release, it's the
site you end up on and it's purposefully inconvenient to move elsewhere.

Having actually tried the preview release, I was quite impressed. Though
no indication of the UI, the js performance in my stuff seems at least
as 'peppy' as Chrome and faster than Firefox. Substantially faster than
IE8. Its 'flying images' demo showed far better performance than
anything else on my system (both FPS and image quality while moving).
And the only thing readily obvious that breaks on my sites (even when
forcing IE9 rendering) is some jQueryUI autocomplete stuff on an
intranet app -- which is beta itself and I know it's buggy.

IMHO Microsoft should be applauded for this. As it evolves is starts
supporting DOM level 2 events (they've said they will) and other
fixes/features they'll likely deserve even more credit.

And since they're now providing resources to a somewhat
Mozilla-affiliated jQuery project, probably a move to gain some positive
PR from the web developer community, I would guess they'll get more and
more standard compliant. I'm sure some remnant junk will remain -- else
it would kill any chance of getting corporations to upgrade -- but it's
most certainly headed the right direction and, in some cases,
outperforms everything else already.
 
S

S.T.

What would possess you to use code written by a jQuery maven to
implement something as simple as an auto-complete feature? Of course it
is buggy. It can't not be buggy. All you have to do is look at the
code it is built on (the actual code, not what you can see it doing in a
handful of browsers). And a year from now they'll announce they've
stopped "caring" about IE< 9 anyway (and then all of that stuff will go
to hell in a hurry) and you'll have to upgrade to get it work with some
newer browser. All of that against spending a couple of hours slapping
together an auto-complete? That's something that you should already
have in your arsenal (or at least the few pieces required to build one).


I already use jQuery UI on the intranet app for it's datepicker (which I
really like) and it's drag/drop which I like as well. I would never have
bothered coding drag/drop functionality as its use was for something I
deemed not too important -- more of an experiment (our salespeople
"build" an HTML email quote and prices with it from a bunch of
components). As it turned out the sales agents love it.

Dialog -- not so much. Tabs/Accordion -- why bother?

Autocomplete has promise - they thought out the key-bindings to increase
functionality pretty darn well and doing nothing more than spitting back
a query result via some PHP'd json_encode() is nice - but I still find
kinks in the manner I use it. So far a little custom CSS has fixed "my"
bugs though. I'll be curious what the final version looks like.

jQuery UI IS on the bloated side -- no argument there -- but on my
intranet app (Win+FF3.6 without exception) it's fine. For now, at least,
it's used in-house only. Damn fast to develop/prototype with though.

I'm not a fan of using an autocomplete solution on public-facing sites,
mine or a prepackaged version. I'm sure there are roles where it works
but for the most part it seems to confuse too many visitors.
 
D

David Mark

S.T. said:
I already use jQuery UI on the intranet app for it's datepicker (which I
really like) and it's drag/drop which I like as well.

For one, what on earth does that have to do with the other thing? Do
you think those are some sort of matched set? They are just scripts,
likely written by different people and they are teetering on top of
jQuery, which changes every month, often throwing add-ons like these UI
widgets for loops. Now, you say you will be like Matt Kruse and never
upgrade jQuery? Then don't ever upgrade browsers. ;)
I would never have
bothered coding drag/drop functionality as its use was for something I
deemed not too important -- more of an experiment (our salespeople
"build" an HTML email quote and prices with it from a bunch of
components). As it turned out the sales agents love it.

But management won't like it when it must be rewritten. You are trying
to keep three layers in sync, jQuery (a completely incompetent script
that shifts constantly), some thing written by a jQuery maven (the drag
and drop add-on, whatever that is) and browsers. Good luck with that
juggling act!
Dialog -- not so much. Tabs/Accordion -- why bother?

Indeed, why bother when anyone who purports to script browsers for a
living should be able to put together either of those in an hour (and I
don't mean with some stupid library).
Autocomplete has promise - they thought out the key-bindings to increase
functionality pretty darn well and doing nothing more than spitting back
a query result via some PHP'd json_encode() is nice - but I still find
kinks in the manner I use it.

In other words, it doesn't work like you need it to. What are you
clinging to?
So far a little custom CSS has fixed "my"
bugs though.

Custom CSS to fix a script? Now you have a fourth layer. Can you see
where this is going? Toppling. Put it on your calendar.
I'll be curious what the final version looks like.

Of what? Some neophytes "final" (no such thing) rendition of an
auto-complete? Why?
jQuery UI IS on the bloated side -- no argument there -- but on my
intranet app (Win+FF3.6 without exception) it's fine.

That depends on your definition of fine. Remember when you thought
invalid markup was fine? You can learn from those who have already made
the mistakes (unless they are Matt Kruse as his delusions seem to have
no bounds).
For now, at least,
it's used in-house only. Damn fast to develop/prototype with though.

Fast would imply you are saving time. Any time you think you saved (and
again, how long does it take to write such a widget?) today will
certainly be wasted tomorrow. That's not even up for debate at this
point (I hope anyway). Just look at the history.
I'm not a fan of using an autocomplete solution on public-facing sites,
mine or a prepackaged version.

Depends on the context, but I generally hate them (of course, they are
generally sluggish). And did I take that to mean that you have such a
solution? Why on earth aren't you using it instead of participating in
jQuery's endless Beta test swarm whatever-the-****-they-are-doing?
I'm sure there are roles where it works
but for the most part it seems to confuse too many visitors.

The problem is that browsers often have their own auto-completes.
 
Ad

Advertisements

G

Garrett Smith

S.T. said:
I already use jQuery UI on the intranet app for it's datepicker (which I
really like)

The jQuery datepicker that uses mm/dd/yyyy?
http://jqueryui.com/demos/datepicker/

That Datepicker does not meet basic usability and accessibility
criteria. It uses a nonstandard date format (YYYY-MM-DD) and provides no
indication of what format the user should enter, should js be disabled.
It is not keyboard friendly. There is no way to navigate years. It
breaks bfcache.

The format mm/dd/yyyy is nonstandard and worse, is not stated in the
label. That is bad usability. Instead, the label should use a standard
format and indicate that format clearly in the label where the user will
unavoidably see it, e.g.

Date (YYYY-MM-DD): [ ]
(It is also acceptable to additionally use placeholder text that
contains that standard format).

When entering of an ISO-8601 date format, the user is prevented (only
when javascript is enabled). What I mean is that typing: "2012-", the
"-" character is not entered.

The datepicker cannot navigate years. Try entering your birthdate using
the "month back" button. Not nice at all and even you kids out there
trying this out can see how aggravating that can be.

Not keyboard accessible! The calendar should be navigable by the
keyboard keys. I hate sites that force me to use my trackpad.

Regarding bfcache that I mentioned earlier: You might notice is that in
Firefox, or another browser that ties bfcache to unload, is that when
navigating back, the Calendar disappears, and whatever was visible in
the calendar is gone, and so you have to navigate the thing to the right
month again.

The bfcache breakage is caused by unload event handlers. Such design is
not optimal for a more complicated RIA, where in most cases, the user
would want the page to load as quickly as possible and retain its state
on hitting "back" button.

I believe in the requirements:
* works with JS disabled
* provides indication of date format in label
* uses INPUT type="date", where available
* fallback to js-driven calendar widget
* uses ISO 8601 format
* full keyboard a11y
* can navigate years and months

Those requirements, with a partial implementation of HTML 5 input
type="date", are what I decided upon for my own Calendar widget.
http://dhtmlkitchen.com/ape/example/widget/Calendar/

and it's drag/drop which I like as well. I would never have
bothered coding drag/drop functionality as its use was for something I
deemed not too important -- more of an experiment (our salespeople
"build" an HTML email quote and prices with it from a bunch of
components). As it turned out the sales agents love it.

Usability assessments from unqualified individuals are often harmful.
This is particularly the case when you get sales and marketing thinking
they want the web page to work a certain way, such as to include a
popup, automatically draw focus to an input, scroll the viewport
automatically, marquee, gif animations, and other such mistakes of years
gone by.
Dialog -- not so much. Tabs/Accordion -- why bother?

Autocomplete has promise - they thought out the key-bindings to increase
functionality pretty darn well and doing nothing more than spitting back
a query result via some PHP'd json_encode() is nice - but I still find
kinks in the manner I use it. So far a little custom CSS has fixed "my"
bugs though. I'll be curious what the final version looks like.

What requirements are important for Autocomplete?

I've not yet finished unit tests for mine. I'm interested in hearing
considerations.
 
D

David Mark

Doug said:
That's the best double negative I've seen in a long time.

Thanks! It was certainly intentional, but the ironic context is lost in
this quote.
 
D

David Mark

Garrett said:
The jQuery datepicker that uses mm/dd/yyyy?

Does it?
http://jqueryui.com/demos/datepicker/

That Datepicker does not meet basic usability and accessibility
criteria. It uses a nonstandard date format (YYYY-MM-DD) and provides no
indication of what format the user should enter, should js be disabled.

Ah, it doesn't. And wouldn't such a widget vanish on scripting being
disabled (leaving 1-3 text inputs?) Perhaps they include some
ill-conceived static markup with the script? That's just what we need
jQuery for (designing cruddy markup to go with their cruddy scripts).
It is not keyboard friendly.

They never are.
There is no way to navigate years.

LOL. Minor detail. :)
It
breaks bfcache.

They always do. :(
The format mm/dd/yyyy is nonstandard and worse, is not stated in the
label.
OMFG.

That is bad usability. Instead, the label should use a standard
format and indicate that format clearly in the label where the user will
unavoidably see it, e.g.
Yes.


Date (YYYY-MM-DD): [ ]
(It is also acceptable to additionally use placeholder text that
contains that standard format).

When entering of an ISO-8601 date format, the user is prevented (only
when javascript is enabled). What I mean is that typing: "2012-", the
"-" character is not entered.

OMFG again. How do people recommend using widgets by jQuery (or Dojo)
mavens with a straight face. Assuming the recommender is looking to
make money, it's fraud if you ask me. Gee, look I can save you lots of
time and money by "leveraging" these "well-tested" and popular widgets. :)

http://www.cinsoft.net/
The datepicker cannot navigate years.

So you said.
Try entering your birthdate using
the "month back" button. Not nice at all and even you kids out there
trying this out can see how aggravating that can be.

It was probably written by a child. I get the feeling many of the
jQuery plug-ins are.
Not keyboard accessible! The calendar should be navigable by the
keyboard keys. I hate sites that force me to use my trackpad.

I think this is starting to repeat.
Regarding bfcache that I mentioned earlier: You might notice is that in
Firefox, or another browser that ties bfcache to unload, is that when
navigating back, the Calendar disappears, and whatever was visible in
the calendar is gone, and so you have to navigate the thing to the right
month again.

Yep. I remember dealing with that on writing a similar widget in 1998.
(!) Rich text editors often have the same problem, some resorting to
bizarre hacks (that the author(s) confirm work in whatever browser(s)
they have lying around _today_). :(
The bfcache breakage is caused by unload event handlers.

That's right. :)
Such design is
not optimal for a more complicated RIA, where in most cases, the user
would want the page to load as quickly as possible and retain its state
on hitting "back" button.

Yep. You can make the equivalent of an MDI in most major browsers if
you do it right, with each document view retaining its full state. It's
very powerful and leverages what the browser does best (navigation), so
it is no wonder it was the first thing the Ajax zealots stepped on.
I believe in the requirements:
* works with JS disabled

Not necessarily. For instance, popups can just cease to exist, leaving
behind the original text input(s). Depends on the context.
* provides indication of date format in label

Always good!
* uses INPUT type="date", where available

I suppose you could try to create one and detect its methods.
* fallback to js-driven calendar widget
* uses ISO 8601 format
* full keyboard a11y
* can navigate years and months

I think that last one goes without saying. It's sort of like requiring
a car to have at least two gears. I can't imagine a calendar widget
that can't go back/forward a year at a time. What sort of maniac would
design such a thing?
Those requirements, with a partial implementation of HTML 5 input
type="date", are what I decided upon for my own Calendar widget.
http://dhtmlkitchen.com/ape/example/widget/Calendar/

and it's drag/drop which I like as well.

I hope that last bit is optional. You shouldn't normally need to drag
and drop a calendar widget.
I would never have

Usability assessments from unqualified individuals are often harmful.

Yes, like "look at this cool widgets; let's *use* those!"
This is particularly the case when you get sales and marketing thinking
they want the web page to work a certain way, such as to include a
popup, automatically draw focus to an input, scroll the viewport
automatically, marquee, gif animations, and other such mistakes of years
gone by.

Like calendars without year-based navigation? Of course, I've _never_
seen that one in 15 years. Leave it to jQuery. They really push the
envelope (right into the trash). :)
What requirements are important for Autocomplete?

I've not yet finished unit tests for mine.

Ah, unit tests are for suckers. :) Just post the thing.
I'm interested in hearing
considerations.

I consider it very irritating that you didn't respond to my <FAQENTRY>
post of a couple of days back. You want to get on that?!
 
D

David Mark

kangax said:
A colleague of mine recently informed me with the emphatic title:
"HTML5, CSS3, and omg finally AddEventListener in new IE9!"

With a link to:
http://ie.microsoft.com/testdrive/

[...]

I was testing preview of IE9 on Vista yesterday and posted some of the
initial observations on twitter (http://twitter.com/kangax). Most
notable change — IE can now actually render documents served as
application/xhtml+xml.

Dear God. Why did they bother with that at this late date?
When it comes to JScript/DOM, some things are
tweaked, but a lot of old cruft still remains.

Here are some of those findings:


What happened to #ES5 in #IE9? No String#trim, no Function#bind, no
Object.create, no Array.isArray, no accessors.

Pfft. But I'll reserve final dismissal when and if it is released.
In #IE9 host objects still (!) don't inherit from `Object`/`Function`
(`window.alert instanceof Function === false`). Not good.

Eh, I just don't care as I've learned not to assume much of anything
about host objects.
On the bright side, Array#slice can now convert NodeLists to array!
[].slice.call(document.getElementsByTagName('*')) instanceof Array==true

Cool! That means they will switch to the "fast lane" in a few places in
My Library.
In #IE9, attributes and properties are still (!) mapped to each other.
Some things never change? :)

What?! They fixed that (mostly) in IE8 (standards mode). The
"breakdown lane" fork is only taken in compatibility mode in the current
version.
Same bugs in #IE9: gEBTN returns comment nodes, innerHTML is buggy with
select/table elements, gEBN mixes names and ids.

Some things never change.
Named function expressions still leak identifier to enclosing scope in
#IE9. IE team promises to fix things: http://bit.ly/aCCYWY

They are really good at promising to fix things. Of course...
#IE9 good part: Object.defineProperty now works with non-host objects
`Object.defineProperty({ }, 'x', { value: 'y', writable: false })`

Host object madness continues: `window.window === window` is still
`false` in #IE9 :)

Ignore them. Just walk away. They aren't worth worrying about.
#IE9 fails 10 out of 24 tests when it comes to `delete` conformance —
http://bit.ly/9Xd7Bd (must be preview issue, since IE8 fails only 3)

#IE9 still thinks that 4096 CSS rules should be enough for anyone —
http://bit.ly/71BKUL

Well, it really should. :)
OMG. #IE9 actually _renders_ XHTML served as... "application/xhtml+xml"
I can not believe this...

That was really stupid of them. It's a dead language now.
#IE9 good part: Host objects are less crazy. `document.x=1; delete x`
doesn't throw and `typeof document.forms.item` is no longer a "string"

The latter is interesting, but I just never found a need (or even a
want) to use the - item - methods.
[email protected] Unfortunately, there's still "unknown" type which throws
error on [[Get]] `document.createElement('p').offsetParent+''`; // boom
:)


[email protected] DontEnum bug seems to be fixed. Yay! `for (var p in {
toString: 1 }) console.log(p); // logs "toString"` #IE9
Good.


[email protected] Nope, no __proto__, __parent__, __defineGetter__, or `watch`
in #IE9

Don't care.
Whitespace character class still doesn't match NO-BREAK SPACE
`/\s/.test('\u00A0') === false` #IE9

Ah well. That's easy enough to feature test if you need to make such a
discrimination.
Not only is there no `Array.prototype.*` extras (forEach, map, reduce),
but even basic JS1.6 `indexOf` is missing. Sad. #IE9

Oh well. They'll stay in the slow lanes on those then.
Event object passed to event handler (added with `addEventListener`) is
NOT an `instanceof Event`. #IE9

Don't care what instanceof says about anything (particularly not host
objects).
And there's still only a proprietary innerText in #IE9, not DOM L3
Node::textContent :) Ok, let's wait and see what next update will bring..

Half a dozen of one, six of the other. Granted, depending on context,
the incompatibilities can be irritating. But then I don't think every
browser exactly agrees on textContent either.
 
R

Richard Cornford

A colleague of mine recently informed me with the emphatic title:
"HTML5, CSS3, and omg finally AddEventListener in new IE9!"

[...]

I was testing preview of IE9 on Vista yesterday

It is probably worth mentioning that this IE 9 preview will only
install on Vista SP2 or later OSs and requires IE 8 to already be
installed.
and posted some of the
initial observations on twitter (http://twitter.com/kangax).
Most notable change IE can now actually render documents
served as application/xhtml+xml.
<snip>

Render, maybe, but the important question for us is does it create an
XHTML DOM, or is it just accepting the content type and using its
normal HTML DOM (that is, doing no more than tag soup-ing and error-
correcting the mark-up)? Does the DOM have the namespace qualified DOM
methods (e.g. - createElementNS -), and if so, do they work correctly
(can you create both XHTML and non-XHTM XML elements, for example).
Are the element names case-sensitive (with the XHTML names lowercase)?
Does - document.wirte - work in that DOM? (where its not working is
not standard, but is the norm with XHTML DOMs). If not, how does it
fail (silently or not)?

If we have a situation where all IE is going to do is accept the
content type, but still treat the result as (tag soup) HTML then the
result will be the worst of all possible worlds.

How does the Rendering cope with mixed namespace mark-up?

Richard.
 
Ad

Advertisements

M

Matt Kruse

Now, you say you will be like Matt Kruse and never
upgrade jQuery?

I wish you would stop spewing that line, as you are misrepresenting my
original statements. I have upgraded jQuery since that original
discussion.

Matt Kruse
 
D

David Mark

Matt said:
I wish you would stop spewing that line, as you are misrepresenting my
original statements. I have upgraded jQuery since that original
discussion.

Whatever. I wish you wouldn't barge in here talking BS. How about that?
 
G

Garrett Smith

David said:
Garrett said:
The jQuery datepicker that uses mm/dd/yyyy?

Does it?
http://jqueryui.com/demos/datepicker/

That Datepicker does not meet basic usability and accessibility
criteria. It uses a nonstandard date format (YYYY-MM-DD) and provides no
indication of what format the user should enter, should js be disabled.

Ah, it doesn't. And wouldn't such a widget vanish on scripting being
disabled (leaving 1-3 text inputs?) Perhaps they include some
ill-conceived static markup with the script? That's just what we need
jQuery for (designing cruddy markup to go with their cruddy scripts).
It is not keyboard friendly.

They never are.
There is no way to navigate years.

LOL. Minor detail. :)
It
breaks bfcache.

They always do. :(
The format mm/dd/yyyy is nonstandard and worse, is not stated in the
label.
OMFG.

That is bad usability. Instead, the label should use a standard
format and indicate that format clearly in the label where the user will
unavoidably see it, e.g.
Yes.

Date (YYYY-MM-DD): [ ]
(It is also acceptable to additionally use placeholder text that
contains that standard format).

When entering of an ISO-8601 date format, the user is prevented (only
when javascript is enabled). What I mean is that typing: "2012-", the
"-" character is not entered.

OMFG again. How do people recommend using widgets by jQuery (or Dojo)
mavens with a straight face. Assuming the recommender is looking to
make money, it's fraud if you ask me. Gee, look I can save you lots of
time and money by "leveraging" these "well-tested" and popular widgets. :)

http://www.cinsoft.net/
The datepicker cannot navigate years.

So you said.
Try entering your birthdate using
the "month back" button. Not nice at all and even you kids out there
trying this out can see how aggravating that can be.

It was probably written by a child. I get the feeling many of the
jQuery plug-ins are.
Not keyboard accessible! The calendar should be navigable by the
keyboard keys. I hate sites that force me to use my trackpad.

I think this is starting to repeat.
Regarding bfcache that I mentioned earlier: You might notice is that in
Firefox, or another browser that ties bfcache to unload, is that when
navigating back, the Calendar disappears, and whatever was visible in
the calendar is gone, and so you have to navigate the thing to the right
month again.

Yep. I remember dealing with that on writing a similar widget in 1998.
(!) Rich text editors often have the same problem, some resorting to
bizarre hacks (that the author(s) confirm work in whatever browser(s)
they have lying around _today_). :(
The bfcache breakage is caused by unload event handlers.

That's right. :)
Such design is
not optimal for a more complicated RIA, where in most cases, the user
would want the page to load as quickly as possible and retain its state
on hitting "back" button.

Yep. You can make the equivalent of an MDI in most major browsers if
you do it right, with each document view retaining its full state. It's
very powerful and leverages what the browser does best (navigation), so
it is no wonder it was the first thing the Ajax zealots stepped on.
I believe in the requirements:
* works with JS disabled

Not necessarily. For instance, popups can just cease to exist, leaving
behind the original text input(s). Depends on the context.
* provides indication of date format in label

Always good!
* uses INPUT type="date", where available

I suppose you could try to create one and detect its methods.
* fallback to js-driven calendar widget
* uses ISO 8601 format
* full keyboard a11y
* can navigate years and months

I think that last one goes without saying. It's sort of like requiring
a car to have at least two gears. I can't imagine a calendar widget
that can't go back/forward a year at a time. What sort of maniac would
design such a thing?
Those requirements, with a partial implementation of HTML 5 input
type="date", are what I decided upon for my own Calendar widget.
http://dhtmlkitchen.com/ape/example/widget/Calendar/

and it's drag/drop which I like as well.

I did not write that; S.T. did.
I hope that last bit is optional. You shouldn't normally need to drag
and drop a calendar widget.

No. I remember old DOjo Datepicker was d'n'd and was against proj.
requirements that it did that, so it was required to remove that
functionality (that was prior to removing Dojo, which never should have
been used, except the manager wanted to "save time" and "not rewrite
everything from scratch".
Yes, like "look at this cool widgets; let's *use* those!"


Like calendars without year-based navigation? Of course, I've _never_
seen that one in 15 years. Leave it to jQuery. They really push the
envelope (right into the trash). :)


Ah, unit tests are for suckers. :) Just post the thing.
Unit tests are one of the most important parts of my development.

My unit tests facilitate change. When I find something that wants to be
changed, that changing that thing can be much more safely done, and
especially if that thing has dependencies.

The change might be to refactor something complicated to something
simple, or use a more efficient strategy.


When something is complicated, the unit tests verify each thing that it
does and if it is doing something that is not being tested, that thing
can be looked at for removal.
I consider it very irritating that you didn't respond to my <FAQENTRY>
post of a couple of days back. You want to get on that?!
I don't read all of your posts, but I think I just found the one you meant.
 
S

S.T.

The jQuery datepicker that uses mm/dd/yyyy?
http://jqueryui.com/demos/datepicker/

That Datepicker does not meet basic usability and accessibility
criteria. It uses a nonstandard date format (YYYY-MM-DD) and provides no
indication of what format the user should enter, should js be disabled.
It is not keyboard friendly. There is no way to navigate years. It
breaks bfcache.

The format mm/dd/yyyy is nonstandard

$('#theDate').datepicker({dateFormat:'yyyy-mm-dd'});

BTW: The default mm/dd/yy or yyyy is VERY standard in the U.S. Believe
me. Last year our company loaded 78,462 lodging rates from 1,414 lodging
properties. I built the UI that's used for the data entry.

Almost without exception the rates provided to our data entry people are
mm/dd/yy(yy) -- perhaps that's because >80% of the properties are in the
U.S.

Hence, for data entry's sanity I leave the default date format despite
needing to convert it back and forth to a more tech-standard yyyy-mm-dd
each time it touches a database.

Should the default date format be YYYY-mm-dd rather than the more U.S.
centric present default? Perhaps, but it's trivial to adjust.
and worse, is not stated in the
label. That is bad usability. Instead, the label should use a standard
format and indicate that format clearly in the label where the user will
unavoidably see it, e.g.
Date (YYYY-MM-DD): [ ]
(It is also acceptable to additionally use placeholder text that
contains that standard format).

When entering of an ISO-8601 date format, the user is prevented (only
when javascript is enabled). What I mean is that typing: "2012-", the
"-" character is not entered.

It's a fair point but I'll add... if it's a public site, labels don't
matter much. I deal with a HUGE amount of user-submitted dates and a
remarkable percentage won't pay attention to desired format. They'll
enter 'dec 5', 'dec 5 10', '12/5 2010' or whatever they feel like.
Telling the user they've made an error isn't really an option for a
non-captive audience (the IRS might be able to get away with it).
Generally have to use server-side to interpret any user entered date.

The U.S. mm/dd versus Euro/Aussie dd/mm is really my pain in the ass.
The datepicker cannot navigate years. Try entering your birthdate using
the "month back" button. Not nice at all and even you kids out there
trying this out can see how aggravating that can be.

$('#theDate').datepicker({changeYear: true});

If using it for birth dates, probably would want to adjust the default
yearRange option which is set to +/- 10 years from today.
Not keyboard accessible! The calendar should be navigable by the
keyboard keys. I hate sites that force me to use my trackpad.

* page up/down - previous/next month
* ctrl+page up/down - previous/next year
* ctrl+home - current month or open when closed
* ctrl+left/right - previous/next day
* ctrl+up/down - previous/next week
* enter - accept the selected date
* ctrl+end - close and erase the date
* escape - close the datepicker without selection

I guess you can argue about choice of key bindings they mapped, but it's
there and quite thorough.
Regarding bfcache that I mentioned earlier: You might notice is that in
Firefox, or another browser that ties bfcache to unload, is that when
navigating back, the Calendar disappears, and whatever was visible in
the calendar is gone, and so you have to navigate the thing to the right
month again.

The bfcache breakage is caused by unload event handlers. Such design is
not optimal for a more complicated RIA, where in most cases, the user
would want the page to load as quickly as possible and retain its state
on hitting "back" button.

I believe in the requirements:
* works with JS disabled
* provides indication of date format in label
* uses INPUT type="date", where available
* fallback to js-driven calendar widget
* uses ISO 8601 format
* full keyboard a11y
* can navigate years and months

Those requirements, with a partial implementation of HTML 5 input
type="date", are what I decided upon for my own Calendar widget.
http://dhtmlkitchen.com/ape/example/widget/Calendar/

It's a nice datepicker. I personally like a dropdown for month selection
if I believe the user will be selecting dates a fair distance from the
starting date -- the month in a <select> also seems to highlight the
month -- but that would be my only critique for the way I use datepickers.

I'm not seeing the bfcache effect you're talking about (on FF3.6 at
least). Seems to function identically to the jQuery UI one. Pops open to
the chosen date if one exists in the input or current date if one
doesn't exist no matter what, which seems to be identical.
and it's drag/drop which I like as well. I would never have

Usability assessments from unqualified individuals are often harmful.
This is particularly the case when you get sales and marketing thinking
they want the web page to work a certain way, such as to include a
popup, automatically draw focus to an input, scroll the viewport
automatically, marquee, gif animations, and other such mistakes of years
gone by.

I assess usability based on the only people using it. On the intranet
stuff it's basically built to spec. I also end up redoing things quite
often based on an individual -- for instance shifting a UI from
something more keyboard-based entry to more point-and-click if that's
their preference. 45 minutes of work on my part makes their next couple
thousand work hours slightly more efficient for them -- the math works.

Aside from the 3-6 "tweak requests" I field each week, at least once a
month I'll watch how people work, make some changes based on what I've
seen, and throw up a test branch and have them try it out for a day or
two. Sometimes they like it and it makes the cut, sometimes not and that
fork is killed off. Another reason I like jQuery's development speed -
hurts less when I "git branch -D myCoolIdea"
What requirements are important for Autocomplete?

I've not yet finished unit tests for mine. I'm interested in hearing
considerations.

They've done a nice job with keybindings. Arrow up/down as expected, but
also pageUp/pageDown to move to the top/bottom of the output list. It's
a handy feature many don't include. If you see what you want second to
last of 25 results, nice to pageDown->upArrow versus downArrow*24 or
grabbing your mouse.

Formatting inside the output list is important as is returning a
different value than the actual text of the selection.

For example, the way I'm using it: I have a 'Look Up' box to find quotes
(we coordinate and sell travel, like a small scale Expedia). Users can
start entering a quote number or a guest name in that box to find what
they're after. On a autocomplete the 'results' page will lookup matching
quote numbers if the entry is numeric or search client name if the query
is text. The results fed back, regardless of the format of the query, is
a LOT of data - quote #, guest name, salesperson, destination, travel
date. All fields are formatted in different colors to the make the
output list easy to scan. Upon selection only an unrelated-to-results
list id number is fed back, then a callback uses that number to do it's
task.

The jQueryUI autocomplete is quite adaptable and handles these needs
well. My only real issue is it appears (haven't tested thoroughly) they
tied the width of the autocomplete results container to the width of the
original input box. I can understand why they might have done that as
less likely to cause a horizontal scroll when results appear, but didn't
work for my needs as I was relaying a great deal of additional
information versus what would ever be entered in the input.

That's where the custom CSS came in, to force the width of the container
box to something different than the input width. Took some firebug work
to find the rule to change, and because it's CSS is so tightly tied to
the framework's CSS, might have to fix again once it finishes beta. Also
unclear why it wouldn't function on the IE9 preview, but I won't worry
about that much until jQueryUI 1.8 is out of beta (autocomplete is new
and doesn't exist in production versions yet) and/or IE9 moves a bit
closer to a release candidate.
 
D

David Mark

S.T. said:
$('#theDate').datepicker({dateFormat:'yyyy-mm-dd'});

BTW: The default mm/dd/yy or yyyy is VERY standard in the U.S. Believe
me. Last year our company loaded 78,462 lodging rates from 1,414 lodging
properties. I built the UI that's used for the data entry.

Why do you always do this? I suppose it is a good way to learn. :)
You and your empirical evidence. How many do you suppose you might have
logged if, for the sake of argument, _I_ had built the UI used for the
data entry. :)
Almost without exception the rates provided to our data entry people are
mm/dd/yy(yy) -- perhaps that's because >80% of the properties are in the
U.S.

Provided how?
Hence, for data entry's sanity I leave the default date format despite
needing to convert it back and forth to a more tech-standard yyyy-mm-dd
each time it touches a database.
Sanity?


Should the default date format be YYYY-mm-dd rather than the more U.S.
centric present default? Perhaps, but it's trivial to adjust.

Why should you have to adjust it just to conform to standards?
and worse, is not stated in the
label. That is bad usability. Instead, the label should use a standard
format and indicate that format clearly in the label where the user will
unavoidably see it, e.g.
Date (YYYY-MM-DD): [ ]
(It is also acceptable to additionally use placeholder text that
contains that standard format).

When entering of an ISO-8601 date format, the user is prevented (only
when javascript is enabled). What I mean is that typing: "2012-", the
"-" character is not entered.

It's a fair point but I'll add... if it's a public site, labels don't
matter much.
Labels?

I deal with a HUGE amount of user-submitted dates and a
remarkable percentage won't pay attention to desired format.
So?

They'll
enter 'dec 5', 'dec 5 10', '12/5 2010' or whatever they feel like.

And it is up to you to deal with those eventualities. How does the
jQuery thing do with each?
Telling the user they've made an error isn't really an option for a
non-captive audience (the IRS might be able to get away with it).
Generally have to use server-side to interpret any user entered date.

The U.S. mm/dd versus Euro/Aussie dd/mm is really my pain in the ass.

Well, perhaps if you followed standards, it wouldn't be. ;)
$('#theDate').datepicker({changeYear: true});

LOL. That's not navigation.
If using it for birth dates, probably would want to adjust the default
yearRange option which is set to +/- 10 years from today.


* page up/down - previous/next month
* ctrl+page up/down - previous/next year
* ctrl+home - current month or open when closed
* ctrl+left/right - previous/next day
* ctrl+up/down - previous/next week
* enter - accept the selected date
* ctrl+end - close and erase the date
* escape - close the datepicker without selection

Assuming they handle keyboard input properly (and the browser
configuration doesn't get in the way), which I'll go out on a limb and
say they don't and it likely will, maybe that will work (for some people).
I guess you can argue about choice of key bindings they mapped, but it's
there and quite thorough.

Definitely not what I would have done.
It's a nice datepicker. I personally like a dropdown for month selection
if I believe the user will be selecting dates a fair distance from the
starting date -- the month in a <select> also seems to highlight the
month -- but that would be my only critique for the way I use datepickers.

I'm not seeing the bfcache effect you're talking about (on FF3.6 at
least). Seems to function identically to the jQuery UI one. Pops open to
the chosen date if one exists in the input or current date if one
doesn't exist no matter what, which seems to be identical.

Haven't seen either, so can't comment. But basically, if the DOM is not
preserved _exactly_ on back/forward, something is amiss. IIRC, jQuery
breaks fast history navigation. And even if they stop doing it, the
plug-ins and widgets will likely continue to do it (like with the UA
sniffing).
I assess usability based on the only people using it. On the intranet
stuff it's basically built to spec. I also end up redoing things quite
often based on an individual -- for instance shifting a UI from
something more keyboard-based entry to more point-and-click if that's
their preference. 45 minutes of work on my part makes their next couple
thousand work hours slightly more efficient for them -- the math works.

Aside from the 3-6 "tweak requests" I field each week, at least once a
month I'll watch how people work, make some changes based on what I've
seen, and throw up a test branch and have them try it out for a day or
two. Sometimes they like it and it makes the cut, sometimes not and that
fork is killed off. Another reason I like jQuery's development speed -
hurts less when I "git branch -D myCoolIdea"

For God's sake, jQuery is not helping you (sure as hell not to save time).
They've done a nice job with keybindings. Arrow up/down as expected, but
also pageUp/pageDown to move to the top/bottom of the output list. It's
a handy feature many don't include. If you see what you want second to
last of 25 results, nice to pageDown->upArrow versus downArrow*24 or
grabbing your mouse.

Paging would seem a standard requirement.
Formatting inside the output list is important as is returning a
different value than the actual text of the selection.

For example, the way I'm using it: I have a 'Look Up' box to find quotes
(we coordinate and sell travel, like a small scale Expedia). Users can
start entering a quote number or a guest name in that box to find what
they're after. On a autocomplete the 'results' page will lookup matching
quote numbers if the entry is numeric or search client name if the query
is text. The results fed back, regardless of the format of the query, is
a LOT of data - quote #, guest name, salesperson, destination, travel
date. All fields are formatted in different colors to the make the
output list easy to scan. Upon selection only an unrelated-to-results
list id number is fed back, then a callback uses that number to do it's
task.

The jQueryUI autocomplete is quite adaptable and handles these needs
well.

Depends on your definition of well I suppose. Why wouldn't you just
spend a few hours (tops) and write this enhancement. It's basically a
text input and a DIV plus a bit of Ajax. Why on earth would you bind
your project to jQuery (of all things) to get such functionality?
My only real issue is it appears (haven't tested thoroughly) they
tied the width of the autocomplete results container to the width of the
original input box.

LOL. That would seem to fly in the face of a standard requirement.
Would _you_ have done it that way?
I can understand why they might have done that as
less likely to cause a horizontal scroll when results appear, but didn't
work for my needs as I was relaying a great deal of additional
information versus what would ever be entered in the input.

No, I can assure you it has nothing to do with horizontal scroll bars
(except perhaps in their heads). More likely they just thought it
looked pretty that way.
That's where the custom CSS came in, to force the width of the container
box to something different than the input width. Took some firebug work
to find the rule to change, and because it's CSS is so tightly tied to
the framework's CSS, might have to fix again once it finishes beta.

Do you see your mistake(s) now? In the time you spent monitoring some
subject-to-change (endless) Beta jQuery wonder-widget, writing hacks for
it, etc., you could have had the thing in the bag (proper widths and all).
Also
unclear why it wouldn't function on the IE9 preview, but I won't worry
about that much until jQueryUI 1.8 is out of beta (autocomplete is new
and doesn't exist in production versions yet) and/or IE9 moves a bit
closer to a release candidate.

I wouldn't worry at all about IE9 at the moment. I would worry about
anything to do with jQueryUI. Do you understand that the people writing
it are deluded neophytes and they are building on top of the output of
another one (and with no mechanism to keep them in sync?) I've seen
some of the related discussions and they are chilling. It's the same
thing with Dojo, these people do not understand that you cannot write
code that branches on today's observations. Think about that. Their
whole pitch is that the Web moves so fast that you need an army of
hacker-ninjas to keep up with just a handful of the latest browsers
(which is a ludicrous enough concept by itself). Now how does that
correlate with the inane practice of writing logic based on what you can
see in your current browsers _today_. Doesn't make a whit of sense,
does it? I guess the contract they are offering is that they'll just
keep churning out new scripts every month for you to download and
re-test and then you have to contract with your end-users to upgrade
their browsers to keep up with _you_. And if anyone at any level
complains, just tell them you "don't care" about whatever it is they are
complaining about. Yeah, that strategy's got legs. :)

And how long does it take to write an auto-complete anyway? Why should
you wait for them to write what they think is appropriate for
_everybody_ (clearly can't be ideal for any individual's needs) when you
could write your own in a few hours and have it do exactly what you need
to do without the anchor of a 70K+ blob of CSS selector query nonsense.
 
Ad

Advertisements

S

S.T.

Why do you always do this? I suppose it is a good way to learn. :)
You and your empirical evidence.
http://en.wikipedia.org/wiki/File:Date.png

How many do you suppose you might have
logged if, for the sake of argument, _I_ had built the UI used for the
data entry. :)


Provided how?


Why should you have to adjust it just to conform to standards?

Perhaps I didn't explain what they're doing. Data entry people get rate
sheets via PDF, Excel file, fax, postal mail, etc. It might look
something like rates seen in:

http://bit.ly/aEFHfB

All these rates, perhaps a thousand pages worth from hundreds of
different sources, have to be merged into a database. There is no
standard format for rate sheets. Some will have dates as column headers,
others may have dates as row headers. Some will have multiple date
ranges that have an identical rate lumped together in a single
column/row, others will show all date ranges in chronological order
regardless of duplicate rates, and so on.

The only thing truly consistent is these rates are NEVER provided
yyyy-mm-dd. In the case of US properties, mostly what we handle,
they're almost always mm/dd/yy(yy). A few we receive, especially
Canadian, will be dd mmm yyyy (5 Sep 2010). But mostly, it's the mm/dd/yyyy

"My" data entry users will overwhelmingly see the dates they need to
enter in a mm/dd/yy(yy) format. It would be borderline cruel for me to
have them enter them as yyyy-dd-mm simply because that's how databases
and programmers like to see dates.
LOL. That's not navigation.

It's a dropdown of years. It's the most intuitive by-year navigation I
can think of. Beats clicking on a little icon 50 times to get to 1960.
Assuming they handle keyboard input properly (and the browser
configuration doesn't get in the way), which I'll go out on a limb and
say they don't and it likely will, maybe that will work (for some people).

There's already a conflict with the Ctrl-pageUp/pageDown on some
browsers. Such will always be the case with browsers and keyboard input
as the "Hi, we're browser XX. Look at all our shortcuts we've enabled by
default and 99% of you will never use!!" war continues. No guarantee you
can disable/override built-in keyboard shortcuts now or in the future.
Is your solution simply not to provide keyboard shortcuts because
there's no guarantee they'll always work?

In any case, probably wise of the jQueryUI team to not disable built-in
browser shortcuts.
LOL. That would seem to fly in the face of a standard requirement.
Would _you_ have done it that way?

Container width = input width is the fairly common interpretation, as
seen on Google/Yahoo/Bing's usage or virtually anywhere else I've seen
autocomplete in use.

http://ui-patterns.com/pattern/Autocomplete

"The list of suggested items is most often displayed directly beneath
the input text box and has a width that matches the width of the text box."

I can't fault them for defaulting to that pattern - it's logical and
result width needs to be constrained. Do wish the container width was a
configurable option however versus combing through CSS. The widget's not
finished yet - who knows?
 
G

Garrett Smith

S.T. said:

Are you attempting to communicate something of meaningful value there,
or do you just like random links?

[...]
Perhaps I didn't explain what they're doing. Data entry people get rate
sheets via PDF, Excel file, fax, postal mail, etc. It might look
something like rates seen in:

http://bit.ly/aEFHfB

All these rates, perhaps a thousand pages worth from hundreds of
different sources, have to be merged into a database. There is no
standard format for rate sheets. Some will have dates as column headers,
others may have dates as row headers. Some will have multiple date
ranges that have an identical rate lumped together in a single
column/row, others will show all date ranges in chronological order
regardless of duplicate rates, and so on.

The only thing truly consistent is these rates are NEVER provided
yyyy-mm-dd. In the case of US properties, mostly what we handle,
they're almost always mm/dd/yy(yy). A few we receive, especially
Canadian, will be dd mmm yyyy (5 Sep 2010). But mostly, it's the mm/dd/yyyy

So what?
"My" data entry users will overwhelmingly see the dates they need to
enter in a mm/dd/yy(yy) format. It would be borderline cruel for me to
have them enter them as yyyy-dd-mm simply because that's how databases
and programmers like to see dates.

Gee, I didn't know the rest of the world was a Database.
It's a dropdown of years. It's the most intuitive by-year navigation I
can think of. Beats clicking on a little icon 50 times to get to 1960.

Is there a dropdown in that datepicker? I don't see it.
That one is correct.


That one is correct.

There are only two shortcut keys that are correct. The rest - Are you
kidding? ctrl+page up to select previous year, plus other such wacky
shortcuts. Who is going to remember and use that stuff? It is junk.

Why can't I just type the date in a normal standard input? Just get rid
of that horrible junk and give me a text box so I can type it in. Don't
prevent the user from entering a standard format. Don't anticipate that
everyone is as dumb and wants the mm/dd/yy format.

Hopefully the server side programmers aren't dumb enough that they want
mm/dd/yy and can actually handle a standard ISO-8601 format.
There's already a conflict with the Ctrl-pageUp/pageDown on some
browsers. Such will always be the case with browsers and keyboard input
as the "Hi, we're browser XX. Look at all our shortcuts we've enabled by
default and 99% of you will never use!!" war continues. No guarantee you
can disable/override built-in keyboard shortcuts now or in the future.
Is your solution simply not to provide keyboard shortcuts because
there's no guarantee they'll always work?

In any case, probably wise of the jQueryUI team to not disable built-in
browser shortcuts.


Container width = input width is the fairly common interpretation, as
seen on Google/Yahoo/Bing's usage or virtually anywhere else I've seen
autocomplete in use.

I know I would not do that. I would provide an ID for the container so
it can be customized in CSS. e.g.

#myInput-list {
width: 10em;
}

Let it be as wide as it needs to be. An Autocomplete could have images.
I have right here in front of me a demon that has images large text and
when the object is focused outside the viewport (by user hitting DOWN
arrow key), then scrollIntoView brings it into view. Not desirable, but
less bad than the user not seeing it at all.
http://ui-patterns.com/pattern/Autocomplete

"The list of suggested items is most often displayed directly beneath
the input text box and has a width that matches the width of the text box."

I can't fault them for defaulting to that pattern - it's logical and
result width needs to be constrained. Do wish the container width was a
configurable option however versus combing through CSS. The widget's not
finished yet - who knows?
The container does not have an ID? What is it appended to? Can you use
descendant selector?

I would rather have the option of:

#myInput, #myInput-list {
width: 10em;
}

to make the same width if I want that. It doesn't seem that hard to
configure, not to me at least. Then again, I can see how others would
have problems iwht it.
 
Ad

Advertisements

D

David Mark

S.T. said:

What is that supposed to prove?
Perhaps I didn't explain what they're doing. Data entry people get rate
sheets via PDF, Excel file, fax, postal mail, etc. It might look
something like rates seen in:

http://bit.ly/aEFHfB

All these rates, perhaps a thousand pages worth from hundreds of
different sources, have to be merged into a database. There is no
standard format for rate sheets. Some will have dates as column headers,
others may have dates as row headers. Some will have multiple date
ranges that have an identical rate lumped together in a single
column/row, others will show all date ranges in chronological order
regardless of duplicate rates, and so on.

The only thing truly consistent is these rates are NEVER provided
yyyy-mm-dd. In the case of US properties, mostly what we handle,
they're almost always mm/dd/yy(yy). A few we receive, especially
Canadian, will be dd mmm yyyy (5 Sep 2010). But mostly, it's the mm/dd/yyyy

So, do you see your mistake?
"My" data entry users will overwhelmingly see the dates they need to
enter in a mm/dd/yy(yy) format.

But not always, so...
It would be borderline cruel for me to
have them enter them as yyyy-dd-mm simply because that's how databases
and programmers like to see dates.


It's a dropdown of years. It's the most intuitive by-year navigation I
can think of. Beats clicking on a little icon 50 times to get to 1960.

I was referring to your example (code).
There's already a conflict with the Ctrl-pageUp/pageDown on some
browsers.

And there can be conflicts with virtually all of those (e.g. arrow
keys). My main point is that keyboard input is virtually always handled
incompetently (usually with browser sniffing).

http://www.cinsoft.net/keyboard.html
Such will always be the case with browsers and keyboard input
as the "Hi, we're browser XX. Look at all our shortcuts we've enabled by
default and 99% of you will never use!!" war continues.

It's not a war (except perhaps in the heads of overzealous Web app
designers).
No guarantee you
can disable/override built-in keyboard shortcuts now or in the future.

I know.
Is your solution simply not to provide keyboard shortcuts because
there's no guarantee they'll always work?
Nope.


In any case, probably wise of the jQueryUI team to not disable built-in
browser shortcuts.

They couldn't disable them if they tried. :)
Container width = input width is the fairly common interpretation, as
seen on Google/Yahoo/Bing's usage or virtually anywhere else I've seen
autocomplete in use.

Why do you always cite incompetent Websites (e.g. Google) as examples?
Assuming that the width of the text input is sufficient for the results
in the drop down is a common *mistake*, which you have apparently seen.

Again, what is that supposed to prove? And I certainly have no interest
in some random auto-complete primer. ;)
"The list of suggested items is most often displayed directly beneath
the input text box and has a width that matches the width of the text box."

Glad I skipped it. Treat everything on the Web as if it were on the
television (e.g. most of the points you will find are based on
misconceptions or outright lies).
I can't fault them for defaulting to that pattern - it's logical and
result width needs to be constrained.

That's not how you constrain the results width. If it is in danger of
going off the edge of the viewport, then you either shift the position,
allow a scroll bar or use ellipsis as needed.
Do wish the container width was a
configurable option however versus combing through CSS. The widget's not
finished yet - who knows?

Better still, who cares? ;)
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top