Microsoft and IE9 New Features


D

David Mark

Garrett said:
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?

So it shows that S.T. hasn't thought about what he is writing, which
illustrates a problem and dismisses the obvious solution.
Gee, I didn't know the rest of the world was a Database.


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.
Yep.


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.

Hope springs eternal.
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;
}

Why would you do that? The width of the drop down would certainly need
to be dynamic. The width of the input would typically be the minimum
(for aesthetic reasons), but often it may need to grow from there to
accommodate the suggestions.
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.

I don't quite follow that (and definitely don't see where the
scrollIntoView method would come into play).
 
Ad

Advertisements

D

David Mark

kangax said:
On 3/16/10 6:17 PM, Garrett Smith wrote:

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

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.

Didn't know about SP2. I used one of the virtual machine images laying
around; going through closing dozens of popups while installing IE9 was
fun.

I've created a simple test page
(<http://yura.thinkweb2.com/test.xhtml>), served as
"application/xhtml+xml". I don't have much time at the moment, so only
did few cursory checks. I'm also not familiar with XHTML DOM _at all_,
so please correct me if I did something stupid.

Nope, good job. Served with the correct MIME type and rendered without
exception (XHTML renderers are _very_ unforgiving of malformed markup).
Doesn't look like it. See below (input is marked with ">").

I don't think the results are conclusive.
Does the DOM have the namespace qualified DOM
methods (e.g. - createElementNS -),
document.createElementNS;

function createElementNS() {
[native code]
}

(ditto for `getElementsByTagNameNS` and `createAttributeNS`)

Yes, but HTML DOM's have those too. The last one is used to create SVG,
which can be mixed in with HTML.
document.getElementsByTagNameNS(
'http://www.w3.org/2000/svg', 'polygon')[0];

[object SVGPolygonElement]
document.getElementsByTagName('polygon')[0];
undefined

Okay.
and if so, do they work correctly
(can you create both XHTML and non-XHTM XML elements, for example).

Apparently you can:
document.createElementNS(
'http://www.w3.org/2000/svg', 'circle').namespaceURI;

"http://www.w3.org/2000/svg"
document.createElement('circle').namespaceURI;
"http://www.w3.org/1999/xhtml"

Are the element names case-sensitive (with the XHTML names lowercase)?
Yes.

document.documentElement.tagName;

"html"

But what does this do:-

document.getElementsByTagNameNS(
'http://www.w3.org/2000/svg', 'POLYGON')[0]

Should also be undefined.
'http://www.w3.org/2000/svg', 'circle').tagName;

"circle"


What would be a good test for this?

Try calling that method. It will throw an exception in most XHTML DOM's
(if it is available at all).
Fortunately, this doesn't seem to be the case. I see that IE renders
embedded SVG more or less properly (on the test page, it fails to render
shape stroke properly; apparently setting width to something that looks
like "1", even though in markup, "stroke-width" is set to 10).

Sounds like a bug in their Beta. That's forgivable.
Curiously, MathML chunk is rendered as "plain text" (without any special
formatting). So what has to look like:

y = 1 / sqrt(x^2 + 1)

— IE9 displays as:

y = 1 x 2 + 1

— completely destroying the meaning of an equation.

They are good at destroying things, but then it's a Beta.
 
R

Richard Cornford

On 3/16/10 6:17 PM, Garrett Smith wrote:
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
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.

Didn't know about SP2. I used one of the virtual machine images
laying around; going through closing dozens of popups while
installing IE9 was fun.

