We don't support Internet Explorer, and we're calling that a feature • Hacker News Board

Re: We don't support Internet Explorer, and we're calling that a feature

#131

Post by mixonic » Tue, May 08, 2012, 2:33 PM UTC

dclowd9901 wrote: post #30

mixonic wrote: post #10

Aw man. As a bootstrapping web business guy, I can say I've had way more problems with supporting iPads and iPhones than IE. IE costs me $0 to support, and I don't even bother (nobody asks!). Supporting hip and popular Apple browsers can run me a grand in a fast minute. Pleasing early adopters without working really well on the iPad3 is a tough sell. I think startups fighting to support I'm not crazy about getting an…

I'm confused why you believe you need hardware for testing? iOS simulator should be plenty sufficient in any standard dev environment...

I had never heard of the iOS simulator! Thanks for mentioning it, it just changed my friggin life. I'm on Snow Leopard, and there is no free upgrade to Xcode 4.0. I hunted down a torrent of 4.2 and got it installed though, and the simulator is pretty great.

My larger point is that the hassle isn't supporting X version of a browser anymore, it's supporting X version of a browser on various hardware devices. Web-dev hell isn't going to be the fault of IE anymore, it's going to be the fault of mobile platforms with differing browsers, screen-sizes, and use patterns.

Re: We don't support Internet Explorer, and we're calling that a feature

#132

Post by chris_wot » Tue, May 08, 2012, 2:46 PM UTC

maggit wrote: post #91

nardi wrote: post #77

Earlier quoted context omitted.

Completely disagree. There are two very major problems with this idea: 1. Your reputation suffers when users encounter issues while using the browser that you don't support. 2. The support cost of "letting users try anyway" is non-zero, and probably significant.

As a counterexample, let's consider Google's blocking of Opera. Google routinely blocks Opera when rolling out new stuff. I kind of get it, because of your point 1. However, they sometimes offer a "try anyway"-link and sometimes not. The times that I can not easily "try anyway" makes me dislike Google much more than the times that I "try anyway" and it ends up broken in funky ways. Bottom line; Yes, your reputation s…

Actually, your reputation does not actually suffer. You have been up-front with your customers from the very start. If you use Internet Explorer, then you should be blocked or else you will probably come against a bug that causes you to:

* potentially lose work

* have a product that you paid for that doesn't do everything you want it to do

* get frustrated when things don't work and nobody will fix them ("Why don't you care?")

Bottom line - if you don't want to support Internet Explorer, I'd say feel free to detect it and then block it. Preferrably not via a referer string, but via something you can't change like one of Internet Explorer's own bugs/incompatibilities. Like, for example, detecting document.all, or via something proprietary or broken in IE.

Re: We don't support Internet Explorer, and we're calling that a feature

#133

Post by chris_wot » Tue, May 08, 2012, 2:49 PM UTC

brudgers wrote: post #112

nardi wrote: post #77

Earlier quoted context omitted.

Completely disagree. There are two very major problems with this idea: 1. Your reputation suffers when users encounter issues while using the browser that you don't support. 2. The support cost of "letting users try anyway" is non-zero, and probably significant.

The reputation hit for blocking on the web is more or less permanent for most companies. Sure if I'm running Opera, I'll probably switch browsers to access Google. But Paydirt ain't free, it ain't Google, and I don't think I need it very badly. What I'll have to say about it probably won't be positive.

What you have to say about it probably won't be positive if you use Internet Explorer and it doesn't work. No loss to Paydirt! In fact, a gain - they don't have to spend any development or support time explaining why they don't support the Internet Explorer specific bug you encountered.

Re: We don't support Internet Explorer, and we're calling that a feature

#134

Post by chris_wot » Tue, May 08, 2012, 2:57 PM UTC

prodigal_erik wrote: post #72

My personal web projects always start with standard-conforming HTML with forms and links. They're fully interoperable contributions to the world-wide web and should be usable by every browser and robot written in the last sixteen years. I call that a feature, and I'm disappointed that so many devs set their sights lower.

That's nice. The problem is that Internet Explorer doesn't conform to these standards. What do you do in this situation?

Re: We don't support Internet Explorer, and we're calling that a feature

#135

Post by JVIDEL » Tue, May 08, 2012, 3:06 PM UTC

rimantas wrote: post #130

JVIDEL wrote: post #81

IE market share has been going down for years, but it's still more or less 70% That means that by not supporting IE you don't get 70% of the market. Early adopters come and go, but "hockey stick" growth like the one Pinterest got? that comes from the mainstream market that uses IE and doesn't knows what Firefox is, and thinks that by Chrome you mean actual chrome... But as I said IE is going down, and when it hits 50…

