IE seems right, Chrome seems wrong | Hacker News Reader

IE seems right, Chrome seems wrong

jessepollak.me

166 pointsjessepollak63 comments

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.

So what is port in this case? That's defined at 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. ;)

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?

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

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.

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

But isn't Chrome still doing the wrong thing when given https://foo.com:443?

No, because 443 is the default port for https, so it is reset to empty string.

I don't see anywhere in the spec where is says that's okay to do.

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

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

Second link in bzbarsky's post?

That sounds, bizarrely, like the correct behavior when the default port is used would be to have a trailing ":", i.e. "clef.io:"

I'm not so sure... I assume you're referring to this line:

    Return host, serialized, ":", and port concatenated.

...except if the port is an empty string, the process will terminate one step sooner:

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

So there would be no trailing colon, in that case.

Oh, I see now. You are correct.

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.

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

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

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.

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.

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.

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/

awesome! glad I could help.

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.

But it implements 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.

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

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

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 was, in fact, the bug in the code that brought this to their attention.

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

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

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

it's brand new, so may be a little buggy. screenshot?

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.

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.

Same problem here with Firefox 27 (Nightly).

Thanks for the screenshot, I'll fix that ASAP.

Luakit must be wrong. You should probably switch to Internet Explorer. :S

Interesting, I didn't even realize it was there until I saw this posting.

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.

that's wrong, sorry! obviously, something about my media queries is off, will fix ASAP.

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.

Was going to say the same thing. I found it pretty distracting. It looks great, but at a detriment to usability.

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

Some of us aren't using Safari. Or a Mac. I know, it's a crazy world out there ;-)

(but yes, I have a plugin for that, but the rest of his site is great and readable, it's just that one thing)

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 ;-)

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

I thought it looked great. Then I noticed it was following me around. Easy solution: just make it immobile like an ordinary logo.

personally, I think it's distracting and annoying no matter how subtle. It's a beatiful effect though.

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.

yeah, it's only a couple weeks old, so I'm working out the kinks. thanks for the heads up!

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.

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

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.

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

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.

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!

seems

Reply on news.ycombinator.com