Microsoft Hatred FAQ

Mike Meyer mwm at
Tue Oct 18 21:57:59 CEST 2005

"Mike Schilling" <mscottschilling at> writes:
> "Mike Meyer" <mwm at> wrote in message 
> news:86mzl6yfko.fsf at
>> "Mike Schilling" <mscottschilling at> writes:
>>> "Mike Meyer" <mwm at> wrote in message
>>> news:86y84rxryr.fsf at
>>>> "Mike Schilling" <mscottschilling at> writes:
>>>>> "Mike Meyer" <mwm at> wrote in message
>>>>> news:86fyqzzskt.fsf at
>>>>>> "Mike Schilling" <mscottschilling at> writes:
>>>>>>> What matters in generating HTML is which browsers you want to support
>>>>>>> and
>>>>>>> what they understand.  Standards and recommendations are both
>>>>>>> irrelevant.
>>>>>> Unless, of course, you want to support any compliant browser.
>>>>> Since no browser I know of is perfectly compliant (e.g. bug-free), 
>>>>> that's
>>>>> not a feasible goal.
>>>> I guess you'd say developing any software isn't a feasible goal,
>>>> because it'll never be bug-free, will never have bug-free compilers to
>>>> compile it, bug-free linkers to link it, bug-free GUI/db/etc libraries
>>>> to link with it, bug-free servers to communicate with, and bug-free
>>>> operating systems to run it on. Fortunately, most developers aren't
>>>> quite that anal, and realize that you can get useful work done in a
>>>> less-than-perfect environment.
>>> I'm not speaking theroetically. My company (though not me personally)
>>> creates browser-based UIs, and one of the biggest expenses has been 
>>> dealing
>>> with IE rendering bugs   Given the market share of IE, the fact that
>>> something should work, and even does work in Firefox, Opera, etc, is
>>> irrelevant.  If it breaks IE, we can't use it.
>> Been there, done that, threw out the T-shirt as to ugly to wear.
>> Yes, you have to work around bugs in the popular browsers. That hasn't
>> changed since the first published specs showed up. That doesn't mean
>> you throw out the standards and only support a trivial set of
>> browsers.
> If you're working on a commercial product, it means you support IE (possibly 
> being able to insist on a specific patch level), Foxfire if you can, and 
> ignore the < 1% of the market that won't live with those restrictions. 

Just because you do things some way doesn't mean that's the only way
to do them, or even the right way to do them.

That's one way to do it. Didn't used to be, because the players have
changed.  Which is part of the cost of doing it that way - your
targets change as the publics taste changes.  It only works for a
specific market (though it's a very big one); should you decide to
expand into another market, you'll find your targets have changed

One alternative, as I've said, is to write to the standards, and then
work around bugs in the popular browsers. If the public whim changes
which browser is most popular - it only has minimal impact on
you. Should you decide to move into a different market, your existing
development process works with only minor changes.

Mike Meyer <mwm at>
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

More information about the Python-list mailing list