The 'you need vista SP 2 or above' dialog was one of the ones I
encountered trying to install it on an XP machine.
I've created a simple test page
(<http://yura.thinkweb2.com/test.xhtml>), served as
"application/xhtml+xml". I don't have much time at the moment,
so only did few cursory checks. I'm also not familiar with
XHTML DOM _at all_, so please correct me if I did something
stupid.

I won't have time to look at that page today, but everything below
seems quite reasonable as far as tests go, and confirm what looks like
a proper XHTML DOM. Thanks for looking.

What would be a good test for this?

probably starting with verifying the existence of a - write - method
on the document, somewhere in the body including a script element that
contained a call to - document.write - that would, if it worked, still
result in valid XHTML and see if the mark-up written ended up in the
document (which is not expected, but just about possible). If there is
no apparent result, was an exception thrown or was the failure silent
(as I recall, Mozilla threw exceptions while Opera was silent, though
that was some time ago and things may have changed). I haven't looked
at the IE 9 preview's error reporting, so it might be worth doing the
test in a try-catch block and using - alert - to show (the messages
of) any exceptions thrown.
Fortunately, this doesn't seem to be the case. I see that IE
renders embedded SVG more or less properly (on the test page,
it fails to render shape stroke properly; apparently setting
width to something that looks like "1", even though in markup,
"stroke-width" is set to 10).

They have time to fins and fix those sorts of bugs.
Curiously, MathML chunk is rendered as "plain text" (without
any special formatting). So what has to look like:

y = 1 / sqrt(x^2 + 1)

- IE9 displays as:

y = 1 x 2 + 1

- completely destroying the meaning of an equation.

Presumably MathML is not supported, which is always going to happen
with some types of mixed mark-up. How that unsupported mark-up is
handled is probably a open to opinion, but showing the element's text
content seems fairly reasonable.

Some other test ideas might be derived from:-

<URL: https://developer.mozilla.org/en/Mozilla_Web_Developer_FAQ#section_11
Richard.
 
D

David Mark

kangax said:
On 3/18/10 8:41 AM, David Mark wrote:
[...]
But what does this do:-

document.getElementsByTagNameNS(
'http://www.w3.org/2000/svg', 'POLYGON')[0]

Should also be undefined.

Yep, it is `undefined`.

Sounds like they did a good job.
Method exists, but throws error. See below.

That is in line with what most of the others do.
[...]

I tweaked output on test page slightly, to make it more understandable.
Here's what I see in IE9:

document.write:
function write() { [native code]}

document.createElementNS:
function createElementNS() { [native code]}

document.createAttributeNS:
function createAttributeNS() { [native code]}

document.getElementsByTagNameNS:
function getElementsByTagNameNS() { [native code]}

document.body:
[object HTMLBodyElement]

Yeah, some XHTML DOM's will have this, as well as innerHTML (though the
latter never works for sets, even for well-formed XHTML).
document.documentElement.tagName:
html

document.getElementById('test').innerHTML:
<span class=foo>bar</span>

document.getElementById('test').outerHTML:
<div style="DISPLAY: none" id=test><span class=foo>bar</span></div>

document.getElementById('math-test'):
[object HTMLGenericElement]

document.getElementsByTagNameNS('http://www.w3.org/1999/xhtml', 'h1')[0]:
[object HTMLHeadingElement]

document.getElementsByTagNameNS('http://www.w3.org/2000/svg',
'polygon')[0]:
[object SVGPolygonElement]

document.getElementsByTagNameNS('http://www.w3.org/2000/svg',
'POLYGON')[0]:
undefined

document.getElementsByTagName('polygon')[0]:
undefined

document.createElementNS('http://www.w3.org/2000/svg',
'circle').namespaceURI:
http://www.w3.org/2000/svg

document.createElement('circle').namespaceURI:
http://www.w3.org/1999/xhtml

document.write(''):
Error:

document.getElementById('math-test').innerHTML:
<mrow><mi>y</mi> <mo>=</mo> <mfrac><mn>1</mn>
<msqrt><mrow><msup><mi>x</mi> <mn>2</mn> </msup><mo>+</mo> <mn>1</mn>
</mrow></msqrt></mfrac></mrow>

document.getElementById('math-test').outerHTML:
<math id=math-test
xmlns="http://www.w3.org/1998/Math/MathML"><mrow><mi>y</mi> <mo>=</mo>
<mfrac><mn>1</mn> <msqrt><mrow><msup><mi>x</mi> <mn>2</mn>
</msup><mo>+</mo> <mn>1</mn> </mrow></msqrt></mfrac></mrow></math>


Note how `document.write('')` throws error (although error's `message`
appears to be an empty string).

They seem to have a few things to clean up before release. That is an
odd one though. Did you try the description property of the Error object?
Interesting that `innerHTML` representation actually looks like an
invalid (if we consider it in context of PCDATA) chunk of XHTML, with
missing attribute value quotes:

