Dave Massy's Blog

# re: VPC to run IE6 and IE7 on the same machine @ Thursday, November 30, 2006 8:22 PM

Dave, i've enjoyed watching the Ch.9 videos of the team, but I have to wonder about the transparency of the IE team.

Several times, version 8, and 9 have been mentioned, but *nowhere* is there any discussion of what will actually get *fixed* for these releases?

I apprecate the PNG work, zIndex issues with select elements, and a all the CSS selector fixes... but I'm annoyed to no end, that so much of the broken things, are still not addressed!

DOM method support is scarse at best, doesn't work on all elements, is full of quirks, and non-support of such key things as DOM Modified events, and adding/removing events using the spec.

Worse yet, as developers and testers, we *STILL* can't submit bugs, because the public bug tracking system was shut down, at the *CRITICAL* moment, it should have been running at its peak! (Launch time!, when things actually start going horribly wrong!)

Has anyone tried printing a form in IE7?  yes the page-to-fit is good, but the form controls? where's the scroll bars? radio buttons?

Can you please do one of the following: Either a serious blog post on the IE Blog, about what is *scheduled* to be fixed in IE8, *when* we are going to get a public bug tracking system back up, when we can expect fixes for all the issues with forms!!! (psst, if you think about this for a minute... anyone making any money on the Internet, needs forms... the fact that support in IE6/7 for all controls, and JS access to them is lousy, drives us developers nuts!)

Anyway, end of rant.  But please, seriously, think of the developers that have to develop for IE every day, and ask yourself... Would being more open, with our 3rd party developers be benificial to our success?...

PS Congrats to Chris Wilson's new role in Microsoft. We all hope his influence will have significant effect on the future of IE.

steve

# re: VPC to run IE6 and IE7 on the same machine @ Friday, December 01, 2006 9:48 AM

Ok, here's my list, 1 through 9 are in priority, 10-15 are random:

I'll be *very* frank here.  I am *EXPECTING* 1-9 to be fixed in IE8, since *WE* were *ALL* *EXPECTING* these to be fixed already in IE7!

1.) <button> element should submit the "value" attribute, *NOT* the .innerHTML.  This has been broken in MSIE since is was available.  Unfortunately, it is the *coolest*, most extensible form element available (cause you can stylize the content of the button, provide images, etc. e.g. I can make a button that looks like this:

[ (X) Delete ]   where the (X) is a nice image.)

As reported in the IE Feedback, supporting this element would be a piece of cake, even supporting the backward compatibility for those that implemented it using the broken MS implementation.

Just have the browser submit the content of the value attribute, if it is set. DONE, piece of cake.

2.) DOM method .getElementById(id) should *NEVER, EVER* return elements, with a *name* attribute, matching the specified id.

3.) DOM method .setAttribute() should work on *EVERY* element, and *EVERY* attribute!  This means fixing all of the following:

.setAttribute('class', '...');

.setAttribute('style', '...');

.setAttribute('for', '...');

.setAttribute('name', '...');

.setAttribute('checked', '...'); //see item 8+9 below

.setAttribute('accesskey', '...');

.setAttribute('on???', '...'); //??? = any event

.setAttribute('usemap', '...');

.setAttribute('maxlength', '...');

and

.setAttribute('type', '...'); on input fields *AFTER* they have been rendered.

4.) Form controls, with names starting with a number e.g. '456_user' are not accessible by name, *if* the number is greater than the total number of controls on the form!

5.) Form controls, added to the DOM, via DOM methods are *NOT* accessible by name via JavaScript.

6.) If Autocomplete is turned on in IE, when a user chooses a value from the drop down list, the onchange event, *STILL NEEDS TO BE FIRED* (currently it does not!)

7.) Radio buttons, do not fire the onchange event, until another element is given the focus.  This is plain wrong, as any attempt to retrieve the value returns the new, changed value, thus the event most certainly occurred.

8.) If you create a Radio or Checkbox via the DOM, assigning the checked attribute, has no effect (e.g. it doesn't work)

9.) Moving, Copying or Cloning Radio buttons or Checkboxes in the DOM, loses the checked status of the fields

10.) Textarea's show scrollbar placeholders when they are not required.  This simple rendering error, means that each textarea control needs to be created 1 row larger than necessary, just to accommodate the data.

11.) All of the following DOM & proprietary methods fail on the script element.

.appendChild(textNode);

.innerHTML = '...';

.innerText = '...';

12.) JavaScript issue: Array.splice(); does not work correctly in MSIE

