Re: [whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
On Thu, Jun 2, 2011 at 8:07 PM, Tim Down wrote: > My version passes an array of ranges to be preserved to the command's > various internal methods. Works with multiple selected ranges in > Firefox. I've considered doing that too. But it doesn't work with Range objects you don't have a reference to, so it's not the same as what the browser can do. (Although I'm not sure if browsers actually do anything special for ranges not in the selection, for execCommand(). I haven't tested, but I suspect not.)
Re: [whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
On 31 May 2011 18:39, Aryeh Gregor wrote: > On Tue, May 31, 2011 at 4:15 AM, Markus Ernst wrote: >> Anyway, everything we need is actually available in the DOM, except a >> standardized and simple handling of selections and ranges. (Well, I might be >> wrong - but looking at the Gecko DOM reference and the MSDN DHTML reference, >> they show very different approaches to the range and selection objects, and >> the code of TinyMCE shows lots of browser sniffing.) > > That's because browsers' implementations don't follow the specs, or in > some cases because there weren't specs until the last few months, not > because there's anything wrong with the spec. I've implemented all my > algorithms in pure JavaScript, and there are almost no places where I > have to work around browser bugs -- given that I only target the > latest versions of IE/Firefox/Chrome/Opera. implementation.js is over > 4000 lines, and I estimate I've needed maybe ten browser-specific > workarounds, certainly under twenty. (If you want to support IE<9, of > course, have fun . . .) I'm working on this. There was a perverse pleasure in getting to a workable version of the Range and Selection APIs in IE < 9, and the commands stuff I've recently built on top based on (a slightly outdated version of) Aryeh's code has required relatively little browser-specific code to get bold and italic working. Very rough demo here (works in IE 6 - 8 as well as sensible browsers): http://rangy.googlecode.com/svn/branches/1point2/demos/commands.html. > The only major thing that can't be done in JS is change how ranges > behave when you mutate the DOM. Effectively, I work around it by > using a single Range object to represent the user's selection, and I > only care how that changes. This might actually be the way I'll end > up speccing it too, although it'd be nice if we could preserve ranges > outside the selection too. My version passes an array of ranges to be preserved to the command's various internal methods. Works with multiple selected ranges in Firefox. Tim
Re: [whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
On Tue, May 31, 2011 at 4:15 AM, Markus Ernst wrote: > While following the discussions about Aryeh Gregor's great work on > execCommand(), I get the impression that this method is very limited to some > basic formatting actions. It provides shortcuts for a limited set of DOM > actions, but is not really extendable or generalizable. > > Some of the discussions were about adding support for new elements, such as > and , or for distinctive and resp. and > elements. I doubt that extending execCommand() with specific new > commands for more elements would be the direction to go. > > With the focus on HTML editing rather than WYSIWYG editing, some kind of > generalized wrapping/unwrapping mechanism would be helpful. This could be > handled with a new method that offers shortcuts for wrapping/unwrapping > selections; some kind of addWrapper(elementName) and > removeWrapper(elementName). I do have a wrapping algorithm in the current spec: http://aryeh.name/spec/editcommands/editcommands.html#wrap There are a whole bunch of others you can find in the spec too, some of which Tim Down mentions. Once everything looks stable and the kinks are worked out, I'm definitely going to think about exposing some of the primitives my spec relies on to authors as new methods someplace. However, I'd prefer to wait until we have actual implementations that confirm that these primitives are the right way to do things for execCommand(). I don't want to say we should expose an algorithm when it turns out that the algorithm doesn't make sense and needs to be split in pieces or something. > Anyway, everything we need is actually available in the DOM, except a > standardized and simple handling of selections and ranges. (Well, I might be > wrong - but looking at the Gecko DOM reference and the MSDN DHTML reference, > they show very different approaches to the range and selection objects, and > the code of TinyMCE shows lots of browser sniffing.) That's because browsers' implementations don't follow the specs, or in some cases because there weren't specs until the last few months, not because there's anything wrong with the spec. I've implemented all my algorithms in pure JavaScript, and there are almost no places where I have to work around browser bugs -- given that I only target the latest versions of IE/Firefox/Chrome/Opera. implementation.js is over 4000 lines, and I estimate I've needed maybe ten browser-specific workarounds, certainly under twenty. (If you want to support IE<9, of course, have fun . . .) The only major thing that can't be done in JS is change how ranges behave when you mutate the DOM. Effectively, I work around it by using a single Range object to represent the user's selection, and I only care how that changes. This might actually be the way I'll end up speccing it too, although it'd be nice if we could preserve ranges outside the selection too.
Re: [whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
On 31 May 2011 09:15, Markus Ernst wrote: > While following the discussions about Aryeh Gregor's great work on > execCommand(), I get the impression that this method is very limited to some > basic formatting actions. It provides shortcuts for a limited set of DOM > actions, but is not really extendable or generalizable. > > Some of the discussions were about adding support for new elements, such as > and , or for distinctive and resp. and > elements. I doubt that extending execCommand() with specific new > commands for more elements would be the direction to go. > > With the focus on HTML editing rather than WYSIWYG editing, some kind of > generalized wrapping/unwrapping mechanism would be helpful. This could be > handled with a new method that offers shortcuts for wrapping/unwrapping > selections; some kind of addWrapper(elementName) and > removeWrapper(elementName). > > Anyway, everything we need is actually available in the DOM, except a > standardized and simple handling of selections and ranges. (Well, I might be > wrong - but looking at the Gecko DOM reference and the MSDN DHTML reference, > they show very different approaches to the range and selection objects, and > the code of TinyMCE shows lots of browser sniffing.) I'd find it very > helpful as an addition to Aryeh's work, to get standardized methods for > actions like: > - creating a range out of a selection > - block-extending the range > - accessing all child elements of the range > - accessing all parent elements of the range > - memorizing start and end points in order to reset the selection after > modifications > (This list may not be complete.) > > I'd be happy about some thoughts on this. > > -- > Markus Aryeh's own example implementation script accompanying the execCommand spec has several of these (block-extending a range, decomposing a range and performing DOM manipulation while preserving ranges, for example). See http://aryeh.name/spec/editcommands/implementation.js Tim
[whatwg] Generalized execCommand() alternatives, or standardized selection and range handling
While following the discussions about Aryeh Gregor's great work on execCommand(), I get the impression that this method is very limited to some basic formatting actions. It provides shortcuts for a limited set of DOM actions, but is not really extendable or generalizable. Some of the discussions were about adding support for new elements, such as and , or for distinctive and resp. and elements. I doubt that extending execCommand() with specific new commands for more elements would be the direction to go. With the focus on HTML editing rather than WYSIWYG editing, some kind of generalized wrapping/unwrapping mechanism would be helpful. This could be handled with a new method that offers shortcuts for wrapping/unwrapping selections; some kind of addWrapper(elementName) and removeWrapper(elementName). Anyway, everything we need is actually available in the DOM, except a standardized and simple handling of selections and ranges. (Well, I might be wrong - but looking at the Gecko DOM reference and the MSDN DHTML reference, they show very different approaches to the range and selection objects, and the code of TinyMCE shows lots of browser sniffing.) I'd find it very helpful as an addition to Aryeh's work, to get standardized methods for actions like: - creating a range out of a selection - block-extending the range - accessing all child elements of the range - accessing all parent elements of the range - memorizing start and end points in order to reset the selection after modifications (This list may not be complete.) I'd be happy about some thoughts on this. -- Markus
