DevTools/Features/HTMLTreeEditor

Status

Team

Open issues/risks

`

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

Web developers.

3. Dependencies

`

4. Requirements

Be able to:

1. add or remove a class (adding the class attribute if there isn't one)
2. bug 705323 change text
3. add/edit other attributes
4. edit tag name

Optional for the first round (but made it in as part of an earlier feature)):

1. bug 705847 copy innerHTML/outerHTML for an element
2. be able to remove nodes

these were not done in the first release:

1. be able to add nodes
2. be able to move nodes
3. bug 703383 ability to get a CSS selector for an element
4. handle elements like script and link appropriately
5. style tag editing in-place
6. validation of attributes
7. autocompletion
8. focus on an element

Non-goals

`

Stage 2: Design

5. Functional specification

Requirements

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.

Change Text

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

Being able to assign an id for an element, for example, makes it easier for the developer to work with that element in JavaScript. The ability to edit other attributes allows users to see how their application behaves with different data in the DOM.

Optional Features

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.

Edit Tag

Sometimes people need to change the tag as part of their editing in support of styling.

Remove Nodes

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.

Add Node

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).

Move 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

The ability to quickly get a CSS selector for an element makes it easier for a user to write new style rules for that element and related elements or new bits of JavaScript code that work with them.

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.

Script Tags

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.

Style Tags

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).

Autocompletion

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

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

A description of the feature as it shipped is in the Hacks Aurora post

Feature details

Team status notes

   

     Full Query    

   

     Full Query