Re: [SVGMobile12] SVGT12-207: "editable" attribute for text

Hello www-svg,

Maciej Stachowiak <mjs@apple.com> wrote:
> - Spec says: 'If set to "none" the contents of the text or textArea  
> elements must not be editable in place through the user agent.' It  
> seems inappropriate to require that the text *must* not be editable,  
> even if allowed through other SVG-independent mechanisms such as  
> contentEditable, designMode, CSS editability, etc.

We agree, the intent was not to prevent other editing methods (like
loading the file into an editor, even) only to indicate when the SVG
implementation should make text editable and when it should not.

We have reworded this to say that if set to none, SVG editing facilities
are not provided for the contents of the text or textArea elements.

> - according to the schema, the default value is "false", but the  
> allowed values are "none" and "simple" according to the text.
The schema has been corrected.

>  The  
> text says if the attribute is missing the default value is false:
This has been corrected as well.

> - The spec does not make clear whether editing internally styled text  
> (with <tspan>) is allowed, or if so what happens.
It is allowed, but in SVG Tiny 1.2 with editable="simple" the text is
flattened so the tspans, and any styling that went with them, is lost.

The plan is that another value, like 'rich', will allow rich text
editing in SVG Full 1.2. This is why we changed from a true/false value.

> - The spec does not make clear what happens when you edit text with  
> individual characters absolutely positioned. Is this supposed to work?
It is not clear why this would pose a problem. The layout of the text
due the the attributes on the element  is independent of editing the
text content of the element, which can be done by script and which can
be done declaratively with the editable attribute.

> - The spec does not make clear what happens if the user attempts to  
> enter a line break in a <textArea>. Should the UA enter a space?  
> Beep? Enter a <tbreak> element? Enter an <html:br> element or wrap  
> previous content in an <html:p> (likely behavior for existing editing  
> engines in HTML/XML UAs)? Enter a newline which is not collapsed by  
> the normal collapsing rules?

Entering a line break character will have the same result as if a line
break character were inserted into the text content via script.

> - What happens if the user attempts to enter more than one space in a  
> row, or leading or trailing space, in xml:space="default" mode?

xml:space controls whitespace handling during parsing. It has no effect
on script changes to element content after parsing, and similarly has no
effect here.

> In general, editing seems underspecified. It seems like the intent is  
> to provide plain text editing type features,
right(at least for Tiny)

> but the interaction with  
> the more unusual text styling like absolute positioning is completely  
> unspecified.
As noted above, this is incorrect.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Wednesday, 10 May 2006 12:49:34 UTC