The Mozilla
Organization
Our Mission
Who We Are
Getting Involved
Community
Editorials
What's New
Newsbot
Development
Roadmap
Module Owners
Blue Sky
Projects
Status
Tools
Products
Source Code
Binaries
Documentation
License Terms
Bug Reports
Quality
Search
Feedback


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.

Tue Dec 8 1998
akkana@netscape.com

Copyright © 1998 The Mozilla Organization.