![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link.png){kind=icon}
Having fun with IE - part 4: invalid argument
I thought I'd revive this series again after finding yet another one of those incomprehensible 'features' of IE, version 8 this time 
Short, sweet & simple:
HTML:
And for those of you who are visiting my blog using IE8 (why?), here's the link in action: Click me! The Sweetness!
Sure it's not a valid URL, but why throw an error like that? It doesn't make any sense, but then again, what does? IE will just always be IE I'm afraid. Well, at least it gave me something to rantblog about
This was the bug report that triggered this discovery: [Forum/Bug] JS Error IE8 (dutch).
Here are the previous posts in the 'Having fun with IE' series, from the time I just started blogging:
Having fun with IE - part 3: doctype switching
Having fun with IE - part 2: CSS inheritance
Having fun with IE - part 1: getAttribute()
At least MS fixed some of that
Short, sweet & simple:
HTML:
1 | <a href="http://about:blank"
|
And for those of you who are visiting my blog using IE8 (why?), here's the link in action: Click me! The Sweetness!
Sure it's not a valid URL, but why throw an error like that? It doesn't make any sense, but then again, what does? IE will just always be IE I'm afraid. Well, at least it gave me something to rantblog about
This was the bug report that triggered this discovery: [Forum/Bug] JS Error IE8 (dutch).
Here are the previous posts in the 'Having fun with IE' series, from the time I just started blogging:
Having fun with IE - part 3: doctype switching
Having fun with IE - part 2: CSS inheritance
Having fun with IE - part 1: getAttribute()
At least MS fixed some of that
 04-11
|
Inline validatie met een Ajax sausje |
 06-'09
