RE: The 'hanlder' element

On the 'accesskey' attribute. This should be changed to allow
key identifiers (as in DOM level 3)- not just characters. The character
content, described in HTML 4, is stated to be from the document's
character set.

-----Original Message-----
From: Robin Berjon [mailto:robin.berjon@expway.fr]
Sent: Tuesday, July 20, 2004 12:06 PM
To: James Bentley
Cc: 'Dean Jackson'; 'www-svg@w3.org'
Subject: Re: The 'hanlder' element


James,

James Bentley wrote:
> That's great but it doesn't cover non-character key presses,

DOM 3 Events should address all possible text and key events, if it 
doesn't please show us where as that'll be an issue.

> and it
> doesn't address the issue of not using script. It would be nice if the
> handler could encapsulate SVG, or the SMIL provided by Cameron.
> If it encapsulated the SMIL, we could set the 'display' attribute, of
> some group, when the event occurs. If it encapsulated SVG, we could
> interpret the SVG when the event occurs. In the example below, I
> may be able to write '<set begin="r.text" ...>', or something 
> similar, but that would, I assume, capture all character input events.
> It would be nice to bind the handler to a specific key event - even
> non-character key events.

Are you asking for an extension of the accessKey() SMIL specifier? If 
so, we have had other requests for that in the recent past but so far 
have turned them down due to various issues and the high proximity of 
the SVG Tiny 1.2 release. If you add a case for it, we could consider it 
again, either for 1.2 (if it's really urgent and well motivated), or for 
1.3.

> Essentially, I'm working in a serverly constrained environment where
> scripting should be minimized, if not eliminated. If necessary, perhaps
> we can support extended 'handler' types for SVG Tiny, only. Also, I don't
> have a 'standard' input device, so key codes are not necessarily
character,
> and
> don't always have the same meaning as on the QWERTY keyboard.

That is also the case on mobile devices, yet general agreement is that 
we address them quite well.

> Ultimately, I believe the W3 will need to consider another profile to meet
> the needs of my environment - a television profile. While Tiny is, for the
> most part, implementable, it is too constrained. However, Basic is not
> constrained enough for some low-end platforms (a conversation for another
> time, I suppose).

If it is too constrained then your environments are not as constrained 
as you say :) TV is a pain to address because you get a large range of 
devices, ranging from half the power of a low-end mobile phone to stuff 
that can reasonably compete with a desktop (and might just be a PC inside).

It would be helpful if you could say where you find Tiny too constrained 
for your needs, and why -- since you appear to be less constrained than 
mobile devices -- why you can't use script when they can.

-- 
Robin Berjon

Received on Tuesday, 20 July 2004 15:36:18 UTC