IE hack magic
-
I had a rather amusing experience the other day using IE + xmlhttp requests + JSON.
I was using JSON to serailise some xml on the server into JSON objects and writing them out to the page. When JSON parses xml it prefixes variable names that were attributes in the xml with an @ symbol, presumably so on deserialisation it knows whicha variables are attributes, etc. All checked and working fine in opera and firefox but in ie i get an error from the javascript, i forget the exact error it was something like "conditional compile is not turned on" after some googling i find that this little gem is possible in ie.
If i am writing some javascript and inside a comments block add the line @cc_on @ followed by JScript it will run client side.
for example putting this inside a javascript function.
/*@cc_on @*/
/*@if (@_jscript_version >= 5)
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
}
}
@end @*/I can kind of see why they did this and it has its uses but does anyone else here smell hack, plus its really annoying because @prefixed variables are legal in javascript it would seem, at least it works in ff and opera.
-
A hack in Internet Explorer? Inconceivable!
-
[quote user="joe.edwards@imaginuity.com"]
A hack in Internet Explorer? Inconceivable!
[/quote]You keep using that word. I don't think it means what you think it means.
-
That's a little odd, although I also find it odd that Javascript variables can start with symbols (maybe thrown in there to make Perl programmers more comfortable?)
Actually, I really like conditional comments in HTML, not sure about Javascript though.
-
@Cap'n Steve said:
That's a little odd, although I also find it odd that Javascript variables can start with symbols
I'm not sure if you can use any symbol and I'm not bothering to find the ECMAscript reference right now, but this page from Mozilla Developer Center says:
A JavaScript identifier must start with a letter, underscore (_), or dollar sign ($); subsequent characters can also be digits (0-9). Because JavaScript is case sensitive, letters include the characters "A" through "Z" (uppercase) and the characters "a" through "z" (lowercase).
Starting with JavaScript 1.5, you can use ISO 8859-1 or Unicode letters such as å and ü in identifiers. You can also use the \uXXXX Unicode escape sequences listed on the Unicode Escape Sequences page as characters in identifiers.
This works in Firefox 2.0.0.7:
var $\u0009 = 'Yo!';
alert($\u0009);PS: \u0009 is a Tab character.
-
I just realized the above is equivalent to:
var $ = 'YO!';
What a disappointment!alert($ );
-
@Cap'n Steve said:
Actually, I really like conditional comments in HTML, not sure about Javascript though.
Conditional comments are pretty awful.
They are useful for adding special code for IE, when you need to apply a hack because it doesn't work like it should. It would be better if IE worked properly in the first place.
-
Conditional comments is quite possibly the best way to solve the problem of incomplete standards support - it provides you with a guaranteed way of working around a problem without relying on parsing bugs (you can't know if the parsing bug is fixed at the same time as the bug you're working around), the presence of JavaScript functions to detect a given browser (JavaScript can be disabled), or the user-agent string (which is easily tampered with).
No other browser gives you such a feature, despite having plenty of bugs themselves - regardless of which scheme you can think of, there's a way to make it think it's dealing with a different browser than is the case, and that leads to suddenly getting complaints from Opera users because the site looks horribly on their computer, since you detected it as IE due to it's built-in user-agent masking.
-
Unless a version of IE turns out to have a bug in the conditional comments parser...
What?
-
@Pidgeot said:
Conditional comments is quite possibly the best way to solve the problem of incomplete standards support - it provides you with a guaranteed way of working around a problem without relying on parsing bugs (you can't know if the parsing bug is fixed at the same time as the bug you're working around), the presence of JavaScript functions to detect a given browser (JavaScript can be disabled), or the user-agent string (which is easily tampered with).
The only reason other browsers haven't implemented conditional comments (complete with masking as IE) is sites have not, in general, used that to prevent content from being used in non-IE browsers. Which is precisely the reason that all non-IE browsers provide some mechanism to tamper with the user-agent string.
-
@Random832 said:
@Pidgeot said:
Conditional comments is quite possibly the best way to solve the problem of incomplete standards support - it provides you with a guaranteed way of working around a problem without relying on parsing bugs (you can't know if the parsing bug is fixed at the same time as the bug you're working around), the presence of JavaScript functions to detect a given browser (JavaScript can be disabled), or the user-agent string (which is easily tampered with).
The only reason other browsers haven't implemented conditional comments (complete with masking as IE) is sites have not, in general, used that to prevent content from being used in non-IE browsers. Which is precisely the reason that all non-IE browsers provide some mechanism to tamper with the user-agent string.
Doing that would pretty much defeat the entire purpose of them anyway; they're not supposed to be used for providing different content, they're meant to provide additional styling in order to ensure a uniform rendering across different browsers.
That's the very reason why I think ALL browsers should implement such a thing using the same model as IE, but obviously with a different browser identifier (for example [if lt Opera 9] or [if gte FF 2.0.5104]) - it would allow us to work around CSS bugs found in those browsers *without* having to resort to ugly and unreliable hacks. (And yes, Firefox has more than it's share of bugs.)
-
@element[0] said:
I had a rather amusing experience the other day using IE + xmlhttp requests + JSON.
I was using JSON to serailise some xml on the server into JSON objects and writing them out to the page. When JSON parses xml it prefixes variable names that were attributes in the xml with an @ symbol, presumably so on deserialisation it knows whicha variables are attributes, etc. All checked and working fine in opera and firefox but in ie i get an error from the javascript, i forget the exact error it was something like "conditional compile is not turned on" after some googling i find that this little gem is possible in ie.
Your discovery is surely interesting, but the error is still on your side. JSON is no W3C blessed format, but it still has "standard grammar". This grammar is mostly just the same as the "object notation" in javascript, but there are some points, where it deviates. And this is exactly one of those points:
[quote user="JSON Grammar"]
Pair
String : ValueString
" Chars "
[/quote]
Unlike JS, JSON requires that ALL object identifiers are wrapped in quotes. This is done to work around all the quirks JS has with identifiers and to prevent weird problems like yours.
-
@Pidgeot said:
@Random832 said:
@Pidgeot said:
Conditional comments is quite possibly the best way to solve the problem of incomplete standards support - it provides you with a guaranteed way of working around a problem without relying on parsing bugs (you can't know if the parsing bug is fixed at the same time as the bug you're working around), the presence of JavaScript functions to detect a given browser (JavaScript can be disabled), or the user-agent string (which is easily tampered with).
The only reason other browsers haven't implemented conditional comments (complete with masking as IE) is sites have not, in general, used that to prevent content from being used in non-IE browsers. Which is precisely the reason that all non-IE browsers provide some mechanism to tamper with the user-agent string.
Doing that would pretty much defeat the entire purpose of them anyway; they're not supposed to be used for providing different content, they're meant to provide additional styling in order to ensure a uniform rendering across different browsers.
Right, but that doesn't mean they can't be used for "We haven't tested in any browser other than IE, so we'll just only allow IE to use it. Oh, and, since any other method of detecting IE can be faked, we'll use these newfangled "conditional comments" to limit it to IE.
Doing that defeated the purpose of User-Agent, too, why do you think conditional comments will be any different?
The _only_ reason that the user agent string is so "easily tampered with" is because people have a reason to want to tamper with it.
-
I've never used conditional comments.
Any sort of CSS inconsistency can always be rephrased to be IE's fault, and the underscore hack and the asterix hack are quite adequate to tweak things for IE6 and IE7 respectively.
-
@Random832 said:
Doing that defeated the purpose of User-Agent, too, why do you think conditional comments will be any different?
There are several reasons:
1) If people wanted to use it for that, they'd have done so already. Conditional comments have been around since IE 5, which came out in 1999, and they've been adopted as the standard way of fixing CSS for IE ever since Firefox came out.
2) Browser vendors started UA spoofing before users did - hence the Mozilla part seen everywhere these days. They fully well know it wouldn't be a good idea to start spoofing other browsers if conditional comments were widely implemented.
3) You'll be hard pressed to find a source on conditional comments that actually considers it an even remotely good idea to do such a thing.
4) Any web developer worth anything knows that's about the worst thing you can do these days. I know there's a lot of incompetence on the field these days, but this is really basic stuff, considering how widespread Firefox and other browsers have become. Web developers who don't know or realize this also tend to not know about conditional comments, so they'll end up going after the user-agent in the end.
5) When you really, really want to do that kind of blocking, you want to do it server-side - before sending out anything to the client. Conditional comments don't allow you to do that.
-
@element[0] said:
I was using JSON to serailise some xml on the server into JSON objects...
Out of curiosity, do you have access to the server-side code that creates the XML? You could possibly just route the database result sets into a JSON object and send from there.
Just a thought.
-
@dhromed said:
...the underscore hack and the asterix hack are quite adequate to tweak things for IE6 and IE7 respectively.
I'd have to disagree. I won't say that I don't normally just slip "necessary" IE hacks into the CSS of sites, but it's more due to timelines. But it isn't a good solution. For instance, IE7 fixed a lot of the CSS parsing bugs from IE6, but didn't address some of the major rendering bugs that were the reason web devs were exploiting CSS bugs in the first place. Conditional statements at least allow you to make sure your hacks are targetting the right browser (who knows how differently IE8 will render the same hacks?), and don't rely on invalid CSS.
-
@boolean said:
@element[0] said:
I was using JSON to serailise some xml on the server into JSON objects...
Out of curiosity, do you have access to the server-side code that creates the XML? You could possibly just route the database result sets into a JSON object and send from there.
The server side code is c# using the newtonsoft JSON parser. At the moment the api objects we are using will serialise to xml so the xml is being generated by the .net xml serialiser. It ended up becoming a non issue, i was only serialising from xml because the api already serialised to xml and didn't have all the necesary [JSONIgnore] attributes above the variables that cause circular refernces and then we have to release a new version of the api etc. but we realised we needed to do an update release soon anyway so i just went through and did it. works perfeclty now in all browsers.
BTW, on a side note i've eally enjoyed working with JSON as a method of transfering objects from the server to the browser, i'd recommend checking it out if you are getting into complex javascript stuff
-
@boolean said:
@dhromed said:
...the underscore hack and the asterix hack are quite adequate to tweak things for IE6 and IE7 respectively.
I'd have to disagree. I won't say that I don't normally just slip "necessary" IE hacks into the CSS of sites, but it's more due to timelines. But it isn't a good solution. For instance, IE7 fixed a lot of the CSS parsing bugs from IE6, but didn't address some of the major rendering bugs that were the reason web devs were exploiting CSS bugs in the first place. Conditional statements at least allow you to make sure your hacks are targetting the right browser (who knows how differently IE8 will render the same hacks?), and don't rely on invalid CSS.
IE7 fixed the _parse bug, but left the *parse bug.
IE7 fixed:
- the 3px float-nonfloat offset bug.
- the list item height explosion bug
- the double-margin float bug
It respects height, and supports min-height.These have been, in my work over the past 5 years, the biggest pains in the ass in IE6. I can't remember any other at the moment. I've browsed positioniseverything a little, but I have never seen most of those bugs.
I find conditional comments a far more cumbersome solution to IE quirks than a few hacked properties here and there.
I'd even go so far as to say that if you need any more hacks, like those craptacular band pass filters, you need to learn more HTML/CSS.
