Re: The 'hanlder' element

On Tue 20 Jul 2004, James Bentley wrote:

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

As Robin said, we've had a few requests for that in SVG 1.2,
but have resisted because it effectively means modifying the
SMIL syntax. 

The fact that you request it, as a member of the public, means
that we should probably look at it again (soon).

I too think that you need to be able to
start animations beased on a particular key/text event.

Dean

> 
> -----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 Wednesday, 21 July 2004 03:05:50 UTC