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: S.T. on 16 Mar 2010 20:56 On 3/16/2010 5:02 PM, David Mark wrote: > 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.
From: Doug Gunnoe on 17 Mar 2010 00:25 On Mar 16, 6:02 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > It can't not be buggy. That's the best double negative I've seen in a long time.
From: Garrett Smith on 17 Mar 2010 02:46 S.T. wrote: > On 3/16/2010 5:02 PM, David Mark wrote: > >> 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) 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. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 17 Mar 2010 05:37 Doug Gunnoe wrote: > On Mar 16, 6:02 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >> It can't not be buggy. > > 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.
From: kangax on 17 Mar 2010 09:22
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. 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. In #IE9 host objects still (!) don't inherit from `Object`/`Function` (`window.alert instanceof Function === false`). Not good. On the bright side, Array#slice can now convert NodeLists to array! [].slice.call(document.getElementsByTagName('*')) instanceof Array==true In #IE9, attributes and properties are still (!) mapped to each other. Some things never change? :) Same bugs in #IE9: gEBTN returns comment nodes, innerHTML is buggy with select/table elements, gEBN mixes names and ids. Named function expressions still leak identifier to enclosing scope in #IE9. IE team promises to fix things: http://bit.ly/aCCYWY #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 :) #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 OMG. #IE9 actually _renders_ XHTML served as... "application/xhtml+xml" I can not believe this... #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" ..@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 ..@abozhilov Nope, no __proto__, __parent__, __defineGetter__, or `watch` in #IE9 Whitespace character class still doesn't match NO-BREAK SPACE `/\s/.test('\u00A0') === false` #IE9 Not only is there no `Array.prototype.*` extras (forEach, map, reduce), but even basic JS1.6 `indexOf` is missing. Sad. #IE9 Event object passed to event handler (added with `addEventListener`) is NOT an `instanceof Event`. #IE9 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.. HTH -- kangax |