Trying to make "span" tag read-only in tinyMCE text editor in Firefox

[Boris Golman]

Hello everybody. I have a rather peculiar issue with the way <span> tag is handled in Firefox. I currently have a Richfaces component <rich:editor>, which is a tinyMCE object and HTML is what's expected to be its content. But what I usually have there is a simple text, mixed with what I call "placeholders". These "placeholders" are read-only <span> objects that the user cannot change, he can only delete them (and only with one click of a backspace or a delete key). So, in the end, that's what the sample might look like:

This is the text that contains info about a certain person, <span contenteditable="false" style="color: grey; font-weight: bold; class="placeholder ui-draggable" unselectable="ON"> [Person Name]</span>, and will be updated further down the road.

In IE it works fine, but when it comes to Firefox - the <span> object becomes editable and selectable, which kind of defeats the purpose of having it there. I was able to make it at least non-selectable, using "-moz-user-select:none;" style attribute, but the user can still edit it (like partially delete it, using backspace key) and it still doesn't work on Safari. It almost seems like <span> attributes "contenteditable" and "unselectable" don't even work on non-IE browsers.

Does anyone have any idea on how to fix that? I'm gradually running out of ideas.

Thanks in advance

[Greg Charles]

Hi Boris,

As you probably already know, HTML text isn't generally editable whether it's inside a span tag or not. What must be happening is that the rich:editor tag renders into a combination of HTML and JavaScript to make a simple editor panel, and somehow it isn't applying the JavaScript correctly for Firefox. I'll add this thread our JSF forum and hopefully someone there will have experience with the rich:editor tag.

[Tim Holloway]

If I am not mistaken, the editable area of a tinyMCE control is an HTML TEXTAREA tag. Anything within a TEXTAREA is supposed to be editable, so that actually sounds like a bug in IE. Shocking, I know.

[Boris Golman]

Tim Holloway wrote:If I am not mistaken, the editable area of a tinyMCE control is an HTML TEXTAREA tag. Anything within a TEXTAREA is supposed to be editable, so that actually sounds like a bug in IE. Shocking, I know.

In IE it works fine, actually. Same goes for Chrome. Adding -moz-user-selectable and -webkit-user-selectable for Firefox and Safari (respectively), makes span uneditable in Safari (but it looses the cursor) and only partially editable in Firefox (you can place cursor at the end of the span and change it, using backspace key).

[Tim Holloway]

While I didn't do a completely exhaustive analysis, I did do a quick rundown on the official HTML4 DTD and schema and as far as I can see, TEXTAREA is not permitted to have child elements - neither display elements nor items such as DIV and SPAN elements.

JSF2 is HTML4-compliant, so even assuming HTML5 supported child elements, the output of the JSF2 renderer would not be valid with span tags in it no matter how many browsers let it slip by.

[Greg Charles]

Well, I may have an answer. As Tim points out, the rich:editor does seems to maintain a hidden textarea for the contents of the edit window in the same way something like OpenOffice is maintaining an XML version of the document being edited. The user doesn't directly work with it though. The actual display of the document is done with an iframe, with its body tag set to contenteditable="true". I believe that is an HTML 5 tag, but it is pretty widely supported in today's browsers.

I tried it out in Firefox, and it seem to work OK for me. There is a known bug in IE8 that forces you to set contenteditable to true if you want the span to be uneditable (that is, exactly the opposite of what it should be), but I couldn't find any reported issues with Firefox. Boris maybe you could post a small example of your rich:editor?

[Boris Golman]

Here's what my rich:editor looks like (someBean.someHTMLData is, of course, the HTML content that contains span objects I want to make read-only):

<rich:editor theme="advanced" plugins="fullscreen" value="#{someBean.someHTMLData}" 
     id="someID" autoResize="true" width="250" height="100" required="false">
     <f:param name="theme_advanced_buttons1" value="undo,redo,removeformat,|,formatselect,styleselect,bold,italic,underline,
strikethrough,|,justifyleft,justifycenter,justifyright,justifyfull,|,bullist,numlist,insertdate,inserttime,hr,outdent,indent," />
     <f:param name="theme_advanced_buttons2" value="" />
     <f:param name="theme_advanced_buttons3" value="" />
     <f:param name="theme_advanced_toolbar_location" value="top" />
     <f:param name="theme_advanced_toolbar_align" value="left" />
</rich:editor>

Is there something I need to set there? I thought about it, but I was afraid it's going to affect the whole content, not just the span objects (and only span objects that I need).

[Boris Golman]

