RichTextArea.Formatter wraps modified text/html with copy of parent SPAN (copying all attributes) ??

73 views
Skip to first unread message

TimOnGmail

unread,
Oct 23, 2012, 5:19:08 PM10/23/12
to google-we...@googlegroups.com
Hello there folks...

So we are using an HTML formatting toolbar for a RichTextArea (as described here and elsewhere: http://code.google.com/p/richtexttoolbar/ ), which calls various methods on RichTextArea.Formatter.  For example, toggleBold() (to toggle bolding in a given selected area of text).

This is fine, except I have discovered a problem.  If the underlying HTML in the RichTextArea looks something like this:

<span abc="hello" def="goodbye" style="display: inline-block;">HERE IS MY TEXT</span>

... and the user selects some text in that span (the user cannot see the span, of course, just the text), and "toggleBold()" is called (let's say the word "MY" is selected), then what is rendered in the RichTextArea is:

<span abc="hello" def="goodbye" style="display: inline-block;">HERE IS <span abc="hello" def="goodbye" style="font-weight: bold; display: inline-block;">MY</span> TEXT</span>

As you can see, all the attributes of the surrounding span are copied to the inner span, with CSS bolding adding to the style attribute.  This seems wrong (and causes rendering issues in our case, because it is caopying the "display: inline-block;" styling, which forces a line break.

I would like to know why, instead, toggleBold() doesn't generate this:

<span abc="hello" def="goodbye" style="display: inline-block;">HERE IS <span style="font-weight: bold;">MY</span> TEXT</span>

(i.e. only modify the thing that is being changed in the inserted span)?

This seems to happen deep within browser-specific code (eg. RichTextAreaImplMozilla), so is not easily changeable.

I would call this a bug.  Any opinions on this, anyone?

- Tim

TimOnGmail

unread,
Oct 23, 2012, 5:22:15 PM10/23/12
to google-we...@googlegroups.com
I noticed someone else was having a similar problem as myself, tho' since they didn't have parent spans with attributes to copy, they were more concerned with how styles were being applied in these cases:


In any case, I'm wondering if I should log this as a bug.

- Tim

TimOnGmail

unread,
Oct 23, 2012, 5:47:37 PM10/23/12
to google-we...@googlegroups.com
Another note - in my first post, I incorrectly how the text is modified.  It actually is changed from:

<span abc="hello" def="goodbye" style="display: inline-block;">HERE IS MY TEXT</span>

to:

<span abc="hello" def="goodbye" style="display: inline-block;">HERE IS </span>

<span abc="hello" def="goodbye" style="font-weight: bold; display: inline-block;">MY</span>
<span abc="hello" def="goodbye" style="display: inline-block;"> TEXT</span>

(newlines added for clarity)

So the wrapped text is unwrapped into 3 separate SPANs, which is NOT what I want. I need my HTML formatting preserved, not broken up into separate pieces like that.

Again, seems like a bug.

- Tim
 

TimOnGmail

unread,
Oct 23, 2012, 5:53:43 PM10/23/12
to google-we...@googlegroups.com
Another correction (sorry for all the posts) - I noticed that whether the HTML is broken up into separate SPANs, or whether a span is embedded, is dependent upon specific styles of the surrounding SPAN.  For example, if the outer span has "font-weight: bold" and you are turning off bolding, the text is broken up into separate spans.

But if you call, for example, toggleUnderline() (and the surrounding span does not have underline set), then a span that does not copy the parent attributes is inserted in the parent span, as opposed to breaking up the text into separate spans.

It looks like the Formatter implementation is trying to be clever about how it does its work, but could, in effect, cause issues, since it is modifying the structure of already-structured HTML, and in a way that is not always easily predictable.

- Tim

On Tuesday, October 23, 2012 2:19:08 PM UTC-7, TimOnGmail wrote:
Reply all
Reply to author
Forward
0 new messages