DevTools/Features/HTMLTreeEditor: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(16 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{FeatureStatus
{{FeatureStatus
|Feature name=HTML Tree Editor
|Feature name=HTML Tree Editor
|Feature stage=Development
|Feature stage=Shipped
|Feature status=In progress
|Feature status=Complete
|Feature version=Firefox 17
|Feature health=OK
|Feature health=OK
|Feature status note=In development, WIP patch up
}}
}}
{{FeatureTeam
{{FeatureTeam
|Feature product manager=Kevin Dangoor
|Feature product manager=Kevin Dangoor
|Feature feature manager=Kevin Dangoor
|Feature feature manager=Dave Camp
|Feature lead engineer=Kyle Simpson
|Feature lead engineer=Dave Camp
|Feature qa lead=Mihaela Velimiroviciu (irc: MihaelaV)
}}
}}
{{FeaturePageBody
{{FeaturePageBody
|Feature overview=As part of the original Inspector that was landed in late summer 2010, we landed an HTML tree view. This feature is concerned with adding easy-to-use editing to the tree.
|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.
|Feature users and use cases=Web developers.
|Feature users and use cases=Web developers.
}}
|Feature requirements=Be able to:
{{FeatureInfo
 
|Feature priority=P2
# add or remove a class (adding the class attribute if there isn't one)
|Feature roadmap=Developer Tools
# {{bug|705323}} change text
|Feature list=Desktop
# add/edit other attributes
|Feature engineering team=DevTools
# edit tag name
}}
 
{{FeatureTeamStatus
Optional for the first round (but made it in as part of an earlier feature)):
|Feature security status=sec-review-needed
 
}}
# {{bug|705847}} copy innerHTML/outerHTML for an element
== Summary ==
# be able to remove nodes
As part of the original Inspector that was landed in late summer 2010, we landed an HTML tree view. This feature is concerned with adding easy-to-use editing to the tree.
 
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
# autocompletion
# focus on an element
|Feature functional spec=== 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 <tt>id</tt> 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.


== Team ==
=== Stylesheet Link Tags ===


* '''Feature Manager''': ''Kevin Dangoor'' (irc:kdangoor)
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.
* '''Lead Developer''': ''Kyle Simpson'' (irc:getify)


== Release Requirements ==
=== Script Tags ===


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


== Next Steps & Open Issues ==
=== Style Tags ===


* work through UI choices
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.
* land the simplest approach and iterate
* initial prototype published, so working on adding sync-to-DOM functionality to it
* accessibility review


== Related Bugs & Dependencies ==
=== Validation of Attributes ===


See the [http://mozilla.github.com/devtools/2011/status.html#htmleditor status page]
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).


== Use Cases ==
=== Autocompletion ===


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


== Designs ==
=== Focus on an Element ===


* [http://test.getify.com/mozilla/html-inline-edit.html Initial UX prototype]
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.
* [http://www.screenr.com/FZj Screencast walk-thru of prototype]
|Feature ux 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:
* [http://www.screenr.com/QkTs Updated screencast showing additional UX around delete-attribute]


__NOTOC__
* 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
|Feature landing criteria=A description of the feature as it shipped is [https://hacks.mozilla.org/2012/09/html-editing-and-other-improvements-in-firefox-17-developer-tools/ in the Hacks Aurora post]
}}
{{FeatureInfo
|Feature priority=P2
|Feature rank=2
|Feature roadmap=Developer Tools
|Feature list=Desktop
|Feature engineering team=DevTools
}}
{{FeatureTeamStatus
|Feature security status=sec-review-needed
|Feature security notes=<bugzilla>
{
"id":"787481"
}
</bugzilla>
|Feature qa notes=[https://wiki.mozilla.org/DevTools/Features/HTMLTreeEditor/Test_Plan Test Plan]
}}

Latest revision as of 17:04, 17 September 2012

Please use "Edit with form" above to edit this page.

Status

HTML Tree Editor
Stage Shipped
Status Complete
Release target Firefox 17
Health OK
Status note `

{{#set:Feature name=HTML Tree Editor

|Feature stage=Shipped |Feature status=Complete |Feature version=Firefox 17 |Feature health=OK |Feature status note=` }}

Team

Product manager Kevin Dangoor
Directly Responsible Individual Dave Camp
Lead engineer Dave Camp
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead Mihaela Velimiroviciu (irc: MihaelaV)
UX lead `
Product marketing lead `
Operations lead `
Additional members `

{{#set:Feature product manager=Kevin Dangoor

|Feature feature manager=Dave Camp |Feature lead engineer=Dave Camp |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=Mihaela Velimiroviciu (irc: MihaelaV) |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

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 {{#set:Feature open issues and risks=` |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. |Feature users and use cases=Web developers. |Feature dependencies=` |Feature 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

|Feature non-goals=` |Feature functional spec=== 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. |Feature ux 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

|Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=A description of the feature as it shipped is in the Hacks Aurora post }}

Feature details

Priority P2
Rank 2
Theme / Goal `
Roadmap Developer Tools
Secondary roadmap `
Feature list Desktop
Project `
Engineering team DevTools

{{#set:Feature priority=P2

|Feature rank=2 |Feature theme=` |Feature roadmap=Developer Tools |Feature secondary roadmap=` |Feature list=Desktop |Feature project=` |Feature engineering team=DevTools }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-needed 
   
     Full Query
ID Summary Priority Status
787481 SecReview: HTML Tree editor -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` Test Plan
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-needed |Feature security health=`

|Feature security notes=

Full Query
ID Summary Priority Status
787481 SecReview: HTML Tree editor -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

|Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=Test Plan |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


Retrieved from "https://wiki.allizom.org/index.php?title=DevTools/Features/HTMLTreeEditor&oldid=471058"