[VieElm]

Nothing you've said here really addresses the problem discussed and really you're looking at this from the perspective of the consumer and not the developer.

> Safari is nowhere near that bad [as IE was in the past]

Doesn't address the problems developers are having.

> I have yet to run across a page that works in Chrome that doesn't work in Safari.

Try any webpage that uses WebRTC, and there's a growing number of these. But really it's because people are doing what they did with IE6 which is here is code that works everywhere, and here is some code to make it work on Safari so the user is none the wiser. The problem is still there.

> Safary, by comparison ... <insert swoon>

This has nothing to do with the post. Great you like Safari, but the problem still exists. Where's the WebRTC support? The Audio API? Right.

As to the original article, I prefer a 4th step not mentioned, just ignore Safari. Apple has a huge iOS userbase, sure, but as the HTML5 disparity between Safari and other browsers increase it's becoming increasingly not worth considering and really do iOS users even expect the HTML5 features that don't work in Safari? They'd probably prefer a native app for that.

Desktop users can use Chrome or Firefox when a site doesn't work in desktop Safari, and if that makes them mad, good. Maybe Apple will fix their shit then.

Edit:

Regarding downvotes: I know engineers are ignoring Safari. I ignore Safari, and other people I know ignore Safari. A convenient sample sure, but as this article points out developers aren't happy. Downvotes or no. Deal with it.

[exelius]

> Nothing you've said here really addresses the problem discussed and really you're looking at this from the perspective of the consumer and not the developer.

That's entirely the point: developers and users have different needs. But the developers will follow the users to whatever browser the users feel is best. Apple's priorities are on improving battery life, page responsiveness, etc. If users value Apple's browser development model that prioritizes user-facing features over developer features, then the developers will simply follow the users. If you want to build a product around features that a major browser doesn't support, go ahead.

To use the dreaded car analogy, you don't build a car to be easy to work on just to make the mechanics happy. You build a car that consumers want to buy, and it's the mechanic's job to figure out how to work on it.

[VieElm]

> then the developers will simply follow the users.

That didn't happen with IE6. I think the web as platform is bigger than Apple as big as it may be. It's amazing to me that you're OK with a single company holding back the entire platform because of a single device. People use the web with machines that don't even have batteries.

Really to a developer who cares about the open web and standards, just throwing the whole concept of the web out of the window for the sake of Apple's priorities is so, so bad and it will never happen. At least that's my hope and prediction. The open web as a platform will guide my behavior with regards to how I engineer applications that run in the browser, whether Safari is on board or not.

[shadowmint]

> That didn't happen with IE6

Yes it did...but anyway, the detail is irrelevant; it's the point you're refusing to acknowledge:

A developer, building a product, is obsessed with growth metrics, OR, a slave to the pedantic demands of a client they're working for.

Either way, those demands require that a site be available to as many people as justifiably possible. The questions you have to ask are:

1) Is the the $ value of a customer using IE6 worth the time taken to make the site work in it? (No, almost certainly not)

2) In IE8? (Hopefully not, but you know, there are still a lot of these guys, and it's almost always a demand in the .gov space...)

3) In Safari? Yes. There are tonnes of these guys, especially on mobile where they don't have a choice, and no matter what fancy javascript 0-day API you're in love with, you can work around it without any significant effort.

The point:

Is safari holding things back? Yes.

Is it OK? Not really. It sucks.

Can you ignore safari and pretend it doesn't exist, and lose those customers? No. No you can't.

We're webdevs, sucking it up is what we're good at. We've had years of practice.

Suck it up.

The path forward, I think we'll find in the long run is going to be less native apis, more WebAssembly-style low level polyfills to implement new 'universal' features that run on all js runtimes.

[VieElm]

> Can you ignore safari and pretend it doesn't exist, and lose those customers? No. No you can't.

Actually we can, and where I work we do. Never has anyone complained about it. SO everything is just fine. So I don't need to "Suck it up".

[shadowmint]

Maybe you can, because either you work for yourself, or you work for some who doesn't care... but you're mistaken if you think you fall in the majority in that.

[exelius]

> That didn't happen with IE6.

Yes it did. That's the entire reason IE6 was such a headache: IE6 was by far the worst browser platform out there, but everything in the corporate world was written with IE6 in mind. This made it a nightmare to support these sites -- because they didn't work in Firefox or Chrome. So when IE6 was finally deprecated, it was a mad scramble to try to patch internal tools (or hack an unsupported install of IE6) so your HR person could access payroll.

[butterfi]

Rather then just downvote you, let me say that I (20+ years webdev) and my colleagues use our audience to determine what browsers we support, not our personal preferences. My job is to provide visitors to my clients websites with the best possible experience, not judge them on their technical choices.On the site I support, hundreds of thousands visits a year are from Safari users. Based on your comment ("deal with it"), you pretty clearly are not the kind of web developer I would ever hire. Or your engineer friends.

[exelius]

Yeah, the choice of which browsers to support is a business requirement informed by marketing, not a technical decision. Business requirements should inform the selection of technology, not the other way around. When you let technical requirements drive your business requirements, you end up with a product that is a poor fit to user's needs. It's hard enough to get users for a new product without engineering imposing arbitrary technical limitations.

[isaacremuant]

Without having practically any serious web dev experience (just some minor freelance here and there) I can imagine a world where you both are right.

They might've done the math and realize that the amount of safari users they might gain is not worth the cost of the extra development (time & money).

You obviously do.