13.) If you define a function on a page, then inquire via typeof(...) what type of thing it is, it will return 'function'. Unless of course, you are making the request, from a popup window, back to the opener window, in which case, it will return 'object', *WHY?!*

14.) If you are generating table content via DOM methods, you need to create a TBODY section to wrap your rows, or IE will not render it. (Odd, because only IE has this issue, and if it was plain HTML being streamed to the browser, it wouldn't care about tbody tags.  Table markup is bloated enough, why make this worse!)

15.) You can *NOT* create DOM elements/nodes in window A, and append/insert them to popup window B. (launched with handle, from window A)

steve_web

# re: VPC to run IE6 and IE7 on the same machine @ Saturday, December 02, 2006 11:25 AM

As for item 1 + 2, no it wouldn't.

Anyone using the broken button behaviour, will not be afflicted by changing it to submit the value attribute if supplied.  And if they were smart enough to add the value attribute, then they *KNEW* that this bug was in there, and they will want to get this code fixed pronto too!

Just declare that this behaviour will be fixed in IE8, and *WE* will ensure that our code is in sync.  You have to realize that most developers, have *FLAT OUT IGNORED* this element, because the behaviour in MSIE is broken!

As for #2, that was just a very bad design decision.  It sounds like another case of MS trying to "help" make things easier for developers, without realizing the consequences of straying from the spec.

More to the point, if a developer is making use, of such obviously flawed behaviour, they too should expect to see this behaviour get fixed in future releases.

If IE had a JavaScript console, you could place warning messages in the console, when a match is made on "name" instead of "id" to indicate that such behaviour is deprecated, and will no longer work after date (X).

Better yet, put up a poll, on some of these questions, and pose them to the developer community.  If you get *ANYTHING* other than an overwhelming, "YES, FIX IT ASAP!" I will be *very* surprised.

But again, it all comes down to transparency, if you announce *NOW*, that these behavior implementation errors will be fixed in IE8, then we will have Months/Years to get a fix in.  If you don't mention a word, until the Beta's are out, then you will start getting flack from any of the developers that built apps/sites against the spec, and weren't aware the change was coming.

Heck, I would even support the following, which is *TOTALLY* against spec, but may actually get something done here.

Make a conditional comment, the trigger for compliant behaviour.

If <!-- FOLLOW_SPEC=TRUE --> appears in the <head> of the page, then for any of the behaviors you are worried about breaking backward compatibility with, *WE* can at least follow the spec.

Note, I would only go for this last option, if you seriously don't think the proper behaviour can not be shipped in IE8.  But as said, it there is going to be any doubt, at least offer developers the option to follow the spec!

steve_web

# re: VPC to run IE6 and IE7 on the same machine @ Saturday, December 02, 2006 8:52 PM

If there is serious worry, from the MS camp, that developers have followed the broken implementation of the spec, without realizing that the "straying" was going to require future fixes, well, I'm not too sure how high quality these web apps are, and I'll be honest, I hope that I'm not using one of them, thats for sure! yikes! scary stuff!

Ok, then if this is how it is going to be, and we are to see no innovation, and no conforming of the spec, for fear of backward compatibility, then the *ONLY* thing to do, if for no other reason, than to save face, is to implement some sort of flag, that turns on

*****SPEC-COMPATIBILITY*****

I actually had a quick thought about this...

for #2 .getElementById('uid')

Since this is purely at the JavaScript level, add a flag, at the document level such as:

document.__MSIE_DOM_strict_getElementById

It would be a boolean, false by default, but be editable.

If a developer calls:

document.__MSIE_DOM_strict_getElementById = true;

Then from this point forward, any attempt to use .getElementById() would follow the SPEC EXACTLY, and only return elements by ID.

Bingo! Problem solved! Backward Compatibility maintained, and yet, now developers can follow the spec without fear of what curve balls IE is going to throw.

As for #1, and the button issue, I again ask that you pose this as a poll question to the community.  As it stands now, the workaround example that people have explianed for over 5 years now, still works, and arguments otherwise... really doesn't have a leg to stand on.  (Sorry, but of the hundreds and hundreds of developers I talk to, all of them see it as a perfect solution (until the behaviour is permanently fixed), and wish that such a fix is  applied ASAP.

PS yes, MS has shown 100% improvement in transparency with IE7.  The IE Blog has been crutial, in admiting mistakes, notifying the developer community of fixes, changes and new features.

