- From: Chris Lilley <chris@w3.org>
- Date: Wed, 10 May 2006 14:49:28 +0200
- To: www-svg@w3.org
- Cc: Maciej Stachowiak <mjs@apple.com>
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