Re: SVG crosswordplayer first release!!

On Sunday, December 7, 2003, 4:41:35 PM, Jim wrote:



JL> "Chris Lilley" <chris@w3.org> wrote in message
JL> news:662995667.20031207150919@w3.org...

>> SVG has a much better footing. Its already intolerant of WF errors,

JL> Unfortunately...

are you *mad*????

JL>  although at least it's not very intolerant like XHTML,

XHTML tolerates wf errors just fine, unfortunately, at least when
served as text/html.

JL> it
JL> still renders what it does understand up to that point.

It renders up to the point of NWF, yes. That means the author can figure
out where the error is and fix it.

>> 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> I think our difference is that you're suggesting FooSVG UA 6 has to display
JL> an error about something it successfully rendered in FooSVG UA 5

That depends on whether whatever FooSVG UA 5 renders is correct
according  to some Rec or not.

JL> - that I
JL> think is wrong, I'd be much happier if you simply said Conformant SVG UA's
JL> must not implement a particular feature,

Ok, we both want these to be not implemented; just have different
ideas on how to get there.

My ideas are based on quiet corridor conversations with SVG
implementors who say 'we are going to implement blah; its not in the
spec but there is content out there using it and it works in other
viewers so it has to work in ours too.

I am reminded of an anecdote about the author of the 'make' program.
He suddenly woke up in bed and realized there was a colossal error, and
he knew how to fix it. But then, he realized it was too late to change
it, because he already had six users.

JL> rather than error on it - my
JL> problem is the errors, not the lack of support.  Errors which users cannot
JL> understand are no use to anyone.

I understand where you are coming from. I disagree, though. Errors
which users cannot understand are an embarrassment to the author, and
ths the author fixes them. Also, many times the author uses a UA to
'see if it works'. For that particular user, the error is very
helpful.

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

JL> Yeah, the script ones - script errors are fine, I'd encourage those, but
JL> script is different to mark-up well written script today can deal with
JL> future errors, we can build future-proofing into our scripts (either by
JL> try/catching away the errors, or object detection)  we can't do the same
JL> with mark-up or CSS.

That is a fair point.

JL>  I can't afford to change the content I ship today next
JL> year, there's not the budget, I need to be happy that it won't confuse users
JL> in the future.

Then check that it is compliant. If you as a developer consciously
depend on a rendering bug, an undocumented feature, then that is your
choice and your risk; don't come crying to me if it doesn't work next
year or doesn't work on a different viewer.

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

JL> Yep me too!  I just think forcing errors to appear is not the way to go.

Instead, you suggest merely a spec that says 'don't do that'?

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

JL> I think us scripters have been more than able to keep DOM scripting alive
JL> with different parse-trees, you can also find some research over on wai-er
JL> awhile back I did which showed that the browser DOM trees were actually
JL> pretty similar.

'pretty similar' is pretty useless. Identical is a lot better.

JL>  Assuming you get a specific parse tree is impossible in
JL> scripting,

No,it isn't. The rules for parsing XML are pretty clear.


JL> and a mistake (accessibility or other users modify the parse tree
JL> for their own needs client-side, we need to cope with that, it's not just
JL> bad DOM's that are problem.)

Non-sequiteur. I didn't ask for a static parse tree, but a repeatable
one.

JL>   CSS is a different issue for sure.

>> They [HTML UAs] are f***ed and will stay that way for ever.

JL> I think we can agree on that!

And I don't want SVG to go the same sorry route.


-- 
 Chris                            mailto:chris@w3.org

Received on Sunday, 7 December 2003 12:56:54 UTC