Re: FW: IE4.0 and W3C Standards [long, probably pointless]

On Wed, 5 Mar 1997, Chris Lilley wrote:

> On Mar 5,  7:24am, Benjamin Franz wrote:
> 
> > Ummm...While on first read this seems to say that MS is just following the
> > lead of the W3C, I think a closer read will reveal that this is just a
> > (somewhat wordy) denial of the extensions being proprietary. While it is a
> > good thing that MS is working for a formal public definition of these
> > extensions - I do not believe that this changes the public perception that
> > the W3C standards process is just a rubber stamp for what MS and NS plan
> > to do *anyway*.
> 
> That may be the public perception but the reality is that W3C specifications
> represent an interoperable consensus among our members. We have 160, by
> the way, and you only named two. By no means are all suggestions rubber
> stamped. Some experiments fail, and sometimes W3C members have to leave
> these behind and move to new ways on which there is consenus.

You implicitly admitted that at least some proposals *are* rubber stamped,
although this may not be what you meant to say. How many major proposals
from MS or NS have arrived with the 'we are already implementing this in
our browser' seal of approval? How many of those were ultimately rejected
by the W3C? I don't want to know what they are: just the corpse count.

> > And for any set of extension to be viable, they would have
> > to be well defined anyway or no one could use them, so backwards
> > engineering them would be comparatively trivial whether or not MS works
> > with W3C to produce an 'official' standard.
> 
> A fine piece of circular logic.

Less so than MS saying 'We are following the lead of the W3C on a
proposal which which we brought to the W3C and are pushing.' It is
semantically equivalent to saying 'we are following the lead
set by ourselves'.

> Many extensions are 'viable' in the sense
> that they may be taken up rapidly but are often poorly documented if at
> all and the definition may change from week to week. A definition which
> depends on backwards engineering is fragile; plus backwards engineering
> is hard if you want interoperability and are aiming towards 100% bugwards
> compatibility with some proprietary feature. The first 75% is often easy ;-)

Versus HTML-3.2, CSS1, Client Side Image Maps, or OBJECT, *as actually
implemented*? ;-) 

Anyone who has ever tried to actually use these can tell you that
'bugwards compatibilty' is the order of the day.  Substantial sections of
3.2 only work in NS or only work in MSIE or don't work in *either* as
spec'd (and yes - for all practical purposes, NS and MSIE *are* the
browser market. If someone else comes above 5% of the market - I'll start
worrying about them). Ditto for CSS1, CSIM, and OBJECT.

OBJECT is particularly heinous in MS's mis-implementation - they managed
to destroy the usability of OBJECT *COMPLETELY* for anything but ActiveX
objects. If I were to try to use it for anything except ActiveX - I
would hang 25% of the browsers visiting my site (not to mention the
'insecure activeX object notices'). You can't even embed a JPEG using it
(I tried). It might as well be named the ACTIVEX tag.

To tar NS in this mess as well - they have rendered CSIM's of only
marginal use to me because of a combination of bugs. Essentially - forget
external references to CSIMs. NS won't do them and disables even the
*SERVER* side imagemap if you try. I won't talk about the interactions of
tables and CSS1 stylesheets while NS4 is still in beta...they still have
time to fix those problems.

It will probably be *years* before the installed base of MSIE/NS3.01
diminish sufficiently to solve the CSIM and OBJECT problems - even if they
are ALL fixed in the V4 releases (I'm not holding my breath).

Any web author can tell you that the published specs of the W3C are useful
primarily for running syntax validation on your documents. It is nearly
useless in terms of knowing what will actually be understood by a browser
(other than to suggest 'try this and see if your browser can do it'). I
*NEVER* implement solely from the spec - I always implement according to
spec - but then check against every variant of NS and MS I have (Mac,
Unix, Win, v2,3,4) and Lynx to make sure nothing wierd is happening due to
partial and broken implementations. And then I pray that the next major
release doesn't break everything into little pieces. 

I understand the MS developer's frustration with a somewhat mis-leading
article.  And I have a great deal of respect for the programmers who are
trying to move a monster in a very short time. That doesn't mean, however,
that I do not see MS's (and NS's) *corporate policies* as being less than
open standard directed. I hear a LOT of hype about open standards from
both - but when push comes to shove: proprietary is what I see roll out
the door and onto the web. 

It is not a slam on the *programmers* - it is a slam of the *corporate
policies* involved. 

-- 
Benjamin Franz
"Pay no attention to what people say: Watch what they *do*."
                                           --- ???

Received on Wednesday, 5 March 1997 17:03:28 UTC