I was so impressed, when the IEFeedback site opened up.  Microsoft actually taking feedback? in a public bug-tracking system? oh my gosh, this is so.. so.. so.. like all major application developers that care!... wow! (I was trully amazed!) and began to furiously submit all the bugs I knew of, waiting to watch the progess of them being aknowleged, targeted, and fixed, and to actually be part of the testing of these fixes... then as it turned out, after I submitted hundreds of bugs... it was (or at least it seemed) to be a crock.  It was a beautiful PR move, and it gave hope to the community that they were finally being heard (this was the biggest post on the IE Blog ever... the "we heard you" post)... but then it fizzled... the bugs were auto-closed without any review... obvious bugs you could repeat with your eyes closed were reported as "can't repro", and any bug actually aknowleged, was pushed as a "maybe" to an un-targeted future release.

As an active member, of many public bug tracking systems, I was shellshocked with the lack of feedback, waiting for confirmation, and the lack of expertise, on many of the tester comments. (e.g. testing a JS DOM bug, but not understanding a very simple test case)

I don't want to rant, honestly, I don't... but I put up with the Feedback site, and the lack of responses... I thought, ok, once IE7 ships, they will kick in to development mode, and start fixing stuff, but instead, Feedback was closed (PS, in terms of a PR move?... this reversed everything it ever did in the first place and more!  How incredibly helpful it was, to turn off the *ONLY* method of remotely useful bug reporting and tracking IE has ever had! I'm not sure whose idea it was, but I would have had a team meeting about this, with the PR department, before shutting down the best thing MS has ever done for developers.

And as I said originally, all we are looking for, is that you make a statement... we are planning to fix the following issue(s) in IE8.

You don't have to commit to it, but at least it gives us some hope, that before 2020, IE will be following the spec, and that developing cross-browser applications and websites will actually be an enjoyable experience, not filled with the chaos of being a guinnea pig tester for finding bugs.

Better yet, it makes us think that MS cares about correcting it's browser, and following the spec, and not straying any more.

Thanks,

steve

steve_web

# re: VPC to run IE6 and IE7 on the same machine @ Thursday, December 21, 2006 12:13 PM

Oh, one more that is really, really annoying...

#16) When adding event handlers to a page, it is often desired to handle specific key presses.

e.g. the [Escape] key, to clear something...

What is extremely annoying, is that there is a BUG, in the "keypress" event, that it WILL NOT capture KEYPRESSes on the Arrow navigation keys! (even the number pad ones)

Thus, sniffing for keys 37,38,39,40 from a keypress event, return null.

now, users experiencing this bug, can listen for the "keydown" event, but depending on what the user is planning to do, this may or may not be appropriate. (e.g. if they only want the single fire, not multiple, if the user holds the key down).

steve_web

# re: VPC to run IE6 and IE7 on the same machine @ Thursday, December 21, 2006 12:22 PM

I second Steve's remarks. Like many developers, I've been pulling my hair out for years dealing with IE6's deviations from the specs. When I'm working on something that requires CSS or Javascript of any complexity, it's not uncommon to spend 20% or more of my development time coding around IE6's bugs.

So I was really looking forward to IE7, hoping that web devs could FINALLY leave non-standard and proprietary implementations in the dustbin of history where they belong.

You guys did fix a lot of stuff, and we're grateful. But with each passing week since the release of IE7, I find more and more things that still don't work. For example, I came across this blog entry while Googling to figure out why obj.setAttribute( "onchange", "foo" ) isn't working in IE6 (see Steve's third item) - only to find that it doesn't work in IE7, either!

I've spent several hours working on this project, and this single, stupid stumbling block may force me to rewrite half my code and change the way my interface works.

MS keeps complaining that fixing many bugs would require a complete rewrite of key IE components, which would take too long. Well, however long it's going to take, _do it_.

The development team behind Firefox - a bunch of unpaid hobbyists, mind you - has managed to build a wonderful, efficient, standards-compliant browser in the span of a couple of years. Why can't Microsoft, with all its financial and technological capital, achieve the same thing? Answer: they could, of course, but for whatever bizarre reason, they won't.

Your argument that fixing the bugs would break existing apps is flawed, as well. The longer those bugs are out there, the more code that relies on those bugs will be written, so the problem is only going to get worse with time. Sooner or later, MS is gonna have to fix those bugs - and it's gonna hurt. But it'll hurt a lot less to do it NOW than it will several years from now.

I'm not one of those people who bashes Microsoft just for the hell of it, but you guys are really taking a beating on this one. The web is ready to take big strides forward, and IE's multitude of bugs present a crippling roadblock. We certainly appreciate the transparency and progress that _has_ been made, but it's small comfort when we still can't write apps that will work reliably in the world's most-used browser.

Travis Miller