Status

Feature tracking bug

• bug 237964

Has a design review been completed?

There has not been a formal design review.

When do you anticipate the feature landing

Landed in June 2007 (Firefox 3 Alpha 6).

Overview

Allow webcontent to make regions of a webpage editable.

Use Cases

Requirements

• Make HTML elements editable through setting a contenteditable HTML attribute or JS property.
• Non-editable regions must not be editable, not spellchecked, ...

UI Design Documentation

use cases and expected user knowledge (terminology, metaphors, etc)

design mockups (of whatever fidelity is easiest)

links to relevant user data, bugs, reports, examples, etc

Design Impact

Security and Privacy

• What security issues do you address in your project?
• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

No

• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
  • Assumptions
  • Capabilities
  • Potential Risks

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
  • APIs
    • exported to the web: contenteditable HTML attribute and JS property on HTMLElement
  • UI

None.

• Does it interoperate with a web service? How will it do so?

• Explain the significant file formats, names, syntax, and semantics.

• Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

• Does it change any existing interfaces?

Yes. nsINode/nsIContent/nsISelectionPrivate/nsIHTMLDocument/nsIDOMNSHTMLElement/nsIEditingSession/nsIEditor/nsIPlaintextEditor

Web Compatibility

• Does the feature have any impact on Web compatibility?

Yes, improves it since contenteditable is already implemented in other browsers (IE/Safari/Opera/...).

Performance

• How will the project contribute (positively or negatively) to "perceived performance"?

• What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?

None.

• Will it require large files/databases (for example, browsing history)?

No.

Reliability

• What failure modes or decision points are presented to the user?

• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

l10n and a11y

• are any strings being changed or added?

No.

• are all UI elements available through accessibility technologies?

Installation, Upgrade/Downgrade/Sidegrade, and platform requirements

• Does it equally support all Tier-1 platforms?

Yes.

• Does it have a hardware requirement (or increase minimum requirements)?

No.

• Does it require changes to the installer?

No.

• Does it impact updates?

No.

• list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)

N/A.

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

No.

• Are there build options for developers? [#ifdefs, ac_add_options, etc.]

No.

• What ranges for the tunable are appropriate? How are they determined?

• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Relationships to other projects - are there related projects in the community?

• If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?

• Are you updating, copying or changing functional areas maintained by other groups?

No.

Documentation

• Do built-in Help pages need modified?

No.

• Documentation for developer.mozilla.org?

Other

Discussion & Implications

Caveats / What We've Tried Before

References

WhatWG Web Applications spec