|
IPv6 validation (and caveats) |
Comments
By
RedHat,
Thursday 20 August 2009 14:22
I got a price
By
Deathscythehell,
Thursday 20 August 2009 14:22
Visiting in IE8 here 
@ work so yeah...You link does absolutely nothing for me whatsoever. So no error being thrown around like madness in any case.
@ work so yeah...You link does absolutely nothing for me whatsoever. So no error being thrown around like madness in any case.
By
Joop_,
Thursday 20 August 2009 14:28
splitting hairs ...
Also getting an error in Firefox (Mac).
By
Arfman,
Thursday 20 August 2009 14:40
IE8 also seriosuly fucks up remote management tools like HP iLO ... screw IE8.
By
himlims_,
Thursday 20 August 2009 14:55
opera vind jouw script wel liev
By
LuCarD,
Thursday 20 August 2009 14:57
It also displays the error in IE7
( version 7.0.6001.18000 )
( version 7.0.6001.18000 )
By
Mike-RaWare,
Thursday 20 August 2009 15:11
Mozilla hates your script too!
The messagebox says "This link points to: http://about/" instead the expected "This link points to about:blank".
The messagebox says "This link points to: http://about/" instead the expected "This link points to about:blank".
By
Kosty,
Thursday 20 August 2009 15:23
@Mike : Afaik that is how it is supposed to be. Since you use the http protocol, when you use ":" in the url that part stands for the port. But since the domain has no extention, an error is triggered.
By
LuCarD,
Thursday 20 August 2009 15:24
code:
1
| <a href="http://about:blank" onclick=" alert($(this).get('href'))" >Moooo</a> |
In combinatie met MooTools werkt dit wel...
code:
1
| <a href="http://about:blank" onclick=" alert(this.getAttribute('href', 2))" >Moooo</a> |
Should also work.
elementObject.getAttribute("attributeName", flag);
Where "attributeName" is the name of the attribute whose attribute we have to retrieve and flag is the value which customizes the functionality of this getAttribute() method. The flag value may be 0, 1 or 2 and it is optional.
Flag Value Description
0 It is the default value and performs the non case sensitive search
1 It performs the case sensitive property search
2 It returns the property value as it is set in the script or html code
[Comment edited on Thursday 20 August 2009 15:40]
Volgens mij is "node".href niet echt een property uit de DOM specificatie. Dat het raar doet hoef je dus niet over te zeuren. Zolang this.getAttribute (wel DOM spec) het maar goed doet!
By
crisp,
Thursday 20 August 2009 16:14
LuCarD, getAttribute() werkt inderdaad, maar er zit wel een verschil tussen de href property uit de DOM en de oorspronkelijke attribuut waarde 
Tom: href als property (en dus accessible als HTMLAnchorElement.href) is wel degelijk gedefinieerd in de DOM specificatie. HTML5 definieerd precies wat deze terug zou moeten geven:
Tom: href als property (en dus accessible als HTMLAnchorElement.href) is wel degelijk gedefinieerd in de DOM specificatie. HTML5 definieerd precies wat deze terug zou moeten geven:
maw: het opvragen van een href property geeft je altijd een absoluut URL itt getAttribute() dat gewoon de oorspronkelijke waarde geeft (en dus ook een ongeldig URL kan zijn)If a reflecting DOM attribute is a DOMString attribute whose content attribute is defined to contain one or more URLs, then on getting, the DOM attribute must split the content attribute on spaces and return the concatenation of resolving each token URL to an absolute URL relative to the element, with a single U+0020 SPACE character between each URL, ignoring any tokens that did not resolve successfully. If the content attribute is absent, the DOM attribute must return the default value, if the content attribute has one, or else the empty string. On setting, the DOM attribute must set the content attribute to the specified literal value.
[Comment edited on Thursday 20 August 2009 16:30]
By
Jaap3,
Thursday 20 August 2009 18:45
Wow Tom, crisp uit maken voor een zeur op basis van een verkeerde aanname. Een klein beetje research en ja had jezelf niet zo voor schut hoeven te zetten. Echte tweakers.net/GoT mentaliteit hier :-P
Keep it up crisp, dit blog is het enige wat met tweakers.net te maken heeft dat ik na al die jaren nog volg.
Keep it up crisp, dit blog is het enige wat met tweakers.net te maken heeft dat ik na al die jaren nog volg.
Lol ok dat zal me leren de xml dom spec te nemen 
excuses maar 't was veel te warm vanmiddag. Lijkt er iig op dat IE8 een of andere interpretatie probeert te doen met .href. Als ik http://about:blank typ in de titelbar krijg je trouwens "windows cannot find http://about:blank". "about:blank" daarentegen werkt wel.
excuses maar 't was veel te warm vanmiddag. Lijkt er iig op dat IE8 een of andere interpretatie probeert te doen met .href. Als ik http://about:blank typ in de titelbar krijg je trouwens "windows cannot find http://about:blank". "about:blank" daarentegen werkt wel.gelukkig zet je er een plaatje bij, anders moest ik IE8 instaleren om het te bekijken
By
crisp,
Friday 28 August 2009 15:53
Dat wil ik natuurlijk niet op mijn geweten hebbengelukkig zet je er een plaatje bij, anders moest ik IE8 instaleren om het te bekijken
By
Pixeltje,
Monday 26 October 2009 10:17
Safari's reply: http://tweakers.net/ext/f/PxmPNbTjQVML795vyItfLuPa/full.png
Perhaps some securtiy feature, offering protection against opening a blank page?
Perhaps some securtiy feature, offering protection against opening a blank page?
By
X-DraGoN,
Monday 09 November 2009 09:54
Chrome anwsers the same as Safari
[Comment edited on Monday 09 November 2009 09:55]
Well, it throw an error (both IE7 and IE8) because your coding is a 'piss poor job' that I would not accept from the junior programmers that work with me.
Allow me to explain myself :
1) you can not (unless you base your thinking on some proprietary way to handle events) be sure at 100% of wich will fire first : href or onclick. Can you find a RFC stating href will fire AFTER onclick (if fire BEFORE The return false is useless, as the href have already fire) or that it will fire BEFORE (I am not saying it's or another, but I am saying it might be close to quantic mecanic, mean both).
2) this kind of coding was just fine with IE2; but is becoming the 'old way' since at least 2002.
3) the correct way would be to replace your <a> tag by a <div> tag (without the useless href , obviously)
Allow me to explain myself :
1) you can not (unless you base your thinking on some proprietary way to handle events) be sure at 100% of wich will fire first : href or onclick. Can you find a RFC stating href will fire AFTER onclick (if fire BEFORE The return false is useless, as the href have already fire) or that it will fire BEFORE (I am not saying it's or another, but I am saying it might be close to quantic mecanic, mean both).
2) this kind of coding was just fine with IE2; but is becoming the 'old way' since at least 2002.
3) the correct way would be to replace your <a> tag by a <div> tag (without the useless href , obviously)
By
crisp,
Friday 05 March 2010 11:20
@sting1:
I think you are really missing the point of this article; this example is just a demonstration of weird browserbehaviour; I'm not saying you should use inline eventhandlers (although they can be usefull in certain situations) or use invalid URL's (in our case this was user-generated content).Well, it throw an error (both IE7 and IE8) because your coding is a 'piss poor job' that I would not accept from the junior programmers that work with me.
Sure you can; this follows logically from the DOM level 2 Events model. It wouldn't make sense if eventhandlers could cancel an elements' default action if that action would be executed first. Returning false from an inline eventhandler works consistently between browsers, so your point is based on nothing.you can not [...] be sure at 100% of wich will fire first : href or onclick.
As I said: this is just an example. Replacing an (inline, semantically correct) element with a (block-level, anonymous) DIV-element is pure nonsense. I would not accept that from my junior programmersthe correct way would be to replace your <a> tag by a <div> tag (without the useless href , obviously)
[Comment edited on Friday 05 March 2010 11:21]