Yeah, that's ugly. I suspect that setting it back wouldn't work
regardless of whether it was well-formed or not.
"<span class=foo>bar</span>"

I also tried `outerHTML` (thinking that property might very well not
even exist), and got similar results:

"<div style="DISPLAY: none" id=test><span class=foo>bar</span></div>"

Curiously, `innerHTML` and `outerHTML` even exist on elements from
within MathML namespace (see last 2 results). Note how outerHTML
representation of <math> element shows "xmlns" attribute value with
quotes — '<math id=math-test
xmlns="http://www.w3.org/1998/Math/MathML">', but "id" — without; which
all looks suspiciously similar to HTML 4.01 rules for quotes omission :)

Looks a bit hack-y. Well, they've got time (I imagine it will be years
before this is released).
 
S

S.T.

S.T. said:

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

[...]

I thought David was complaining I was imagining the US is very mm/dd/yy
centric. I often lose track of what he's talking about though.

It would be stupid to use yyyy-mm-dd formatting in this app.
Gee, I didn't know the rest of the world was a Database.

Are you honestly unable to follow along. Intranet app. Who cares about
the rest of the world in that context?
Is there a dropdown in that datepicker? I don't see it.

Not by default. Add {changeYear: true} when you initialize it and it
will have one. Same for month dropdown. There's a number of examples in
the right sidebar on http://jqueryui.com/demos/datepicker/
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.

You've gone from "Not keyboard accessible! The calendar should be
navigable by the keyboard keys." to not liking the shortcut keys they
use. That's a step up.

I'd tend to agree the key bindings are not intuitive. The stated plan is
full WAI-ARIA support by version 2.0, hopefully be the end of the year.
At that stage keyboard nav will presumably follow the reasonably
standard http://www.w3.org/TR/wai-aria-practices/#datepicker

ARIA isn't high on my own list of concerns, but is another example of
why I don't view jQuery UI as ready for primetime yet, instead using it
sparingly for in-house stuff.
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.

You've gone from showing your own calendar 'widget' to complaining that
calendars widgets are pointless?

Sometimes they're not needed, sometime they provide quite a bit of
utility. And I have no need to anticipate "everyone" -- just the 25 or
so people using my intranet app.
Hopefully the server side programmers aren't dumb enough that they want
mm/dd/yy and can actually handle a standard ISO-8601 format.

You're suggesting I force data entry to use yyyy-mm-dd, despite the fact
that's not a convention they're used to using and never see on the data
they're entering, because I don't want to accommodate on the back-end?
Makes no sense.

function ISODate($date) {return date("Y-m-d",strtotime($date));}

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

Yeah, I'd prefer if they gave me the option to pass the container an ID
if I specified one -- easier and more reliable to write CSS rules for
non-standard usage.
#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.

The container does not have an ID? What is it appended to? Can you use
descendant selector?

Container is an absolute positioned ul with a class .ui-autocomplete. On
their demo looks like appended to body. On my app appears appended after
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.

Something along those lines is what I'm hoping they do, however my
particular preferences may not match the goals of a general purpose set
of widgets. If the end result works for my needs, great. If not, isn't
hard to find an alternative or roll my own.
 
Ad

Advertisements

D

David Mark

S.T. said:
S.T. said:
On 3/17/2010 11:31 AM, David Mark wrote:
S.T. wrote:

$('#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.

http://en.wikipedia.org/wiki/File:Date.png

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

[...]

I thought David was complaining I was imagining the US is very mm/dd/yy
centric. I often lose track of what he's talking about though.

You were definitely imagining that. What I was talking about is that it
is virtually exclusive to the US and you are clearly dealing with some
ambiguities in date entry (e.g. mm/dd vs. dd/mm), so it would be better
to use another form.
It would be stupid to use yyyy-mm-dd formatting in this app.

Not at all. Read what you wrote. I sure don't think anyone uses
yyyy-dd-mm, so you would eliminate your ambiguity problems if you switched.
Are you honestly unable to follow along.

Didn't you just say that you were having troubles along those lines?
Intranet app. Who cares about
the rest of the world in that context?

You should as it isn't about what the rest of the world does.
Not by default. Add {changeYear: true} when you initialize it and it
will have one. Same for month dropdown. There's a number of examples in
the right sidebar on http://jqueryui.com/demos/datepicker/

Why anyone would buy into a date picker from that bunch is beyond me.
You've gone from "Not keyboard accessible! The calendar should be
navigable by the keyboard keys." to not liking the shortcut keys they
use. That's a step up.

A baby step. :)
I'd tend to agree the key bindings are not intuitive. The stated plan is
full WAI-ARIA support by version 2.0, hopefully be the end of the year.

