- From: Dave J Woolley <david.woolley@bts.co.uk>
- Date: Mon, 12 Feb 2001 13:42:27 -0000
- To: www-svg@w3.org
> From: Neil Stansbury [SMTP:nstansbury@m85.com] > > 3. Similar to the <g> element define a <button> element as follows: > > <button type="COO|COCO" (Click On/Off, Click On/Click Off) > default rect: fill: etc > StateOver: rect: fill: etc > StateDown: > StateRelease: rect: fill: event:javascript call, etc etc > StateOut: > /> > [DJW:] There's already a button element in HTML, albeit in a different namespace and not falling back gracefully. There also seems to be a position that all forms functionality should be achieved by escaping to other XML namespaces (XHTML + XFORMS). However, if you did have this element, it would, I think, need to have arbitrary up and down images and therefore require sub-elements, not attributes. Duplication of active elements with HTML makes it difficult to produce documents that degrade gracefully, and, unlike Flash, that is a design aim of SVG, albeit one that I think will largely be disregarded in practice, to the detriment of the web's universality of access. Scripting solutions tend to be worse, though. > I know this can be done with js and css/xsl, however to do the same > requires far more than five lines of code, and _everybody_ will use > buttons. I know the CSS principle is [DJW:] I do prefer declarative solutions to the security risks and complexity (halting problem etc.) implicit in scripting. > This information is intended only for the use of the named > recipient. Internet communications are not neccesarily [DJW:] Clearly not true!! This is a list with an open archive! [DJW:] -- --------------------------- DISCLAIMER --------------------------------- Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of BTS.
Received on Monday, 12 February 2001 08:43:01 UTC