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

Re: SVG crosswordplayer first release!!

From: Chris Lilley <chris@w3.org>
Date: Fri, 5 Dec 2003 15:27:31 +0100
Message-ID: <193719788.20031205152731@w3.org>
To: "Jim Ley" <jim@jibbering.com>
Cc: www-svg@w3.org

On Thursday, December 4, 2003, 9:36:06 PM, Jim wrote:

JL> DTD validity is the problem, not validity.  DTD's aren't rich enough for
JL> mixed namespace XML, there are other mechanisms available.

This is very true, and is why we are moving to schemas.

JL> Of course, I was just asking for clarification of what exactly you meant,
JL> given that key events are a requirement for a crossword player and there's
JL> no SVG dtd available that contains them, do you expect L to produce a custom
JL> DTD specifically to address the attribute?  Don't you think that's rather a
JL> waste of time considering the value it would give?

The issue here is not whether the DTD describes the attributes or not.
Its possible to produce one that  does, in fact early drafts of SVG
1.0 probably had those, before they were removed from DOM2 and thus
removed from SVG1.0

The issue is that

a) crossword players are one example of an application that cannot
avoid text entry. Keyboard or text events are the obvious way to do it
(an onscreen keyboard is another option, but less desirable).

b) DOM2 events were rightly removed, because of poor
internationalization. Its important (for the 'other' meaning of
"accessibility") to have stuff that works worldwide.

c) DOM3 text events and keyboard events are much better and much more
device independent (abstracting out any input method thatis used is
not just a help for japanese, chinese and korean; it also helps
western languages where the number of keys is less than the number of
characters, eg cellphones). However, they need an SVG 1.2 player

d) Meanwhile, ASV3 implemented DOM2 events while they were in the
spec, the player continues to be widely deployed, and other players
(Batik, Corel) are under pressure to add these broken, and now
non-standard, interfaces to work with existing content.

The solution to this problem is

1) Encourage SVG implementors to implement DOM 3 Events

2) Build test content, get DOM 3 Events and SVG 1.2 through CR

3) Deploy content that uses DOM 3 events

4) Encourage maintainers of legacy content to update to the
standardized form

5) Discourage authoring tools from making the old, non-standard stuff

6) Encourage SVG implementors to display warnings if they encounter
the old key events stuff.

 Chris                            mailto:chris@w3.org
Received on Friday, 5 December 2003 09:27:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:59 UTC