Al Sparber wrote:
[...]
Reducing the disparities is not the same as eliminating disparities.
It is human nature to make mistakes. It's often the best way to
learn.
Yes, it is. However, it is not human nature to make use of what they
have, or should have learned, if they can get away with their old
mistakes and maybe a few patches.
Just ask the IE7 team - or tear apart IE7 for a closer look.
This "human factor" is in part what's holding back all standard based
web development, as most of what's poured out as web sites today is
based on old mistakes and not standards. One can take any failing site
apart, and find that the main cause for failings in any somewhat
standard compliant browser is old and new designer mistakes which has
nothing to do with browser-bugs.
1. All browsers will always have some bugs
Yes.
2. Some users will always be browsers with an older version
Yes.
It is for these reasons that all browser makers need to provide
developers with a means of eploying targeted workarounds.
For (users of) old versions, maybe, but certainly not for new ones -
unless one wants bugs to become permanent parts of particular browsers.
Since old browsers can't be retrofitted, we'll have to make use of some
kind of progressive enhancement or (dis)graceful degradation for those
anyway. Nothing new there, regardless of what the future brings.
MS has said they want old bugs to stick, apparently because they're
afraid they'll break the web otherwise. Thus, they have added ways for
us to work around their bugs when necessary ( = most of the time).
That's their strategy, and it'll probably work for them - but not
necessarily for us.
AFAIK: the developers of other major browsers want to find and get rid
of the bugs - any and all bugs, and don't want anyone to have to work
around them.
That's their strategy, and it sounds like a much better one
to me - even if human nature will prevent them from ever reaching
perfection.
In which way is it better to let developers send code specifically
for fixing a bug, which creates a dependency of that code on the
bug in question, than fixing the bug? If such dependencies are
created, they make it harder to actually fix bugs.
That's a great philosophy for teachers and parents to have. It does
not work so well, however, for businesses. The assumption, again, is
that human nature is imperfect. Mistakes will always be made.
Mistakes should be corrected at the source - not "covered", or else the
mistakes risk becoming a permanent part of the source - see IE/win.
Whether the source is a browser, or, as is more common: the site and its
developer(s), doesn't really matter when dealing with human
imperfections. How should one learn of ones mistakes if there's never
any need to correct them?
So long as there are more than one browser, there will be unique
bugs. It's useless to talk about MSIE having lots of bugs because it
only takes one bug to keep a developer up at night. The reason I like
conditional comments is that once I identify a fix for IE, I can fix
it in a fully insulated way and for specific versions.
Conditional comments in IE/win are fine, because no-one in their right
mind will use them to break that browser. Site-developers would lose
their jobs if they did.
I'm not so sure that human nature and job-security will save other
browsers from being intentionally broken though - plenty of examples
around already. Thus, from a browser-developer or browser-user's point
of view I'd call built-in targeting-means a death-trap for any serious
contender on the browser-market.
We all know the use, mis-use and abuse of "browser sniffing", which have
lead to built-in cloaking of userAgent strings and lost value of an
otherwise perfectly good browser-ID. Any other built-in targeting-means
would need to have similar "off-switches" to defend against human
nature, which would make the whole targeting just as unreliable.
Consequently: I wouldn't go down that road for any price, even if it
might look like a good, short-term, solution.
I recognize differences of opinion here and am so glad that this
discussion remains civil. The object is always better standards
support. I can't change Opera's mind and while I disagree with their
premise, I can only hope that as this thing runs its course there
will be benefits for us web developers and a better window into the
web for all users.
We agree on the objectives, so exchanging opinions on how to go about it
shouldn't lead to any side-tracking. I only want standards to be
properly supported across the board of new browsers, so I can develop
sites based on standards and not on browser-quirks. Fixing things in old
browsers provides enough "fun" to prevent death caused by boredom.
I'm looking forward to the day where we can rely on a perfect piece of
software to create the perfect "missing link" - generated page code -
between design and browsers/end-users, but that's probably a bit beyond
(X)HTML5, CSS3 and ES4 etc, and maybe beyond my time on earth, so I'm
not holding my breath :-)
For now I'm welcoming any attempts on "shake-ups" in the market, as
there's always a chance that it'll lead to improvements for both us and
the end-users when the pieces fall back into place.
regards
Georg
--
http://www.gunlaug.no
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