Why wait? And that is beside the point anyway. Whether the element
receiving the keys are text inputs (best bet) or not is irrelevant. And
that stuff is the wave of the past for date pickers. By the time they
get their act together, HTML5 (which has a date input) will be prevalent
in the handful of browsers they care about anyway. ;)
At that stage keyboard nav will presumably follow the reasonably
standard http://www.w3.org/TR/wai-aria-practices/#datepicker

And it will be a dead issue.
ARIA isn't high on my own list of concerns, but is another example of
why I don't view jQuery UI as ready for primetime yet, instead using it
sparingly for in-house stuff.

That is a very small concern next to some very large ones (e.g. the
widgets are built on top of jQuery, jQuery is constantly shifting as
they discover and attempt to correct for past misconceptions, so
anything built on top of it is going to shake and eventually collapse).
You've gone from showing your own calendar 'widget' to complaining that
calendars widgets are pointless?

They will be soon enough.
Sometimes they're not needed, sometime they provide quite a bit of
utility. And I have no need to anticipate "everyone" -- just the 25 or
so people using my intranet app.

That makes sense.
You're suggesting I force data entry to use yyyy-mm-dd, despite the fact
that's not a convention they're used to using and never see on the data
they're entering, because I don't want to accommodate on the back-end?
Makes no sense.

I think you have misconstrued the meaning. The main point is that you
are using a widget, so what difference does it make if the end-users
aren't used to yyyy-mm-dd (i.e. they are likely clicking much of the
time, not entering characters). Even if they are not used to it and
refuse to use the widget, I think they will get the hang of it quickly
enough (and make less mistakes due to ambiguities of course).
function ISODate($date) {return date("Y-m-d",strtotime($date));}
Whatever.


No big deal.


Yeah, I'd prefer if they gave me the option to pass the container an ID
if I specified one -- easier and more reliable to write CSS rules for
non-standard usage.


Container is an absolute positioned ul with a class .ui-autocomplete.

Interesting. Normally I would put the list in a scrolling DIV.
On
their demo looks like appended to body. On my app appears appended after
the <input>. Not certain exactly how it's being injected into the DOM
and not going to worry about it until it's moved beyond beta.

Better still, forget it and you won't have such worries (you can decide
how to inject it). JFTR, the BODY would be the worst possible choice as
it would require absolute positioning, which is a needless (and often
outrageous) complication.
Something along those lines is what I'm hoping they do, however my
particular preferences may not match the goals of a general purpose set
of widgets.
Exactly!

If the end result works for my needs, great. If not, isn't
hard to find an alternative or roll my own.

Spot on with rolling your own. Don't bother sifting through more junk
with near future expiration dates.
 
S

S.T.

Well, we're wildly off topic now but I'm assuming most of the newsgroup
has already figured out whether this leg of the post interests them or
not. I'd 'OT' the subject line but really, don't see this going on longer.

I think you have misconstrued the meaning. The main point is that you
are using a widget, so what difference does it make if the end-users
aren't used to yyyy-mm-dd (i.e. they are likely clicking much of the
time, not entering characters). Even if they are not used to it and
refuse to use the widget, I think they will get the hang of it quickly
enough (and make less mistakes due to ambiguities of course).

I don't think you're getting a clear picture of what's being done. First
off, it's a HUGE amount of data being entered. Second, the data changes
somewhat often requiring revisions to already extensive lists of dates.
Eyes back and forth between printed page and monitor, tens of thousands
of times over the course of a year.

If a person has a sheet of paper as sees:

