![]() Requires special handling for selections crossing block nodes due to HTML containment rules. The third part, manipulation, works mainly by inserting a DOM node in front of the startContainer, extracting the selection, and then sticking it in the DOM node. They all happen in different permutations in different browsers depending on how the user selects text (start to end, end to start, double click, triple click, etc). In the real world, whitespace nodes in the DOM create an additional 4+ equivalent points that are identical. It's actually possible for any permutation of the start and end points in the illustration to be what your users would consider an identical range. Ranges 2-4 in the illustration are, in terms of both visual appearance and text selected, equal but they do not compare as equal. Next, determining equality of ranges–which is useful for figuring out when one range is in another so you can, say, invert the range–is tricky. toString(), you can extract or clone the nodes so you can mess with them in a doc fragment but you can't get at the live nodes in the DOM. You can't actually get the selected DOM nodes. ![]() This is the best part of the API.įor the second. This representation, naturally, does not persist when you're doing DOM manipulation. You only want so many things from a Range api: the ability to select text, the ability to determine what's selected, and the ability to manipulate the selection.įor the first, you can do it but the offsets are dependent on node and offset which can be a text or child node offset and you must check the node type to distinguish between the two. The DOM 2 Range API which is far and away the worst API I've ever used in my life. If you don't go with simple markup and regexps for the fixup or you want to provide capabilities beyond what's available in the execCommand then you need to deal with the Range API. So that's why you want to start messing with the browser provided behavior. Browsers also tend to toss in random tags and style attributes. Then there's the app-specific logic like what parts of pasted text you want to keep and what to pitch and what you want the markup to look like. There's also behavior that you expect in an editor that isn't the default in markup like leaving empty paragraphs when you hit enter. Text editing works on text ranges while DOM manipulation works on trees. It's necessary because there's a impedance mismatch between editing rich text and generating markup. > astonishment that such a thing is even necessary The amount of code is relatively small (mine is around 2k sloc) but it's all really ugly code that reminds me of the bad old days in 2002-2004 when I had my own DOM abstraction lib. Of the editors I know about only Aloha and my editor take this approach. Using contenteditable would be the preferred technique but it's buggy as hell. CMD+left/right in OS X don't work in gmail). Downside is that doing it is a lot of code and it's easy to miss OS specific keybinds (e.g. This is especially good for things like docs where they need to emulate word's behavior. ![]() You type into a hidden text field and the display/selection/cursor is entirely script rendered. Google uses full emulation in their products. The other two techniques are full emulation and contenteditable. This is the cleanest solution for the most common use case of html email/html item entry. If you insist on OSS, WYSIHTML5 is the best available.įor those that care, Redactor uses the designMode technique, leans on the browser for most operations and keeps the markup clean via regexp cleanup. Redactor came out this spring and is the only generally available RTE that does this. I wrote a proprietary RTE last year and continue to maintain it because nothing available both worked and produced clean markup. ![]() ![]() If you're looking for a Rich Text Editor, this is the only one I will recommend. ![]()
0 Comments
Leave a Reply. |