[yoodenvranx]

> why should any website know all that?

As a developer:

Without user agent: How would I easily detect which browser breaks a certain feature on my project?

If I deploy a new feature and see through logging that a browser X is not able to do Y then I can install X on my machine and test and fix it.

If I don't have a user agent then I can just detect that after deploy there are more cases where Y fails but I don't know which browser is responsible for this.

[CaptSpify]

As a developer: If we actually pushed browsers to fix things, you wouldn't need to worry about that. Why should the job fall to you to work around their shitty implimentation of the spec?

[gizmo385]

Because when management asks you why their site that they paid hundreds of thousands of dollars for doesn't work on <insert major browser here>, your answer can't be "the browser's implementation of the spec is shitty, blame them." Your answer is going to be, "Yeah, sure, let me fix that."

[chriswarbo]

> your answer can't be "the browser's implementation of the spec is shitty, blame them."

If it's a major browser which management cares about, then you should be testing with it already. If you're not, then logging user agent strings isn't going to help.

Logging user agent strings would help if, for example, an unexpectely-large proportion of users are using a "non-major" browser, in which your site is broken.

If the proportion is small, management won't care.

If the proportion is expected, then market/demographic research is partly to blame; update the spec.

If the browser is "major", you should be testing with it anyway.

If the site isn't broken, there's no problem.

[deecewan]

I see what you're saying, but unfortunately, especially in enterprise, the browser version is often locked to something quite old. One of our clients has locked to Chrome 48.

Even if Chrome followed the spec to a T, programmers still write bugs. So, I'm not going to expect a browser (at least) 15 versions old to behave perfectly. And we all know that the spec isn't perfectly implemented.

So, no. Unfortunately sometimes there are things that will make management care a lot about a browser that they really shouldn't.

[chriswarbo]

> Unfortunately sometimes there are things that will make management care a lot about a browser that they really shouldn't.

I never said management should or shouldn't care about this or that browser. I never said anything about browsers being new or old.

I said that developers should be testing with whatever browsers management cares about. If management care about it, and there's some justification, then add it to the spec.

> unfortunately, especially in enterprise, the browser version is often locked to something quite old. One of our clients has locked to Chrome 48.

That's an excellent justification for having Chrome 48 compatibility as part of the spec, so you should already be testing your sites with it. What has that got to do with user agent strings?

Is Chrome 48 even old? I tend to ensure IE6 compatibility, unless I have a good reason otherwise (e.g. voice calls over WebRTC, or something). When I'm using w3m, e.g. to read documentation inside Emacs, I occasionally play around with my sites to ensure they still degrade gracefully.

[CaptSpify]

Well, your answer should be: I'll reimpliment it using known, simple, stable technologies. But for some reason our industry hates those things.

[seandougall]

So... not the web, then? :-P

[nitrogen]

Management is not some all-powerful, all-knowing spectre impervious to persuasion. Don't give up so easily.

[matte_black]

Don’t forget “Also, it’s going to cost $X more.”

[fixermark]

Because 100% of implementations are differently shitty. There's no amount of "pushing browsers to fix things" that is going to catch 100% of novel interactions resulting from different combinations of the declarative HTML and CSS languages out in the wild (especially when JavaScript then comes along and moves all those declarations around anyway).

[CaptSpify]

Sure, and the browsers that stray further off will get used less and die off.

And if you are using the latest and "greatest" JS features, you have to expect the failures that happen. If you enjoy sitting on the bleeding edge, don't complain about getting cut.

If you implement features using known, simple and stable tech, things will generally work great without needing to worry about special cases.

[talmand]

"Yeah sure thing boss. I'll get on the phone to Microsoft and ask them to fix that issue in IE8 that you insist needs to be supported."

[CaptSpify]

So you think a better way is spending your evening trying to fix your square pegs so that they fit in round holes?

Why would you willingly do that to yourself? If we pushed browser developers to actually do their job, they wouldnt be pushing their weight around like they do now.

[zodPod]

Yeah why ask to be empowered to fix your own problems when you could just beg someone else to fix them?

[CaptSpify]

How is a browser not rendering correctly not their problem?

[zodPod]

Who said it's not their problem? But it's also relying on someone else to fix something that you could fix. If I need to get somewhere it doesn't matter if my car's engine is broken because the company stabbed it with bolts I just need a working car. I can sit around whining about how awful the car company is but it doesn't get shit done fast.

Extreme ownership of problems. It's a really helpful concept. You'll stop trying to blame people all of the time for things that you can control and find solutions for them instead. On top of that, if you can't control it you can let it go as something that you can't fix.

[CaptSpify]

If getting shit done fast is your goal, then you are gonna get burned, and I have very little sympathy for you. We should be focusing in getting shit done solid. If it's such a big deal that something works, why build unstable systems in the first place?

If you need your car to be reliable, don't bolt experimental features onto it, and test it before you need to take it on the road.