Greg Charles wrote:Well, I may have an answer. As Tim points out, the rich:editor does seems to maintain a hidden textarea for the contents of the edit window in the same way something like OpenOffice is maintaining an XML version of the document being edited. The user doesn't directly work with it though. The actual display of the document is done with an iframe, with its body tag set to contenteditable="true". I believe that is an HTML 5 tag, but it is pretty widely supported in today's browsers.

I tried it out in Firefox, and it seem to work OK for me. There is a known bug in IE8 that forces you to set contenteditable to true if you want the span to be uneditable (that is, exactly the opposite of what it should be), but I couldn't find any reported issues with Firefox. Boris maybe you could post a small example of your rich:editor?

Apparently, setting iframe's "contenteditable" attribute to anything doesn't fix the problem. You can still edit the content of a span object by simply placing the cursor anywhere (basically, just like any text). The idea was to treat those span objects as components, which the user can only add or delete, but not actually change.

[Tim Holloway]

I'm afraid the sad truth is that HTML is too stupid to be able to do stuff like this. HTML isn't even as smart as the basic UI toolkit for most IDEs, and even HTML5 (which isn't an option here) isn't much better. Consider, for example, that there's no HTML ComboBox control.

A functional solution would probably have to be one of the following:

1. Use a Java applet. Normally I'd go with this, but considering all the security issues with client-side Java lately, it gives one pause.

2. Do it as a Flash plugin. Same issues as #1. Plus Flash. Yuck. Plus Apple mobile devices (among other platforms) refuse to support Flash.

3. Do it in JavaScript. You're a braver person than me. You probably won't be able to leverage tinyMCE, since what you really need is the ability to break the control text into segments, with each segment having the appropriate attributes. I think tinyMCE just lets HTML tags handle that, with results that you've already seen.

No easy solution, alas.

[Boris Golman]

Tim Holloway wrote:I'm afraid the sad truth is that HTML is too stupid to be able to do stuff like this. HTML isn't even as smart as the basic UI toolkit for most IDEs, and even HTML5 (which isn't an option here) isn't much better. Consider, for example, that there's no HTML ComboBox control.

A functional solution would probably have to be one of the following:

1. Use a Java applet. Normally I'd go with this, but considering all the security issues with client-side Java lately, it gives one pause.

2. Do it as a Flash plugin. Same issues as #1. Plus Flash. Yuck. Plus Apple mobile devices (among other platforms) refuse to support Flash.

3. Do it in JavaScript. You're a braver person than me. You probably won't be able to leverage tinyMCE, since what you really need is the ability to break the control text into segments, with each segment having the appropriate attributes. I think tinyMCE just lets HTML tags handle that, with results that you've already seen.

No easy solution, alas.

So, the way I understood you:

1) IE 8 is using HTML 4, which, I guess somehow, for some bizarre reason still allowed me to have read-only span object in my tinyMCE editor. Does the same go for Chrome? 'Cause it works there too. And, apparently, Firefox and Safari already use HTML 5, which makes every text (within a span or a div) editable. Right? And thus, I'm lucky it works even for IE and Chrome AND it probably won't work in newer versions?

2) Javascript... last night I was seriously considering it. Ideally, it would be a hacking, but still... first, I'll need to be able to detect where in the editor I clicked to edit and where my cursor is. If it's on the span object, it immediately moves the cursor to the end of the span object. And, of course, delete function needs to be altered: when I attempt to delete a span object, it somehow wouldn't allow me to do so one character at a time, only the whole thing. Same goes for backspace. Thought that might do the trick, preventing the user from altering the actual text id the span object and make it look like we're dealing with a read-only component. Sounds rather complicated, I'm afraid, but more or less doable, do you think? Unless you can see some pitfalls I've missed.

Other than that, as always, I appreciate the time you took to help me.

[Tim Holloway]

As I mentioned earlier, what I read of the HTML DTD/Schema did not indicate the possibility of ANYTHING being a child element of a TEXTAREA except for straight content. Presumably allowing PI's and comments, since they're meta-information, but admittedly, a DOM tree would still consider them as sub-elements.

What you are observing, therefore cannot be considered as a property of HTML 4, just of certain implementations of HTML4 rendering and DOM manipulation, just as you can often upload a file into a WAR directory, even though that would be physically impossible in a strict implementation of J2EE. In short, it might work some places and some times, but no guarantee for all places and all times and failures can be unpredictable both in when they occur and in how severe the damage will be. Other than Murphy's Law, which says that the more critical the need, the more likely it will fail in some spectacularly horrible way.

You can see a working model of a segmented text editor in the Spring rich text control. Which is why an applet would be my normal first choice. Most of it is already working. But with applets being routinely disabled for security reasons, it's no longer a truly viable solution.