W3C home > Mailing lists > Public > www-svg@w3.org > July 2004

RE: The 'hanlder' element

From: James Bentley <James.Bentley@guideworkstv.com>
Date: Tue, 20 Jul 2004 12:26:23 -0600
Message-ID: <687B7858C99ED711B87B00B0D0D1C922C0FB42@LAMBIC>
To: 'Robin Berjon' <robin.berjon@expway.fr>
Cc: 'Dean Jackson' <dean@w3.org>, "'www-svg@w3.org'" <www-svg@w3.org>

I'm currently preparing an assessment of SVG Tiny and SVG Basic
for TV. As you mentioned, the platforms are very diverse. Our
low end target is 20MHz CPU with less than 1.5MB of RAM - for
video, OS and other resources. Our high end is around 200MHz
with substantially more RAM (though no where near the capability of
today's desktop PC). With this constraint, there is not enough room, or
processing power for full scripting support, full DOM support and
extensions for set top control and application deployment.

Though the low end is extremely under powered, its graphics capability
is, in many instances, much better than a mobile phone. Even the low-end
can produce Gradients (very easily in the vertical plane). Additionally,
set tops support MPEG rendering - in a stream or, in some cases, in stills.
Further, more audio formats are available.  I'll address all these problems
in a future message (once my analysis is complete).

As for DOM3 key events. It appears that the mark up may be (please excuse
any bad form)
<rect onkeydown="doSomething()"/>

<set begin="r.keydown" ...>

but neither instance allows you to listen for specific keys (there is no
way to target a specific key - 'U+001b'). If there is, an example would be
Otherwise, it would require script to access the keyIdentifier as well as
the state
of the shift, alt, control and meta attributes. What would solve our current
need is for the handler to allow something like this:

<handler type="image/svg" ev:event="keyEvent:'U+001b'">
	<!-- render some stuff or make some stuff visible or insert a
foreignObject or reference outside of this document -->

If there is a better way to do this with SMIL - then I'd like to proceed
that way.
Using SMIL would allow me to implement a smaller subset of SVG - say a TV

Sorry for the typo in the subject line (just noticed it).

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

> 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
> 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 14:37:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:02 UTC