You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

You are here: Editor project page > Selection for the Editor in NGLayout

Selection for the Editor in NGLayout

Project status as of February 4, 1999:

  • Text selection with mouse-drag is basically working.
  • nsRange and associated classes are fairly solid though you should expect to find a few bugs here and there.
  • The basic selection interface is nsIDOMSelection (defined in layout/base/public). This is the class which will be IDL-ified for access by outside users, such as the editor or by Javascript routines. nsIDOMRange is also IDL-ified, and can be accessed from the nsIDOMSelection interface.
  • We are working on hooking up selection extend, using keyboard input and shift-mouse clicks.

This document describes the preliminary engineering spec for implementing selection, as needed by the editor, in the new NGlayout world, and as implemented by the Editor team.

Problem/Requirements

  • Discontiguous selection
  • Table selection (inside tables)
  • Selection across tables (or including tables and non-tables)
  • Need API to be able to start, end, extend, add to current selection
  • Formats exported when the selection is cut/copied to the clipboard -- XIF? Straight html?
  • Platform issues: are there differences in clipboard formats?
    Unix should make the selection available for paste without needing an explicit cut (deficiency in the old Composer), like xterm and most other X apps.
  • What happens if the document changes out from under us while we have a selection?

Solutions

We will probably implement "current selection" with a list of nsIRange objects (see dom/public/coreDOM/nsIDOMRange.h for the source, or see the W3C proposal). [Who will own the current selection?] If the document changes (e.g. by a plugin), clear the selection since we don't know whether the nsIRanges are still valid. [The latest iRange spec says that Ranges must be able to change to reflect changes in the DOM. However, we may not have time to implement this for the first pass of Selection code.]

Format advertised to the clipboard will probably be html at least initially, with an option for offering XIF later if there is extra-html information which could be usefully pasted.

Risks

May not be enough time to implement selection early enough. It must be written fairly early in the process; if it's subject to a lot of last-minute hacks, it's even more at risk than other areas of becoming a shoddy mass of unmaintainable code.

Dependencies

Range needs to be fairly solid before much progress can be made on selection. This means that we'll probably have to write at least the first pass of the Range code.

We are also dependent on the front end and layout code responsible for mapping mouse or cursor position to DOM Node.

Black Holes

None known.

akkana@netscape.com