- From: Jim Ley <jim@jibbering.com>
- Date: Sun, 7 Dec 2003 15:41:35 -0000
- To: www-svg@w3.org
"Chris Lilley" <chris@w3.org> wrote in message news:662995667.20031207150919@w3.org... > SVG has a much better footing. Its already intolerant of WF errors, Unfortunately... although at least it's not very intolerant like XHTML, it still renders what it does understand up to that point. > 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. I think our difference is that you're suggesting FooSVG UA 6 has to display an error about something it successfully rendered in FooSVG UA 5 - that I think is wrong, I'd be much happier if you simply said Conformant SVG UA's must not implement a particular feature, rather than error on it - my problem is the errors, not the lack of support. Errors which users cannot understand are no use to anyone. > 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. Yeah, the script ones - script errors are fine, I'd encourage those, but script is different to mark-up well written script today can deal with future errors, we can build future-proofing into our scripts (either by try/catching away the errors, or object detection) we can't do the same with mark-up or CSS. I can't afford to change the content I ship today next year, there's not the budget, I need to be happy that it won't confuse users in the future. > Because I see implementors asking about those, and trying to > implement them to work with existing content, and I want to avoid > that. Yep me too! I just think forcing errors to appear is not the way to go. > 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. I think us scripters have been more than able to keep DOM scripting alive with different parse-trees, you can also find some research over on wai-er awhile back I did which showed that the browser DOM trees were actually pretty similar. Assuming you get a specific parse tree is impossible in scripting, and a mistake (accessibility or other users modify the parse tree for their own needs client-side, we need to cope with that, it's not just bad DOM's that are problem.) CSS is a different issue for sure. > They [HTML UAs] are f***ed and will stay that way for ever. I think we can agree on that! Jim.
Received on Sunday, 7 December 2003 10:43:04 UTC