W3C home > Mailing lists > Public > www-svg@w3.org > December 2003

Re: SVG crosswordplayer first release!!

From: Jim Ley <jim@jibbering.com>
Date: Sun, 7 Dec 2003 15:41:35 -0000
To: www-svg@w3.org
Message-ID: <bqvhnv$mur$1@sea.gmane.org>

"Chris Lilley" <chris@w3.org> wrote in message

> 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
> 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!

Received on Sunday, 7 December 2003 10:43:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:57 UTC