4 ms·

For even more convenience I don't test for IE compliance. I test for ECMA and W3C standards compliance and don't write any vendor specific code.

by gaelow 12y ago

pling 12y ago
That means your stuff probably doesn't work on IE properly. Not joking (and I know this sucks) but there are a shit ton of IE users out there still and I'm not willing to hang our product for convenience. Vendor specific code is a reality we're going to have to live with for a long time yet.
- gaelow 12y ago
  Don't get me wrong: I agree that if you are contractually forced to write IE compliant code for all major versions still in use, vendor specific is the only way to go. Also if the numbers show it's worth the extra resources, then go for it. But that's not my case, and the same goes for many others; Microsoft already got the hint on that and they are starting to catch up and adhere to standards on their latest versions and trying to get everybody to use them (it was about time). Since there are way more teams like ours than big teams funded with huge piles of cash, we have actually managed to put the ball in their court and they cannot make us do the monkey dance as much as they used to. Can we all avoid writing vendor specific code? Maybe not unconditionally, but we are almost there.
matthewmacleod 12y ago
I appreciate what you're trying to say there, but in practice most developers can't adopt this solution. Unless you're writing for known platforms (an internal web app, say) or building a throwaway demo, you will practically speaking have to compromise and support vendor-specific code where it's required by your users. The goal of most real-world software is to deliver a working, usable product – not to produce lots of standards-compliant code.
- gaelow 12y ago
  The goal is to deliver the most profitable code in the specified timeframe and with the resources provided. That's how you organize your priorities. For us in many cases it means to throw away vendor specific solutions in favor of most-major-browser compatible subsets of the current industry standards, even if it means throwing out support for older versions of IE. For some users it might mean using a different service, but for most of them it means switching to a different browser because their favorite app doesn't work on IE. And that's why Microsoft is going for standards compliance and timely browser updates more than ever.
Igglyboo 12y ago
Writing for standards compliance is great when you don't care where/if your code works, what browser do you use that perfectly adheres to all the standards?
- gaelow 12y ago
  No browser adheres 100% to the standards. I use resources like MDN and some automated testing tools to make sure the subset I use is properly implemented on all major browsers (all but IE <= 8, which really sucks at it). But, subset or not, what I write is still 100% standards compliant code, in almost every project I'm involved with. I avoid as much as possible writing vendor specific code. The result is I hardly ever get a complaint about my code working on one browser and not working on another.

For even more convenience I don't test for IE compliance. I test for ECMA and W3C standards compliance and don't write any vendor specific code.

by gaelow 12y ago

For even more convenience I don't test for IE compliance. I test for ECMA and W3C standards compliance and don't write any vendor specific code.

pling 12y ago

That means your stuff probably doesn't work on IE properly. Not joking (and I know this sucks) but there are a shit ton of IE users out there still and I'm not willing to hang our product for convenience. Vendor specific code is a reality we're going to have to live with for a long time yet.

gaelow 12y ago
Don't get me wrong: I agree that if you are contractually forced to write IE compliant code for all major versions still in use, vendor specific is the only way to go. Also if the numbers show it's worth the extra resources, then go for it. But that's not my case, and the same goes for many others; Microsoft already got the hint on that and they are starting to catch up and adhere to standards on their latest versions and trying to get everybody to use them (it was about time). Since there are way more teams like ours than big teams funded with huge piles of cash, we have actually managed to put the ball in their court and they cannot make us do the monkey dance as much as they used to. Can we all avoid writing vendor specific code? Maybe not unconditionally, but we are almost there.

matthewmacleod 12y ago

I appreciate what you're trying to say there, but in practice most developers can't adopt this solution. Unless you're writing for known platforms (an internal web app, say) or building a throwaway demo, you will practically speaking have to compromise and support vendor-specific code where it's required by your users. The goal of most real-world software is to deliver a working, usable product – not to produce lots of standards-compliant code.

gaelow 12y ago
The goal is to deliver the most profitable code in the specified timeframe and with the resources provided. That's how you organize your priorities. For us in many cases it means to throw away vendor specific solutions in favor of most-major-browser compatible subsets of the current industry standards, even if it means throwing out support for older versions of IE. For some users it might mean using a different service, but for most of them it means switching to a different browser because their favorite app doesn't work on IE. And that's why Microsoft is going for standards compliance and timely browser updates more than ever.

Igglyboo 12y ago

Writing for standards compliance is great when you don't care where/if your code works, what browser do you use that perfectly adheres to all the standards?

gaelow 12y ago
No browser adheres 100% to the standards. I use resources like MDN and some automated testing tools to make sure the subset I use is properly implemented on all major browsers (all but IE <= 8, which really sucks at it). But, subset or not, what I write is still 100% standards compliant code, in almost every project I'm involved with. I avoid as much as possible writing vendor specific code. The result is I hardly ever get a complaint about my code working on one browser and not working on another.