Feature | Status | ETA | Owner |
Code Editor | next stages of evaluation | 2011-05-23 | Kevin Dangoor |
Summary
New developer tools features will provide opportunities for users to work directly with their code from within the browser. We would like for our tools to provide an editing interface that is more suited to editing code than a plain textarea or an HTML WYSIWYG interface.
Features that will take advantage of this editor: Scratchpad, CSS Editor, devtools-oriented View Source.
Team
- Feature Manager: Kevin Dangoor (irc: kdangoor)
- Devtools Developer: Mihai Sucan (irc: msucan)
- Built-in Editor Owner: Ehsan Akhgari (irc: ehsan)
Release Requirements
Because there are "off the shelf" choices for this feature and to help guide discussion of the feature, I am listing the requirements as a table showing which of the choices currently offer each requirement. If a requirement is not presently met by a choice, that does not necessarily eliminate the choice from consideration. That just means that additional work will be required to make that choices a suitable one.
In the table below, "Built-in" refers to the editor that is already built in to Gecko.
Requirement | Built-in | Ace | Orion |
License | Tri | Tri | BSD |
Syntax Highlighting (HTML, JS, CSS) | No | Yes | TBD |
Gutter with line numbers | No | Yes | Yes |
Can set/display breakpoints | No | Yes | Yes |
Robust international character support | Yes | No | Yes |
RTL support | Yes | No | TBD |
Accessible | Yes | No | TBD |
Responsive editing, even for large files (20,000 lines) | TBD | Yes | Yes |
Footnotes:
Desirable qualities, but not required initially:
Feature | Built-in | Ace | Orion |
Code-oriented indentation(1) | No | Yes | Yes |
Bracket/brace matching | No | Yes | Yes |
Highlight current line | No | Yes | Yes |
Highlight occurrences of word/symbol | No | Yes | No |
Code folding | No | Yes(2) | No |
Autocompletion | No | No | TBD |
JavaScript syntax checking | No | Yes | No |
Reconfigurable keybindings (vi/emacs possible) | No | Yes | No |
Footnotes:
- code oriented indentation means maintaining the indentation level from the previous line and ideally indenting automatically when a new block is started
- "Unstructured" or "user" folding was just contributed during the week of April 25th
Note: CodeMirror 2 was also considered in the initial round. However, it appeared to have the same i18n and a10y downsides as Ace while lacking other desirable features.
Evaluating the Options
You can read the background section for further information leading up to our current evaluation status.
The short form of where we stand now:
- The built-in editor (contentEditable) must be a part of the solution, because it appears to be the only viable way to handle i18n and a10y needs sufficiently well
- A lot of work (not quantified, but you can get an idea looking at the list above) would be required to make the built-in editor a good code editor
- Ace has a good collection of features, but does not use contentEditable and therefore falls short in a10y and i18n
- Orion has a good start on features (though fewer than Ace), but is closer to our requirements for a10y and i18n
From a time-to-market perspective, Orion looks like the best choice. The only work we'd need to do to get started using it is:
- work through differences between running in content and chrome
- ensure that our integrated editor is sufficiently accessible
Over time, Orion would doubtless gain other features from our wishlist. It is an active Eclipse project. However, the Orion project is trying to do quite a bit and their editor component is only a slice of that. Features like code folding, word wrap and Ace's flexible key bindings are non-trivial.
The other option would be to incorporate Orion's editing/rendering model into Ace. That requires some amount of up-front work, but gives us a lot of features right away.
Therefore, the first step is to evaluate just how much work is likely required to merge the Orion input/rendering with the rest of Ace.
Next Steps & Open Issues
- Solicit additional feedback for the plan on dev.platform (though this really belongs on dev-apps-firefox)
- Proceed with the evaluation
- Verify performance, i18n and a10y characteristics of proposed choice
- Security review of proposed choice
Background
In the dev.platform newsgroup, there were two threads with significant discussion about code editing approaches (1, 2). There was a followup meeting on May 9th in which we (devtools, a10y, Ehsan) discussed the options a bit further and the questions surrounding those options.
We came out of that meeting with some observations:
- contentEditable is the only sane way to do text input, due to both a10y and i18n considerations
- we may not need to use the editor for file viewing at stage 1
- IBM claims that Orion is not fully accessible. dbolter has asked where it falls short.
- Orion does some accessibility events okay: caret changes and text changes. Does not appear to work with screenreaders yet.
- RTL works fine in Orion
- While it may seem like syntax highlighting is a purely visual thing, the metadata for highlighting may be valuable for providing functions like jump-between-methods.
- CodeMirror appears to have the same problems that Ace does, though without some of the features we want
- code-oriented indentation is not a requirement for version 1, but tab key support is
- We should consider the communities around Ace and Orion and how likely it is we can get what we need while working with those communities (FWIW, a10y is important in general to IBM and the Eclipse project)
- Single long lines is a performance case we should consider, since minified files make this case more likely on the web in general than in normal day-to-day editing
- Web Inspector appears to use a simple editor that is built into the webkit tree
We also had a couple of questions:
- What are the requirements for accessibility? (dbolter to followup)
- What are the performance characteristics of the various choices for our use cases?
1: Use of 3rd party projects
2: In-browser code editor
Using the User's Editor
The Firefox Add-on "It's All Text!" allows users to launch their editor of choice to edit the contents of any textarea. The external editor is launched with a temporary file and that file is reloaded into the textarea when the user returns to the browser. (I don't know if and when those files are cleaned up.)
The positive aspect of this approach is that the user can use the editor that they're already comfortable with and for which they've developed muscle memory. The downside is that there's no real integration between the developer tools and the editor. You can't, for example, set a breakpoint from within the editor or see CSS changes instantly in the browser.
A hybrid approach where editor plugins connect via a remote debugging protocol to the browser is possible, but would require considerable effort to create and maintain support for each editor. Even with that effort, it will be nearly impossible to provide the same level of integration with the developer tools even for a single editor.
Related Bugs & Dependencies
TBD