[clipart]See that new SVG-edit icon made by some Opera dude who converted SVG-edit into a standalone widget? Pretty awesome huh? We'll be using that icon in SVG-edit 2.5, Bicorn. Kudos to those browser folk for helping spread the word.

Speaking of SVG-edit 2.5, I had this great idea awhile back to make text editing more awesomer: instead of using svg:text elements, I'd use HTML elements living inside foreignObject inside SVG. That would instantly give you wrapping rich text, bulleted lists, heading styles - because those browsers, they're getting pretty good at displaying plain ol' HTML.

I then had a much cooler idea.

With the contenteditable attribute I could let the user edit her HTML directly in the browser inside SVG-edit just by relying on the browsers which supposedly already support contenteditable.

Over the last couple months it's becoming plain to me that we've reached the current frontier / bleeding edge of interoperable SVG within SVG-edit. Adding features might be harder for a little while. Hey, when things only work in one browser engine, you know that's where you are.

Here's the test case.

Chrome/Safari indeed lets me edit the first list item just fine, but Firefox and Opera do not. 🙁

Firefox "almost" lets me edit it by showing a dashed border around it. Their bug is 549048.

Opera does not even allow me to select the HTML text, for goodness sakes. Kudos given, kudos taken away 😛

Too bad - that would have been really cool.

I might still do that, but I'll have to be clever about it. Maybe when the user clicks on a text element in the editor we'll have to pop up a div at the HTML root instead. Supposedly contenteditable does quite well in HTML-land. Won't quite be the beautiful, seamless experience it could be though.

Unless you have any other bright ideas, chief.

§696 · February 27, 2010 · Uncategorized · · [Print]

11 Comments to “contenteditable hopesdashed”

  1. Jeff says:

    Update: Boris Zbarsky gave me the tip that Firefox requires the document to be of type HTML for the editor to work. While the bug still stands, this information does help me with SVG-edit. This file now works in Firefox.

    Now if someone from Opera would be kind enough to stop by 🙂

  2. Grey says:

    I was going to say “it’s probably better in 10.5” … but actually testing the beta2 build, it actually got worse. For some reason, the second list item doesn’t even appear. Filing a bug may be in order?

    You should probably file one anyway.

  3. Daniel says:

    “You should probably file one anyway.” Most defiantly. The final release is tomorrow.

  4. DSK-284404 has been “defiantly” [sic] raised 🙂

  5. With the contenteditable attribute I could let the user edit her HTML directly in the browser

    Cool, wasn’t aware of this neat feature. 🙂

    Unless you have any other bright ideas, chief.

    Well, maybe not very bright, but here are a couple ideas, not exclusively related to contenteditable but to SVG text editing in general:
    1. Use the standard/draft SVG properties for editing text for browsers which support them, and have a fallback, such as prompt, for other browsers (which works, although a bit uncool);
    2. Use an HMTL+JS widget from one of those cool DHTML libraries which allow editing HTML in a cross-browser fashion (this might somehow bloat the application a bit, though).

  6. The biggest problem I have with SVG text is the lack of wrapping. I’d like to have bulletted lists too.

    I can’t say a prompt would be very acceptable in a WYSIWYG context (no offense)

  7. Bruce says:

    Maybe Microsoft will be the first to implement full text wrapping using arbitrary paths! It would sure jump them to the leader of the pack! This is assuming Doug will blow them away at MIX10 (I have total faith in him)

  8. Chance says:


    I had previously put together some scripts that got text to wrap in SVG since it was not built in. It wasn’t perfect, but calculated the width of the bounding box and text (em) size and this characters per line, etc. But I am really excited to see the foreignobject stuff work. That means form elements, too. I’m sure.

  9. Jeff says:

    Hi Chance,

    Yes, that would be a good second option if we can’t get the HTML-within-foreignObject idea working interoperably. I have created a branch for this work and would appreciate any patches/comments/testing: http://svg-edit.googlecode.com/svn/branches/enhtext/editor/svg-editor.html

    Click on the T+ button to try it out and then start hacking away! 🙂


  10. I can’t say a prompt would be very acceptable in a WYSIWYG context (no offense)

    Actually, the underlying suggestion was to keep using HTML and contenteditable where supported (Fx and WebKit, apparently) and maybe SVG and editable for others (Opera, IE+ASV). 😉

    Naturally, having both behaviors implemented would somehow bloat the whole thing… :-|

    The prompt approach was just a quick+dirty fallback. 😉

  11. Jeff says:

    Helder: Got it, thanks for the clarification.

    Actually with extensions in 2.5 this would be feasible without bloating (i.e. load in the script depending on browser). Of course that means turning the existing Text tool into an extension, but I can’t imagine that would be too hard.