W3C home > Mailing lists > Public > www-svg@w3.org > October 2005

RE: SVG12: editable definition

From: Doug Schepers <doug@schepers.cc>
Date: Tue, 11 Oct 2005 23:35:20 -0400
To: <www-svg@w3.org>, "'Chris Lilley'" <chris@w3.org>
Message-Id: <20051012033526.4F602B3380@filch.dreamhost.com>

Hi, WG-

With this flurry of responses, specifically about "editable", I am wondering
if you also changed the values from "true | false" into something more
extensible, like "editable | none" *, as per my comment of November 2003
[1].

I'm also curious what happens when all the content is removed from a text
element by backspacing... will there still be a way to activate that text
element for input? A very common use case I'm thinking of is a form
textfield that might start out empty; how can a user select a non-rendering
element to start entering text? Possibly by clicking on an associated
'rect', which would toggle the editable attribute of the text element... but
that wouldn't activate it for input, merely make it editable... 

So, instead of 'true | false', it might be sensible to treat it like a SMIL
'begin' attribute:
 editable='click; borderRect.click; accessKey(e)'
or go whole hog and make it a SMIL-type child element of the text element,
which would allow it to take more parameters in the future.


[1] http://lists.w3.org/Archives/Public/www-svg/2003Nov/0031

* or "editable | static"; or "text | none", for future situations where
other elements might be editable and this an attribute inherited from a
mutual group; or "singleline |
multiline | none" which might allow for the creation of line breaks.

Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.
 

Chris Lilley wrote:
| 
| 
| On Monday, April 18, 2005, 12:59:07 AM, Bjoern wrote:
| 
| BH> Dear Scalable Vector Graphics Working Group,
| 
| BH>   In 
| http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/text.html the 
| BH> editable attribute is defined twice (one definition for it on the 
| BH> textArea element, another definition for it on textArea 
| and text, it
| BH> seems) and worse these definitions are inconsistent (e.g., it is 
| BH> defined as both animatable and not animatable). Please change the 
| BH> draft to have only one consistent definition for the attribute.
| 
| Thanks for your comment. The descriptions of the editable 
| attribute on text and textArea now both link to the one 
| definition of the editable attribute, which is animatable.
| 
| Thanks for catching this, and please let us know if it 
| doesn't satisfy your concern.
| 
Received on Wednesday, 12 October 2005 03:35:33 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:31 GMT