Probably some combination of "this is what most browsers do" and wanting to have "http://foo.com:80" and "http://foo.com" have the same underlying representation.
I don't think he's arguing that "http://example.com:80" and "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|"").
I think they just wanted to consistently handle the port, rather than exclude it when it is the default. I can understand wanting to be consistent, but their implementation even goes against the W3 specs: http://www.w3.org/TR/url/#url-decomposition-idl-attributes
General note to OP and others relying on MDN - if you do spot errors, please remember that it is a Wiki. You can just hit the "edit" button and fix it yourself .. and you'll be helping a ton of others along the way.
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?
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.
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.
That and all the other IT worlds (rightful) hate towards IE, makes me think, how does that feel if you're the one of those IE developers... poor guys/girls. Still its staggering how much wrong IE can be in every corner there is some mistake.
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):
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!
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?
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.
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.
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?
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 ;-)
You actually went into the dev tools? You could have just used Reader in Safari and been done with it. Another option is to just view source and read that. (Only kidding.. I found it a bit distracting as well.)
On the android browser, it creates a square that floats over the text and scrolls opposite to the page. Intrusive, useless, and made me skip reading the article.
What does it look like for you? It looks neat to me, but it doesn't seem to expand wide enough to fit all the text in my browser (Luakit on Arch Linux.)
Firefox 24.0 on Ubuntu amd64 (raring). Looks like same problem as described in parent. Have a look at http://imgur.com/SfdVQ7k -- screenshot taken with a brand new profile.
Looks perfect for me on Chrome on Windows, but I think I'd keep it fully expanded for a second or two or start out fully collapsed. Opening the tab to see something collapsing the instant it loads is a little ugly. Otherwise it's super-cool. A bit mystery-meat-ish, but your personal page is a good space for that kind of form-over-function.
Just as a note to OP, the animations are stacking on top of each other, so if you hover in/hover out several times very quickly, the animation keeps going back and forth for quite some time.
It's not likely to pop up, but I noticed it right off the bat.
jQuery queues animations by default. In my opinion, this is a very silly default for its normal purpose, for such reasons as these. Add `queue: false` to the options in the $.animate call to turn it off.
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.
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."
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!