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 18 Mar 2010 14:07 On 3/17/2010 9:09 PM, 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? > > [...] 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. >>>> >>>> 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? It would be stupid to use yyyy-mm-dd formatting in this app. >> "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. Are you honestly unable to follow along. Intranet app. Who cares about the rest of the world in that context? >>>>> 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. 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/ >>>> >>>> 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. 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. >>> 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. 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. > >> 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? 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 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. > 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.
From: kangax on 18 Mar 2010 14:12 On 3/18/10 1:49 PM, David Mark wrote: > kangax wrote: [...] >> 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? This is what I get when `JSON.stringify`-ing error object: {"message":"","description":"","number":-2147221248} Oh well. Not a big deal, really. We'll see what next release brings. [...] -- kangax
From: David Mark on 18 Mar 2010 14:28 S.T. wrote: > On 3/17/2010 9:09 PM, 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? >> >> [...] > > 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. > >>>>> >>>>> 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? > > 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. > >>> "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. > > 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. > >>>>>> 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. > > 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. > >>>>> >>>>> 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. > > 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). > >> 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? 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. > >> 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. 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. > >>>> 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. > > 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. >> >>> 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? > > 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. > >> 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. 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.
From: S.T. on 18 Mar 2010 16:47 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. On 3/18/2010 11:28 AM, David Mark wrote: > 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
From: kangax on 18 Mar 2010 18:23
On 3/18/10 9:17 AM, Richard Cornford wrote: > On Mar 17, 9:46 pm, kangax wrote: >> On 3/17/10 10:08 AM, Richard Cornford wrote: [...] >>> 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? > > probably starting with verifying the existence of a - write - method > on the document, `document.write` exists in IE9 (see my reply to David, which has complete output of the test). > 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. I tried writing a <circle> as a descendant of <svg> element, and got an error with an empty message (in IE9). Circle wasn't drawn either. <svg:svg xmlns:svg="http://www.w3.org/2000/svg" width="5cm" height="5cm" viewBox="0 0 500 400" version="1.1" id="svg-test"> <svg:title>A star</svg:title> <svg:polygon style="fill:red; stroke:blue; stroke-width:10" points="[...]" /> <script type="text/javascript"> // <![CDATA[ try { document.write('<svg:circle cx="100" cy="50" r="40" ' + 'stroke="green" stroke-width="10" fill="yellow" />'); } catch(err) { this.__document_write_error = err; } // ]]> </script> </svg:svg> [...] > Some other test ideas might be derived from:- > > <URL: https://developer.mozilla.org/en/Mozilla_Web_Developer_FAQ#section_11 Thank you. I'll look into it when I get a chance. -- kangax |