Re: SVG crosswordplayer first release!!

"Chris Lilley" <chris@w3.org> wrote in message
news:83886224.20031207185654@w3.org...
>
> 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*????

Possibly, but like most I don't believe I am - my arguments for not breaking
on non WF, is that a bug in a WF parsing of a viewer will render my WF
document in error (consider charset issues as the most likely place this
will break) ending up with it not-rendering through no fault of my own.

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

That would be tag-soup, not XHTML, If you would like to argue differently
can you please tell me how in W3 process to force a WG to address an issue
that is 8 months old, then we can do it in the appropriate forum.

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

User Agents are _user_ agents, they're not authoring tools, if you want a
"developer mode" then have a developer mode, their needs are very different
from users and we shouldn't combine everything in a single configuration.

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

My problem with this is the public process that SVG works to, we're
encouraged to test content to the draft specification, UA authors are
encouraged to publish viewers which implement draft features - This is a
very good think, but it means I have to publish content which is valid to
the draft ideas of SVG, inevitibly some things don't cut it, but I've
deployed my content, even if it's only on my personal site where I'm not
quite as worried about broken content given my limited audience.  However
with the timescale involved in a new specification it's very tempting to use
the new features professionally, and difficult to truely evaluate without
doing so, this means shipping content risking unstable features, I'm happy
to accept the content won't work with other versions - I hope it will or I
wouldn't ship it, but I'm not happy that it might instead of failing in ways
I've understood and allowed for (bad scripting etc.) it actually shows an
error because I used <chicken> and not <cock> for an element name.

> 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'?

Well it's far from ideal, hopefully there's a better solution out there
without the problems of popping up errors.

> JL>  Assuming you get a specific parse tree is impossible in
> JL> scripting,
>
> No,it isn't.

It is, because you can't assume your XML hasn't been modified between you
serving it and the script executing, if you feel it's a requirement of SVG
that such a method is possible, we need some more XML features...

> The rules for parsing XML are pretty clear.

In the case of HTML, XML parsing rules aren't relevant, but I accept your
point, howeve HTML DOM authors have had little trouble authoring to unknown
doms and the DOMs of different browsers are remarkably similar, even fixed
up DOMs are fixed up similarly.

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

It's not repeatable as content-modifying proxies not only exist, but are
extremely commonly used, they may be rarely used in SVG, but they're very
common in HTML.

Jim.

Received on Sunday, 7 December 2003 13:57:02 UTC