|HTML Tree Editor|
|Release target||Firefox 17|
|Product manager||Kevin Dangoor|
|Directly Responsible Individual||Dave Camp|
|Lead engineer||Dave Camp|
|QA lead||Mihaela Velimiroviciu (irc: MihaelaV)|
|Product marketing lead||`|
Stage 1: Definition
1. Feature overview
Firefox 10 added the Page Inspector feature with an HTML panel to view and navigate the HTML. The HTML panel provided is useful for navigation but not much else.
In competing tools, developers use the HTML panel to manipulate the DOM, especially when working on styling.
2. Users & use cases
Be able to:
- add or remove a class (adding the class attribute if there isn't one)
- bug 705323 change text
- add/edit other attributes
- edit tag name
Optional for the first round (but made it in as part of an earlier feature)):
- bug 705847 copy innerHTML/outerHTML for an element
- be able to remove nodes
these were not done in the first release:
- be able to add nodes
- be able to move nodes
- bug 703383 ability to get a CSS selector for an element
- handle elements like script and link appropriately
- style tag editing in-place
- validation of attributes
- focus on an element
Stage 2: Design
5. Functional specification
The following features are ones that we've identified as being the most important for users.
Add/Remove a Class
Users must have a way to add and remove classes from elements, even elements that do not already have a class attribute.
Users working on site designs often want to see how an element reacts when it contains text of different sizes. In order to do this, they must be able to replace the text content of the element with new text.
Add/Edit Other Attributes
These features will improve developer's lives, but it's more important to get the "Requirements" above out the door in a timely manner. We can add these features later.
We start with features that are used by designers for changing their DOM to match the styling work they're doing.
Sometimes people need to change the tag as part of their editing in support of styling.
There are some users that like to be able to eliminate page elements as a sort of manual adblock. More generally, though, the ability to remove nodes is in support of getting the DOM structure to look right for styling experimentation.
Similar to the remove node case, when trying to get the styling correct a user may need to add new nodes to their structure.
Other tools (Firebug and Chrome) give users the ability to go into freeform editing of outerHTML, rather than the ability to add nodes. This is likely one acceptable solution for the styling case (though it would do potentially weird things like blow away event handlers and random data attached to nodes).
Chrome allows users to move an element around via drag and drop. Like the other cases above, this is handy for tweaking the structure to match styling changes in progress.
CSS Selector for Element
Stylesheet Link Tags
Allowing the user to jump from a stylesheet link tag over to the Style Editor is a quick shortcut for a user when they're already looking at their HTML view.
Similarly, when the debugger is in place, being able to jump from a script tag to the debugger view for that script would be useful.
If a user wants to edit the contents of a style tag, the ideal UI would be to drop in an in-place Style Editor so that the user could edit the CSS with all of the goodies provided by the Style Editor.
Validation of Attributes
If a user is working with an HTML doctype, we could validate the attributes and warn them about unknown attributes (possibly suggesting that data- attributes are the preferred way to do custom attributes today).
Given knowledge about which attributes go with which tags, we could provide autocompletion for attribute names. Tag names could also be autocompleted. For certain attributes, there is a set of common values (rel on the link tag, for example) that we could complete for the user.
Focus on an Element
In a deeply nested DOM, the use of screen real estate may be less than ideal. If the user could "focus" on an element and change the view to just consist of a subtree of the DOM, that could give the user a lot more of their screen to work with when editing elements.
6. User experience design
Cedric and Kevin spoke a bit about some UI aspects. These need to be run past shorlander, but I wanted to note them here:
- to expand/collapse a node, click in the space to the left of the node
- single click on the tag name to select that element
- double click on the tag name to edit the tag name
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
A description of the feature as it shipped is in the Hacks Aurora post
|Theme / Goal||`|
Team status notes
= $all-$resolved ?> Open; = $resolved ?> Resolved; = $all ?> Total (100% complete)
|Quality assurance||`||Test Plan|