Re: SVG crosswordplayer first release!!

On Sunday, December 7, 2003, 2:44:40 PM, Jim wrote:


JL> "Chris Lilley" <chris@w3.org>
>> JL> Sure, but requiring that all legacy content need be upgraded so the
JL> legacy
>> JL> content can be accessed on the new viewers is a very bad idea, the new
>> JL> viewers will be seen to be at fault not the content.
>>
>> No, the reverse. If there is no message then the viewers that don't
>> implement old broken stuff are seen to be at fault. If there is a
>> message then its clear which content is broken.

JL> I don't buy that, I've seen lots of people moan like mad when browsers have
JL> switched to standard behaviour

Uh, did you switch sides? you are arguing my point. Yes, if you don't
flag the errors early on then you can't switch later; people moan
about the rendering being 'different' and you are stuck there forever.

JL> from non-standard, a lot of people don't
JL> care, they need something that works.

No, they think they want something that works. In fact they want
something that works in their one browser that they developed it for
and that they showed to the client to get paid; whether it works on
any other browser is dealt with by ostrich tactics.

JL>   This is why RFC 2854 tells authors of
JL> UA's that they have to bugwards compatible with other UA's.


JL>    We can't
JL> break legacy content,

We can always break legacy content. We just have to evaluate the
amount of it that there is, the fluidity of the market, how much
correct content there is, and how young the market is.

HTML spent its entire lifetime being broken. It spent some time
pretending to be SGML while never seriously expecting anyone to
implement it like that, which was a disaster.

SVG has a much better footing. Its already intolerant of WF errors,
something that HTML has yet to achieve. SVG does have a small legacy
of ASV3-specific brokenness. That can be cleaned up and fixed, or it
can be left to rot and diluted out by much more good content, or it
can rot and spread to all the rest and be supported evermore and
eventually added back to SVG 3.0 as a bugfix (holds nose and mutters
"DOM 0") so that all the SVG renderers can add duplicate support for
stuff that was never in the standard anyway.

JL> we can only build something better that authors will
JL> want to author to.

>> Remember this isn't 'legacy' as in 'it was previously a standard' but
>> legacy as in 'nonstandard, proprietary extensions, relying on bugs in
>> a particular viewer'.

JL> bugs?  onkeydown was hardly a bug, it's simply a problem of DOM events not
JL> being ready - it was even in the drafts wasn't it - so to get SVG 1.0 out,
JL> implementation experience was solicited, people had to implement it, we
JL> shouldn't penalise people for doing that.

Ah , okay. If something was in SVG 1.0 Rec then yes, deprecation has
to be more carefully handled. I am talking about the borken jey stuf
and the filling zero width rectangles to get hairlines and silly
getFoo methods that were added as a temporary hack to owrk in Netscape
4.x and stuff like that.

Because I see implementors asking about those, and trying  to
implement them to work with  existing content, and I want to avoid
that.

>> And without an error message, yes, new viewers will be seen to be at
>> fault. So they will be under pressure to reverse engineer bugs etc and
>> the format gets defined by reverse engineering and impenetrable
>> hueristics, not by the spec.

JL> but with an error message, we have no reason to upgrade as our content we
JL> are used to accessing no longer works - that's much more important than new
JL> features, we won't know about those until after we've upgraded, and if we
JL> never do.   This is quite apart from the systems that use an embedded viewer
JL> to display content - having legacy ones of these break will be unacceptable
JL> so the UA authors will not include it, they'll lose their customers.

>> hence the sorry state of html browsers today that have not
>> improved significantly in three or four years.

JL> Well you know I'd say that there's been no reason to improve, there's been
JL> no new mark-up language features,

There has been plenty of reason to improve, both decent CSS and
interoperable DOM scripting require an actual parse tree that is -
gasp! - the same in two different browsers. But they don't get it, so
its a mess. They don't get it because the weight of broken legacy to
good stuff is zillions to one.

JL> and XHTML is still broken. What improvement did you expect from
JL> HTML UA's?

I don't expect any improvement from HTML UAs, at this point, ever.
They are f***ed and will stay that way for ever.

Which means that, for example, CSS3 will only ever be implemented by a
non-HTML UA.



-- 
 Chris                            mailto:chris@w3.org

Received on Sunday, 7 December 2003 09:09:19 UTC