Microsoft and IE9 New Features
in [JavaScript]
|
Prev: Microsoft expanding it use of jQuery & involvement with jQuery
Next: *PITIFUL* FAQ Entry - How can I access the client-side filesystem?(2010-03-15)
From: kangax on 17 Mar 2010 17:46 On 3/17/10 10:08 AM, Richard Cornford wrote: > On Mar 17, 1:22 pm, kangax wrote: >> 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. > >> 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> 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. > > 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)? Doesn't look like it. See below (input is marked with ">"). > Does the DOM have the namespace qualified DOM > methods (e.g. - createElementNS -), > document.createElementNS; function createElementNS() { [native code] } (ditto for `getElementsByTagNameNS` and `createAttributeNS`) > document.getElementsByTagNameNS( 'http://www.w3.org/2000/svg', 'polygon')[0]; [object SVGPolygonElement] > document.getElementsByTagName('polygon')[0]; undefined > 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" > document.createElementNS( 'http://www.w3.org/2000/svg', 'circle').tagName; "circle" > 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)? What would be a good test for this? > 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. 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). > > How does the Rendering cope with mixed namespace mark-up? 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. -- kangax
From: Jorge on 17 Mar 2010 18:01 On Mar 16, 11:17 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> 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/ No <canvas> yet ??? :-| -- Jorge.
From: Garrett Smith on 18 Mar 2010 00:09 S.T. wrote: > 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? [...] >>> >>> 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? > > 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. >>>> 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}); >> >> 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. > Is there a dropdown in that datepicker? I don't see it. >>> >>> 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 That one is correct. >>> * ctrl+end - close and erase the date >>> * escape - close the datepicker without selection 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. >> 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. > >>> 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? > > 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 18 Mar 2010 06:47 S.T. wrote: > 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 What is that supposed to prove? > >> 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? > > 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. > >>>> 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}); >> >> 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. I was referring to your example (code). > >>> >>> 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 >> >> 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. 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. :) > >>> 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? > > 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. > > http://ui-patterns.com/pattern/Autocomplete 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? ;)
From: David Mark on 18 Mar 2010 07:04
Garrett Smith wrote: > S.T. wrote: >> 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? > > [...] > >>>> >>>> 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? >> >> 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. > >> "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. > >>>>> 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}); >>> >>> 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. >> > > Is there a dropdown in that datepicker? I don't see it. > >>>> >>>> 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 > That one is correct. > > >>>> * ctrl+end - close and erase the date >>>> * escape - close the datepicker without selection > > 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. > >>> 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. >> >>>> 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? >> >> 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; > } 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). |