Steps to Reproduce: 1. Add new element.style 2. "color" : "red" but don't hit enter 3. Backspace to remove "red" 4. Hit tab to delete the color property and start a new one Actual Results: Tabs to the next style section and starts editing the selector Expected: Removes the "color: " rule and starts editing a new, blank rule.
(In reply to comment #0) > Steps to Reproduce: > > 1. Add new element.style > 2. "color" : "red" but don't hit enter > 3. Backspace to remove "red" > 4. Hit tab to delete the color property and start a new one > > Actual Results: > > Tabs to the next style section and starts editing the selector > > Expected: > > Removes the "color: " rule and starts editing a new, blank rule. I believe you meant to say "a new, blank property" Hmm, the expected behavior seems counter-intuitive to me. You ARE editing a new property (which has never been committed) at the moment. Effectively, you want "Tab" in the value field to clear the name field and move input there, correct? This does not look consistent with the Tab behavior in the rest cases. Why not just Shift+Tab (or Backspace, once bug 51476 patch is landed) to the property name (which automatically gets selected, so you can start entering a new property name from the scratch right away)? When I was designing this tabbing experience, the idea was that if a user has entered (== tabbed out of/clicked outside of) an incomplete blank property (with no name/value), he does not want a new property. In the case of a Tab, the next editable element is the next rule selector (if any).
Present behavior mimics Firebug and is expected. I have not seen 'tab to delete' action anywhere else.