70%? This looks like worst case scenario to me. Here we have IE hovering about 25%: http://www.ranking.lt/en/rankings/web-browsers-groups.html

Over THERE, also Chrome is the leading browser in Latin America, but how big are those markets?

Re: We don't support Internet Explorer, and we're calling that a feature

#136

Post by squarecat » Tue, May 08, 2012, 3:11 PM UTC

We don't support Internet Explorer, and we're calling that a feature*

*An option few have, so don't be ignorant and categorically mimic our approach.

FTFY.

Re: We don't support Internet Explorer, and we're calling that a feature

#137

Post by mkmcdonald » Tue, May 08, 2012, 3:15 PM UTC

> We don't spend hours debugging obscure IE bugs

IE "bugs" are rarely obscure. Most "bugs" are actually as-intended behavior, which is documented on MSDN. Do your homework.

> Sensible browsers can do amazing things (canvas, SVG animations, CSS3, web-sockets, blazingly fast JS), and limiting usage to these lets Paydirt take full advantage of these new technologies.

As was mentioned earlier, graceful degradation renders this point moot. Web pages do not need to look and function the same in every browser.

> Originally, we feared that we'd receive a torrent of angry emails from avid IE users. In reality we've received exactly zero requests for IE support, angry or otherwise.

Ignorance begets ignorance. The lion's share of people that use IE aren't technically savvy. They're people like parents, uncles or even grandparents. Why expect them to know how to send complaints when they barely know how to use a web browser?

> We work harder when we're happier, and skipping the dirty work of IE makes us very happy.

Clearly you were never working hard to begin with. Supporting IE is much easier than Internet FUD makes it appear.

> Who knows – future versions of IE will probably be standards compliant, super fast and reasonably secure.

You mean like IE 9? A little-known fact is that IE 4-6 were the most innovative browsers of their time. `innerHTML`? IE; event listeners (`*tachEvent`)? IE; editable text content (`innerText`)? IE. Those are some pretty important additions from a platform that seems to get no respect.

Cut the browser elitism and get a clue.

Re: We don't support Internet Explorer, and we're calling that a feature

#138

Post by mkmcdonald » Tue, May 08, 2012, 3:31 PM UTC

paul9290 wrote: post #27

If you are spending a lot of time fixing html/css issues in IE6, 7 or 8 it maybe due to over using floats and clears. Especially for elements inside a container block which are spread apart from each other like elements in a header block ( or if HTML5). For the header block where you have elements spread apart from each other the better solution is to add position: relative in the div id="header" and then absolute po…

This is interesting because I use a pseudo-grid system with plenty of floats and clears. For some reason (research), it seems to look perfectly fine in IE 6+ and Quirks Mode.

Re: We don't support Internet Explorer, and we're calling that a feature

#139

Post by WiseWeasel » Tue, May 08, 2012, 3:36 PM UTC

lloeki wrote: post #89

aethr wrote: post #46

Earlier quoted context omitted.

Hover states are a big one. Also making call-to-action targets bigger for the less precise pointing device (ie, your users' fat fingers). Making sure you use Flash fall-forwards with HTML5 video/audio available for iPad / non-flash devices. iPads and iPhones also have great support for CSS3 transforms (3D included with hardware acceleration), but some of the other "common" CSS3 and HTML5 technologies do bog down on t…

> Making sure you use Flash fall-forwards with HTML5 video/audio available for iPad / non-flash devices. Can't you for the love of all that is binary do it the other way around? I hate it when sites push Flash on me on the desktop when there's a pure html version ready a user agent string away.

Desktop browser support for h.264 video via HTML5 is a crap shoot. Sometimes it works well (Safari), sometimes it works poorly (Chrome), and sometimes it doesn't work at all (Firefox and IE9-).

Re: We don't support Internet Explorer, and we're calling that a feature

#140

Post by WiseWeasel » Tue, May 08, 2012, 3:38 PM UTC

karlshea wrote: post #66

josteink wrote: post #59

Earlier quoted context omitted.

Well, adding support for Retina displays is definitely an iOS-specific thing (at least right now). Not "right now". As long as you intend to support "retina displays", it will always be an Apple-specific thing. If you want to support something as general as high-DPI devices, you know, something concrete and not an Apple marketing-term, there are certainly lots of those being made and sold as we speak. They run Androi…

Well as long as they are running WebKit and support the device pixel ratio media query, they will be supported. But I'm guessing that Android phones with high-dpi screens that support that query are still at the single digit percentage of browser statistics.

That's fine for CSS images (media queries), but what about content images?