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: David Mark on 17 Mar 2010 09:30 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 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. > > .@abozhilov Unfortunately, there's still "unknown" type which throws > error on [[Get]] `document.createElement('p').offsetParent+''`; // boom :) > > .@abozhilov DontEnum bug seems to be fixed. Yay! `for (var p in { > toString: 1 }) console.log(p); // logs "toString"` #IE9 Good. > > .@abozhilov 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.
From: Richard Cornford on 17 Mar 2010 10:08 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. > 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.
From: Matt Kruse on 17 Mar 2010 12:36 On Mar 16, 10:09 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > 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
From: David Mark on 17 Mar 2010 12:44 Matt Kruse wrote: > On Mar 16, 10:09 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> 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. > Whatever. I wish you wouldn't barge in here talking BS. How about that?
From: S.T. on 17 Mar 2010 16:46
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 > 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 "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. >>> 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. >> >> 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. 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. 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? |