View Full Version : Final straw with IE

08-08-2008, 01:11 AM
I use javascript to build a few html elements and then apply styles to them using javascript dom object attributes such as id.style.backgroundColor etc...

Using FF3;
The code is the way you would expect! This validates under HTML 4.01 STRICT!

Using IE7;
The code is changed in every way. My code has gone into uppercase and lowercase which now looks messy and simple things like id="mydiv" is now id=mydiv
The thing thats bugging me the most is that validation FAILS!!! I know it doesnt but M$ IE has ruined the code!

Why, and is it possible to turn M$IE into something that just reads the code I wrote rather than trying to re-write the whole thing again in M$ Knackery?



08-08-2008, 02:56 AM
I'm not sure what you are talking about. The MSIE HTML parser doesn't see the code as valid or invalid, it simply renders the page as best it can according the code written and the DOCTYPE supplied. If you do a code view with the developer extension or have the browser write out the innerHTML of the generated source of the body, you will see how IE sees the code. Outside of a few possible quirks in rendering, and/or in interpreting javascript, as long as you have written valid code, this is nothing to worry about.


<div id=whatever>

(with no quoting of the id attribute) is valid code. Uppercase tag names are valid as well, except in XHTML, which IE doesn't support.

08-08-2008, 04:09 AM
I transformed my doc type to comply with HTML 4.01 Strict and I use javascript to build some html code with js embedded. FF builds it the way I specify but IE changes everything! I write this generated code to a db and when I output into my search results the validation always fails when it has been created with IE7. FF3 always produces my code correctly with the function I have wrote.

for example if I specify that a div element's innerHTML is to recieve;

<div id="test"></div>

then why should I accept that IE will output
<div id=test></div>

Its a little more complicated than the example above*

This messes up everything Ive been working towards and I have no choice but to exclude IE from my supported browsers list. I read up on extensive reports about IE and I seem to be making the right move by doing this as IE hasnt got much of a fan club. Even the US-CERT are saying that the software has security holes and I think most of googles links point to documents saying how bad IE is.

Even style changes. Javascript reports colours through the DOM as RGB but IE resets these as hex values. When I come to re-edit these values my page is going to fail! If I went through one of your pages renaming functions you wouldnt be very happy, its the same thing, if IE wants to take over and do all the work thats fine but all its doing is modifying my existing scripts.

All I want to do is to turn off the option "M$_hacking=false" or "Leave_my_Code_alone=true". There must be a hybrid mode or something I can set.


08-08-2008, 04:38 AM
After I responded to your post the first time I gave it some more thought, but wanted to wait until you responded so that I could get a clearer idea of what you were talking about.

I've always viewed it as a challenge to get code (HTML and javascript) to work as expected/desired in various browsers. And failing that, to at least get it to degrade well in those browsers where I can't figure out how to make it do what I want it to.

There are a great many other browsers around other than IE and FF. And even of just those two, there have been many versions, and will likely be many more versions.

There hasn't been a browser made yet that follows standards 100%, at least not any I'm aware of, none that are in wide use today, certainly.

So, for the time being, you are pretty much going to have to write your code to deal with browser quirks.

The choice not to support IE is perhaps personally satisfying, but I believe misguided. Its developers continue to bring each version closer to standards, as do most other browser developers. I think it has gotten a bad rap in part because everyone loves to hate whoever is on top. For a very long time this has been IE. Part of the problem though is that IE does deserve some of the bad reputation it has, so it is hard to separate fact from fiction there. As an example, it's bad track record on security is exaggerated, but not entirely false, and there are mitigating factors.

I would not personally recommend using it for anything other than testing and for trusted sites that might require or benefit from certain unique features it has.

Excluding it from the development of your site or sites you are doing for others though is like saying you don't want a huge segment of the browsing public to even bother with your site.

Doing so as a sort of protest in the hopes of ending its use by all but a few die hard aficionados, though it may feel good - I don't really think that approach will work. Eventually, as has already been happening, it will be so much better than it is now, that excluding it now will likely later seem shortsighted at best.

08-08-2008, 05:04 AM
Thanks for the advice and the response.

I agree with you on all of what you have said, thats why I continued to test across FF2,FF3,IE6,IE7,IE8,Opera,Avant,Flock and Safari. Unfortunatly the most stable (in my opinion) was IE6 but failed to support features I needed in CSS and PNG transparency. Although, the time has come to assume that IE7 is the main stream at least from the M$ side of things and I was once a developer who created sites for IE only and called every other browser who didnt follow M$. Then, I found that W3C was so important (and Im not referring to any myths on SEO wonders that people seem to get hooked on) Im refering to the simple idea of a standard. Netscape was just as incorrect to go off doing there own thing as M$ are (even know NS set wonderfull standards) W3C is in a position to take both sides into consideration and set what should be based on logic and accessibility.

I realise that there are no browsers out there that have the capability to cover the W3C spec 100% and Ive read different articles to say Mozilla FF3 is the closest and also Ive read that Opera is. Ive never read "IE" and "W3C" in the same sentence except when there a "not" in the middle :p.

The problem I have is that Ive come along way through and I was happy with the code, W3C validator has given me a pass (I know the validator isnt 100% accurate but its not far off) but this problem Im experiencing is a problem with the browser its self and not how it handles its code. Changing things is always going to upset code but I cant compensate for it as javascript is the thing that creates it I would need to do this server side. The problem is that the code can be 5 lines or 5000 lines long with various styles and attributes. Its kind of like a WYSIWYG editor and theres now way to condition it for IE without spending another 6 months re-writting a custom IE7 version. I dont want to have to block access to the site with IE but I cant see a way around.

Even the youtube chromeless player code has been converted from 3 params to 24 params!! One of these has renamed the movie player to "Movie" which now doesnt work correctly. Anyone viewing anything created from IE, the page falls apart and fails W3C on various problems. The same process on FF or Opera creates the page perfectly and passes validation.

I dont know what to do :(


08-08-2008, 05:38 AM
I certainly can sympathise. Quite some time back now I made up this script where you could paste your HTML code into a textarea and it would transform it into a script to create that markup using DOM 2 methods. Needless to say, IE (it was version 6 at the time) required the most code branching, and still missed out on some things if the pasted code was very complex, like if it had scripts in it.

I really don't know what to advise you, really would hesitate to in a way. A general rule of thumb in accessible development though is to have your site be accessible even to browsers without javascript enabled. If you are following that recommendation, you could just have IE skip the parts it can't do properly.

08-08-2008, 07:23 PM
wait will using hex values be a problem in the soon. they worked in FF the last time I checked. will hex values be droped soon?

08-08-2008, 07:31 PM
wait will using hex values be a problem in the soon. they worked in FF the last time I checked. will hex values be droped soon?

No riptide, HEX will always work as an assignment to the javascript DOM properties. The problem I had was that reading the DOM properties converts it to RGB values and you then have to convert them back to HEX.

The reason I read them like this is so that I can highlight a previous colour selection of text.

Im not sure if all browsers read like this under js dom but FF3 certainly did. (It may have even been FF2, I cant remember if I hit this problem with FF2 or upgraded to FF3 anyway its compatible with both)

Kind regards

08-08-2008, 11:54 PM
That's right. If you want to read the color value in all browsers without having to store a reference to what you previously set them as, and without relying upon a base style setting in the stylesheet, you must apprehend what nomenclature the current browser is using to define the color and work from that. Generally once you get what the browser's nomenclature is, you can convert it to whichever one you prefer to use in your code. The nice part is that all modern browsers will accept assignment back for the new color in any standard notation you decide to throw at it.