12/6/09 - 12/10/09 : $100 (around 40% of the time)
- or -
12/06/2009 - 12/10/2009: $100 (around 40% of the time)
- or -
6 Dec 2009 - 10 Dec 2009: $100 (around 10% of the time)

Asking someone to then shift focus to a monitor and enter that $100 rate
in the appropriate location when the dates are given as:

2009-12-04 2009-12-05
2009-12-06 2009-12-10
2009-12-11 2009-12-12

... is ridiculous. It's pleading for data entry errors. No one in their
right mind is going to invert the date format between the data
collection and the data entry.

The appropriate layout, given the working scenario:
http://i41.tinypic.com/9t26vc.png

The "your frickin nuts if you expect me to do this ~25,000 times" layout:
http://i42.tinypic.com/vqk6qt.png
 
D

David Mark

Jorge said:
Yes, by "3rd party plugins" :-|

I guess Dojo and the like will have to rewrite their UA sniffing that
forks for SVG, VML, Canvas, etc. What a pity for their users. :)
 
Ad

Advertisements

G

Garrett Smith

S.T. said:
Well, we're wildly off topic now but I'm assuming most of the newsgroup
has already figured out whether this leg of the post interests them or
not. I'd 'OT' the subject line but really, don't see this going on longer.
*That* is off topic top posting.
On 3/18/2010 11:28 AM, David Mark wrote:
[...]

Asking someone to then shift focus to a monitor and enter that $100 rate
in the appropriate location when the dates are given as:

2009-12-04 2009-12-05
2009-12-06 2009-12-10
2009-12-11 2009-12-12

.. is ridiculous. It's pleading for data entry errors. No one in their
right mind is going to invert the date format between the data
collection and the data entry.

It sounds like that data could be parsed by a program.

A simple regex would match a mm/dd/yy as (\d{1,2})\/(\d{1,2})\/(\d{1,4})

Then you could mix two of those with the "to" in the middle:

to:
\s+-\s+

mix:
(\d{1,2})\/(\d{1,2})\/(\d{1,4})\s+-\s+(\d{1,2})\/(\d{1,2})\/(\d{1,4})

The Datepicker widget with the perverse keyboard a11y seems to be
totally irrelevant to copy paste.
The appropriate layout, given the working scenario:
http://i41.tinypic.com/9t26vc.png

The "your frickin nuts if you expect me to do this ~25,000 times" layout:
http://i42.tinypic.com/vqk6qt.png

So you want date parse routine that accepts mm/dd/yy or mm/dd/yyyy and
converts that to a standard format?
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
The difference between IE6/7/8 and 9 is in these fields:

!!new Date().toISOString // was false, now true
toISOString() (see source) // was false, now 12345-06-07T11:22:33.000Z
(0.007).toFixed(2) // was 0, now 1
(0.5).toFixed(0) // was 0, now 1

So besides ES5 `Date.prototype.toISOString`, we finally have compliant
`Number.prototype.toFixed`.

Provided that no other errors in it are unfixed, and no new ones added.
Preview doesn't support canvas, although IIRC, IE team claims that work
is being done in that area.

Yes; but the question was does it fail *nicely*.


Also, <URL:http://www.merlyn.demon.co.uk/js-maths.htm#Ierr> shows errors
(factor of 10) in IE8 with long integer to string.



In <URL:http://www.merlyn.demon.co.uk/js-date0.htm#TDO>, go to "Date
Object String Output Methods" - certain other questions become obvious
by the blankness of the new column. What does the yellow above
indicate?

Thanks. Pages updated.
 
Ad

Advertisements

D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
On 3/20/10 3:00 PM, Dr J R Stockton wrote:
[...]
Also,<URL:http://www.merlyn.demon.co.uk/js-maths.htm#Ierr> shows errors
(factor of 10) in IE8 with long integer to string.

Couldn't open this. Page was blank.

It should work; it does for me, clicking the link in the previous
article. It will want CSS & JS files, not big, and executes code while
loading, but only briefly. Page last changed about Feb 21. Do others
see it?


All the same as IE8, except `toISOString` (which is missing in IE8 but
present in IE9).

As expected, but it is better not to guess. Updated. Thanks.
 

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