This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | "Edit CSS Rules" dialog modifications preview | ||
---|---|---|---|
Product: | web | Reporter: | Petr Jiricka <pjiricka> |
Component: | CSS Visual Tools | Assignee: | Jan Stola <jstola> |
Status: | NEW --- | ||
Severity: | normal | CC: | lxlyons |
Priority: | P2 | ||
Version: | 7.3 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Petr Jiricka
2012-11-20 13:10:46 UTC
I completely agree with both complains. I believe "Edit CSS Rules" would be better (I've already used that name in the editor popup as you noticed). As for the second problem, I was thinking about the same - at least adding a text area at the bottom which would log all the planned changes. It would be also nice to provide better "diff" for the selected html source element as now it only marks created or modified attributes but won't flag removed one. Possibly we could use the refactoring preview for both. I wasn't sure whether "we" will like the ability to change more selector types at once (which is IMO the biggest contributor to the possible confusion) I didn't do any of the above. Possibly the whole functionality related to "Rules Editor" should be done via the refactoring API which would mean we'd get the changes preview "for free", the functionality may be more discoverable and user would be able to undo the whole refactoring atomically. the name has been changed to "Edit CSS Rules". Keeping opened & switching to enhancement for the second problem. Guys: When accessed from the CSS Styles window, this is properly titled Create CSS Style since that is what the user is doing: the toolbar button that provides access to this is a create. In fact, users in our usability test were specifically looking for a "create" icon and gesture since that's what they're thinking when working in that particular UI. The fact that the user might choose to apply an existing style to the current element instead is incidental, so we should design for the 80%+ use case. For the source case, I think the context menu name is better as Select CSS Style or Apply CSS Style, and the dialog would be titled Apply CSS Style. We're not actually editing the style itself (we're not setting any properties) -- we're picking an existing style or creating a new one. I would expect an Edit CSS Style dialog to bring up a nice editor for the properties themselves. |