4 ms·

No, don't, unless you want bad things to happen when a whole bunch of corner cases start sprouting up. I did this for a while and ultimately gave up after seei

No, don't, unless you want bad things to happen when a whole bunch of corner cases start sprouting up. I did this for a while and ultimately gave up after seeing the error rate spike on my server. There are lots of people out there using stuff which just does not get the protocol-independent // scheme. I went back to doing either the whole thing (http[s]://host/path) or a relative thing (/path) but nothing in-between. http://rachelbythebay.com/w/2012/09/15/rel/ http://rachelbythebay.com/w/2012/09/15/rel/

StavrosK 14y ago
I disagree with your conclusion. The fewer sites this works with, the quicker developers will fix it. Supporting the wrong way is not the right thing to do.
- carbocation 14y ago
  Your two viewpoints are reconcilable, I think. From the standpoint of the individual developer, you handle edge cases like this so you don't break your clients' experience. From the standpoint of the ecosystem, broken tools are bad, and they cause individual developers to have to handle more edge cases. If one individual developer doesn't handle these edge cases, their clients will just think they are bad. If all of the individual developers decided not to handle these edge cases in a coordinated fashion, sure, they could trigger a change. But I don't think that's how it happens in the real world. To look back on the days of IE6/IE7, most developers didn't just stop supporting these browsers and hope that their clients would stop using them; they supported the browsers until larger forces caused their clients to shift to newer browsers. Getting back to my original point, I think it's possible for each of you to have the viewpoints that you have, but also for rachelbythebay to say, "Sure, if I could coordinate with all other devs to stop handling broken edge cases at the same time, I would do that," and for you to say, "Sure, I can see how you would want to keep your job and handle edge cases until they are fixed upstream."
  - StavrosK 14y ago
    I half-agree with rachelbythebay's position, but, in my experience, users will definitely say "hey, this site doesn't work with your service", the developer investigates and fixes it. It'd also probably be worth it to just email the devs of the service, it'd probably get fixed a significant proportion of the time.
- deleted 14y ago
  [deleted]
- _pmf_ 14y ago
  > The fewer sites this works with, the quicker developers will fix it. That turned out really well in the past.
  - StavrosK 14y ago
    Yeah, online services, desktop software, it's equally hard to upgrade both.
hkolk 14y ago
We are running one of the largest sites in the Netherlands with protocol-independend css/js/img: http://www.marktplaats.nl/ http://www.marktplaats.nl/ Haven't heard real complaints from the users about broken things. Probably anecdotal but it saves quite some complexity
- vanderZwan 14y ago
  And in your spare time you are one of the best Dutch cartoonists around?
bct 14y ago
What kind of "stuff"?

StavrosK 14y ago

I disagree with your conclusion. The fewer sites this works with, the quicker developers will fix it. Supporting the wrong way is not the right thing to do.

carbocation 14y ago
Your two viewpoints are reconcilable, I think. From the standpoint of the individual developer, you handle edge cases like this so you don't break your clients' experience. From the standpoint of the ecosystem, broken tools are bad, and they cause individual developers to have to handle more edge cases. If one individual developer doesn't handle these edge cases, their clients will just think they are bad. If all of the individual developers decided not to handle these edge cases in a coordinated fashion, sure, they could trigger a change. But I don't think that's how it happens in the real world. To look back on the days of IE6/IE7, most developers didn't just stop supporting these browsers and hope that their clients would stop using them; they supported the browsers until larger forces caused their clients to shift to newer browsers. Getting back to my original point, I think it's possible for each of you to have the viewpoints that you have, but also for rachelbythebay to say, "Sure, if I could coordinate with all other devs to stop handling broken edge cases at the same time, I would do that," and for you to say, "Sure, I can see how you would want to keep your job and handle edge cases until they are fixed upstream."
- StavrosK 14y ago
  I half-agree with rachelbythebay's position, but, in my experience, users will definitely say "hey, this site doesn't work with your service", the developer investigates and fixes it. It'd also probably be worth it to just email the devs of the service, it'd probably get fixed a significant proportion of the time.
deleted 14y ago
[deleted]
_pmf_ 14y ago
> The fewer sites this works with, the quicker developers will fix it. That turned out really well in the past.
- StavrosK 14y ago
  Yeah, online services, desktop software, it's equally hard to upgrade both.

hkolk 14y ago

We are running one of the largest sites in the Netherlands with protocol-independend css/js/img: http://www.marktplaats.nl/ http://www.marktplaats.nl/ Haven't heard real complaints from the users about broken things. Probably anecdotal but it saves quite some complexity

vanderZwan 14y ago
And in your spare time you are one of the best Dutch cartoonists around?

bct 14y ago

What kind of "stuff"?