- From: Chris Lilley <chris@w3.org>
- Date: Sun, 7 Dec 2003 15:09:19 +0100
- To: "Jim Ley" <jim@jibbering.com>
- Cc: www-svg@w3.org
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