The spec on this is at 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. 

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

So there are a few steps here. First

  parser.href = url;

  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.

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

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

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

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.

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/

- http://medialize.github.io/URI.js/

[1] http://stackoverflow.com/questions/956233/javascript-pathnam...

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...

I also created a JSFiddle to test here:

http://jsfiddle.net/nchaves/vMrjs/2/

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... writes:

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

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

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?

undefined

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

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') {

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...

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

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.

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-...

Just another way IE is a monster ;)

I believe Microsoft isn't following the same spec that every other browser is using.

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

undefined

seems