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
nsIDOMRangeis also IDL-ified, and can be accessed from the
- 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.
- 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?
We will probably implement "current selection" with a list of nsIRange
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
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.
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.
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.