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

Hi, Maciej-

Maciej Stachowiak wrote:
| 
| >> - 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.
| 
| Upon further reading, I found this requirement in section 10.13,  
| "Text selection and clipboard operations". I recommend that it be  
| moved to a section that relates to editing, such as 10.12, "10.12  
| Editable Text Fields".

Chris has addressed this.


| > 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.
| 
| As discussed in followup with Doug Scheppers, it could lead 
| to a very  
| weird UI, where pressing right arrow could move the caret left, or  
| pressing down arrow could move the caret up. It is also not obvious  
| whether the caret should blink after the character before it, or  
| before the character after it, if these would be totally different  
| screen positions (usually such considerations apply only at 
| soft line  
| breaks). This is why I was not sure whether this was intended to be  
| allowed.

It may seem odd, but it actually expresses author intent. For bidi text, for
example, the directionality of movement may seem unintuitive from the
perspective of one used to text with a single orientation. There may be
discontiguous characters or words, or the text might be rotated in any
orientation, or any number of other unique layouts, which would be
impractical to characterize individually.

If the author specifies an unorthodox layout for editable text, that is what
should decide the navigation of the UI. The UA doesn't need to do any
special tricks to handle it, it just follows the directionality and layout
provided by the author and indicated by the language and font. The carat
should simply be positioned and oriented according to the characteristics of
the character it is addressing.


| >> - 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.
| 
| 1) The spec does not appear to say what a textArea element should do  
| if the text content contains a newline.  Section 10.10 "Whitespace"  
| doesn't say, because it says xml:preserve applies only to the 'text'  
| element, not 'textArea'. Section 10.11 "Text in an area" does not  
| mention newlines at all. I am not satisfied with saying one behavior  
| not defined by the spec should be just like another not defined by  
| the spec.

You're right, so I have changed the whitespace handling to include 'text',
'tspan', and 'textArea' elements.


| 2) Please also consider this as an additional comment: "How should  
| newlines that appear in a 'textArea' element be rendered?"

Newline characters in the content are rendered as spaces, which may be
collapsed if appropriate.  But see the next answer.


| 3) If the intent is that newline is always rendered like space in  
| textArea elements, the interpretation you give above would result in  
| the apparent implied requirement that entering a line break actually  
| has the practical effect of entering a space. This is insane user  
| interface and not acceptable to me as a requirement.
 
We were compelled by your insanity plea, and decided to allow 'tBreak'
elements to be inserted into the 'textArea' via user interaction. Unlike
'tspan's, which introduce a bunch of messy questions when boundaries are
crossed, 'tBreak's are simple to deal with (they are either there or they
aren't) and are therefore appropriate to be part of editable="simple". We
have also changed the 'tBreak' such that successive 'tBreak's each create a
line break, so you can stack them. 

This does mean that it's no longer strictly a matter of collapsing the
structure of the 'textArea''s child nodes (as per textContent), but it will
get rid of 'tspan's, extracting and inserting a simplified structure that
includes only text and 'tBreak's. However, we agreed that this extra bit of
complexity would meet the minimum expectations of behavior for authors and
(sane) users. 

Just how (or if) the implementation allows the user to enter these 'tBreak's
is up to what the implementation deems appropriate for the
platform/device/OS. It would often be reasonable to insert a 'tbreak'
element whenever a user hits the 'enter' key, for example.


| >> - 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.
| 
| As others have pointed out, this claim appears to be contrary to the  
| specification. Section 10.10 "Whitespace" says, regarding xml:space  
| processing, "These are behaviors that occur subsequent to XML 
| parsing [XML11] and do not affect the contents of the Document Object 
| Model."  
| Since this response is founded on an incorrect assumption, I am not  
| satisfied with it.

There are 2 orthogonal phases to how xml:space affects the document and its
presentation. 

First, the XML is parsed, and if xml:space="default", then white space may
be collapsed, removing extraneous spaces from the DOM representation of the
text content {1}; if xml:space="preserve", then all white spaces are
represented in the DOM. Note that UAs are not *required* to remove white
spaces. This step is dictated by the XML spec.

Second, when the UA renders the text, it renders or collapses any extraneous
white spaces in the DOM, again depending on the value of xml:space, but in a
different way. White spaces are not removed from the DOM if
xml:space="default", they are simply collapsed per the white space handling
rules in the "White space handling" section. If at some point after the
initial parsing and presentation, the value of xml:space is changed for that
element (e.g. via script), then the rendering of the text may be affected;
if white spaces were removed in phase one (parsing), then there is nothing
left to expand or collapse, so it would not be altered. If the initial value
was "preserve" and it is subsequently set to "default", then white spaces
will be collapsed and the rendering will alter (assuming there are
extraneous white spaces).

The statement, "These are behaviors that occur subsequent to XML parsing
[XML11] and do not affect the contents of the Document Object Model (DOM)
[DOM3]" refers to the second step. 

I'm not convinced this is the most elegant way to handle this (in fact, I
personally dislike it), but it is consistent, correct, and implementable.

{1} "The value 'default' signals that applications' default white-space
processing modes are acceptable for this element",
http://www.w3.org/TR/REC-xml/#sec-white-space



| >> 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.
| 
| Your comment doesn't seem to explain the interaction. It covers  
| modifying the text content (same for script and UI editability) but  
| does not cover such things as how caret navigation should work, how  
| selection should work, how inline text input methods that hold  
| temporary marked text containing multiple characters should work,  
| etc. None of this UI interaction applies to modifying text contents  
| by script.

We do not believe that the spec should mandate this level of detail.
Instead, implementation-specific behaviors should operate in a manner
consistent with the user platform and the text characteristics (bidi, etc.),
whatever that behavior might be.

Selection is orthogonal to the UI. Selection is started at one point in the
DOM node content, and extends to another point in the node content,
regardless of how it is represented on screen. Different platforms will have
users who expect a certain behavior, depending on the abilities of the
device.


If this does not satisfy your concerns, please respond within 2 weeks with
further clarification.

Thanks-
Doug, on behalf of the SVG WG

Received on Wednesday, 28 June 2006 06:04:26 UTC