
IE seems right, Chrome seems wrong - jessepollak
http://jessepollak.me/chrome-was-wrong-ie-was-right/
======
bzbarsky
The spec on this is at [http://url.spec.whatwg.org/#dom-url-
host](http://url.spec.whatwg.org/#dom-url-host) and says:

    
    
        If url is null, return the empty string.
    
        If port is the empty string, return host, serialized.
    
        Return host, serialized, ":", and port concatenated. 
    

So what is port in this case? That's defined at
[http://url.spec.whatwg.org/#port-state](http://url.spec.whatwg.org/#port-
state) and the key step is:

    
    
      2.  If buffer is equal to url's scheme's default port,
          set buffer to the empty string. 
    

So IE is wrong and the MDN documentation is misleading. I've fixed the latter;
can't do much about IE. ;)

~~~
jessepollak
This is exactly the explanation I needed, thank you.

I wonder what the rationale behind this decision was. It seems like a pretty
easy way to mess up people like me :D. Any ideas?

~~~
bzbarsky
Probably some combination of "this is what most browsers do" and wanting to
have "[http://foo.com:80"](http://foo.com:80") and
"[http://foo.com"](http://foo.com") have the same underlying representation.

~~~
deathanatos
I don't think he's arguing that
"[http://example.com:80"](http://example.com:80") and
"[http://example.com"](http://example.com") should have different
representations: I (and I think he) agrees they should, but that the
representation should be "example.com:80", in both cases. I'm not so sure
about host, but having port sometimes be "" seems like it could catch people
off guard. For host, you now need to watch out for the cases where the port
is/isn't present. For port, when it's "".

To me, it's like the type of the variable. The variable "port" should contain
the port, not (port|"").

~~~
bzbarsky
Ah, fair. The fact that port ends up as "" if it's default is almost certainly
a "this is what most browsers do" kind of thing.

------
jgraham
So there are a few steps here. First

    
    
      parser.href = url;
    

causes the URL to be parsed. When URLs are parsed, the spec [1] says:

    
    
      2. If buffer is equal to url's scheme's default port, set buffer to the empty string.
    
      3. Set url's port to buffer.
    

Then the host is serialized. Here the spec says:

    
    
      2. If port is the empty string, return host, serialized. 
    

Since is is the empty string in the case where the port is the default port,
no port should be appended on output, even if there was one there on input
(serializing host doesn't magically append a port).

I'm not really clear why this normalise function is needed at all though?
Origin should be string comparable?

[1] [http://url.spec.whatwg.org/#port-state](http://url.spec.whatwg.org/#port-
state)

[2] [http://url.spec.whatwg.org/#dom-url-
host](http://url.spec.whatwg.org/#dom-url-host)

------
angularly
If you ever find yourself considering whether it's IE or the other browsers,
that are doing it wrong... just assume IE is wrong, and you will most likely
be right.

~~~
yeukhon
That's not always true. There are things Chrome do wrong and other browsers do
right. Browser is a complicated software. Bugs occur everywhere. I don't use
IE but I think this is too much of a hate to say. It's simply an ignorant
thing to say.

~~~
lotsofcows
I don't really see how you can call it "ignorant".

As a view it's a little mean perhaps, but one that anyone with experience of
working with multiple browsers will be sympathetic to.

------
syncerr
As a note to others using document.createElement to manipulate URLs. While it
seems like a neat tool, it is buggy in IE in other ways[1]. I would advise
using a cross-browser library (or writing your own):

\- [https://code.google.com/p/jsuri/](https://code.google.com/p/jsuri/)

\- [http://medialize.github.io/URI.js/](http://medialize.github.io/URI.js/)

[1] [http://stackoverflow.com/questions/956233/javascript-
pathnam...](http://stackoverflow.com/questions/956233/javascript-pathname-ie-
quirk)

------
chavesn
One of my most popular answers on Stack Overflow has been about exactly these
properties. This trick you are using is new to me and you've helped me improve
the answer so it works for any URL. Thank you!

Updated answer here:

[http://stackoverflow.com/questions/6944744/javascript-get-
po...](http://stackoverflow.com/questions/6944744/javascript-get-portion-of-
url-path/6944772#6944772)

I also created a JSFiddle to test here:

[http://jsfiddle.net/nchaves/vMrjs/2/](http://jsfiddle.net/nchaves/vMrjs/2/)

~~~
jessepollak
awesome! glad I could help.

------
thezilch
Doesn't appear it's only Chrome that gets it "wrong," as it is _only_ IE that
gets it "right."

[https://developer.mozilla.org/en-
US/docs/Web/API/HTMLAnchorE...](https://developer.mozilla.org/en-
US/docs/Web/API/HTMLAnchorElement) writes:

    
    
      URLUtils.host
      Is a DOMString representing the hostname and port
      (if it's not the default port) in the referenced URL.
    

But it implements [https://developer.mozilla.org/en-
US/docs/Web/API/URLUtils](https://developer.mozilla.org/en-
US/docs/Web/API/URLUtils) (experimental), which writes:

    
    
      URLUtils.host
      Is a DOMString containing the host, that is the hostname,
      a ':', and the port of the URL.

~~~
jessepollak
Ah, so IE must implement the experimental version while no one else does?

~~~
bzbarsky
No, the documentation just doesn't match the spec.

------
jqueryin
Correct me if I'm wrong, but couldn't your code just have easily used hostname
as opposed to host since that's what you were specifically interested in?

~~~
NoodleIncident
That was, in fact, the bug in the code that brought this to their attention.

~~~
jqueryin
That's not exactly what I'm referring to. You could assume behavior would be
similar to or equivalent to how window.location.host and
window.location.hostname behave. This is especially true when we don't care
about ports, as is the case with window.location.hostname.

[https://developer.mozilla.org/En/Window.location](https://developer.mozilla.org/En/Window.location)

------
pfraze
Unrelated to the article, very cool bit of animation on the site's header. I
like it!

~~~
SCdF
I was about to complain about it actually (in grand HN tradition). Constantly
looping animation beside articles is one of my biggest pet peeves on websites.

If this was the front page of your app or service's website, then fine.

But I'm trying to _read_ here. I _cannot_ help but notice the colour change in
the corner of my eye. It is endlessly distracting. In the end I used chrome
dev tools to delete it so I could actually read the damn content.

This is a blog: I came here to read pages of text, not look at pretty lights.

~~~
jessepollak
Thanks for the feedback, this was actually something I was pretty concerned
about when I made it, but I decided to go with it anyways.

One question: do you think slowing down the color change would make a
difference? I started with a 10 second animation through 5 colors, but it's
currently a 30 second one. I might experiment with making it 1 or 2 minutes to
make it more unobtrusive. thoughts?

~~~
SCdF
So the fact that it's slow helps yeah, so I imagine slowing it down even more
would help even more. And I _totally_ get the tension between doing something
cool and removing everything that isn't strictly needed. I'd still get rid of
it completely (ie make it based on a user action instead of automatic) but
that's just me.

It is nowhere near as bad as a blog I read where the guy had a rainbow
background _explode_ out of his profile picture (that scrolled with you) every
few seconds. I couldn't even get one paragraph through that one ;-)

~~~
jessepollak
I'll mess around with it and see if I can make it better :D. thanks again for
the feedback, seriously.

------
purplerails
Quick question: why do you need to normalize the origin? Is it ever passed in
by the browser runtime un-normalized?

i..e, why couldn't you have written:

    
    
      if (e.origin !== 'https://clef.io') {

~~~
jessepollak
Yep, that code was actually legacy code that ended up causing problems. I
stripped it out :D, but only after I'd spent a few hours messing around with
this.

~~~
purplerails
Thanks. I was not normalizing, and wanted make sure it was OK.

------
JimmaDaRustla
The URL is being passed into an <a> tag href value.

Checking Mozilla documentation, it makes it quite clear. "Is a DOMString
representing the hostname and port (if it's not the default port) in the
referenced URL."

[https://developer.mozilla.org/en-
US/docs/Web/API/HTMLAnchorE...](https://developer.mozilla.org/en-
US/docs/Web/API/HTMLAnchorElement)

So IE is getting it wrong? Edit: Other post points out experimental standard
which IE may be adopting.

------
dragontamer
[http://lwn.net/Articles/551695/](http://lwn.net/Articles/551695/)

Its funny how standards evolve. Should we do things because they were declared
standard? Or should we do things because they make sense?

In the case of the original post, it was IE vs Chrome. In the case I just
brought up, it is Linux vs BSD with their implementation of POSIX.

The same story will continue to run as long as we expect different systems to
run "similarly" based on a unified standard.

------
Kerrick
I ran into this when developing with postMessage as well. This Stack Overflow
post pointed me in the right direction:
[http://stackoverflow.com/questions/13167302/did-
ie10-change-...](http://stackoverflow.com/questions/13167302/did-ie10-change-
the-definition-of-window-location-port)

------
rhizome
Did MS just purchase a new PR campaign contract? There are at least a few
stories up front today.

~~~
smoyer
I don't intend this to be trollish but ...

I don't think you want users who; a) only use IE or b) believe in IE's
infallability. Now that IE is not the dominant browser, we want IE to "work
towards the specification". I'm really happy that IE9 and IE10 are so much
more compatible than they were, but let's not go backwards!

------
dancecodes
seems

