CSSStylingInOtherProjects

(Difference between revisions)
m
m
Line 30: Line 30:
* were motivated by the idea of loading of the focused source file in the browser immediately but we are not doing that - it would have a negative performance impact when done in embedded browser and would be weird to do this in external browser
* were motivated by the idea of loading of the focused source file in the browser immediately but we are not doing that - it would have a negative performance impact when done in embedded browser and would be weird to do this in external browser
* CSS Styles view is shown for any HTML/PHP/JSP file currently but it provides almost no value (i.e., it wastes the screen estate) unless the file is executed
* CSS Styles view is shown for any HTML/PHP/JSP file currently but it provides almost no value (i.e., it wastes the screen estate) unless the file is executed
-
* there are some usability problems with the current eager pursuit of the active editor pane, for example: user finds out that some element is styled incorrectly (by selecting it and watching the content of CSS Styles view). (S)he jumps into the CSS file that contains the relevant rules => the content of CSS Styles view is replaced with the list of rules in the CSS file. This is unfortunate, the user can no longer see what is wrong with the selected element. Moreover, it is useless to show the list of rules in CSS Styles view because it is shown in Navigator already.
+
* there are some usability problems with the current eager pursuit of the active editor pane. For example: user finds out that some element is styled incorrectly (by selecting it and watching the content of CSS Styles view). (S)he jumps into the CSS file that contains the relevant rules => the content of CSS Styles view is replaced with the list of rules in the CSS file. This is unfortunate, the user can no longer see what is wrong with the selected element. Moreover, it is useless to show the list of rules in CSS Styles view because it is shown in Navigator already.
===Views follow browser===
===Views follow browser===

Revision as of 11:02, 11 March 2013

The design of some Easel areas in NetBeans 7.3 was tied to HTML projects that were not using any kind of templating framework. The current design has some problems with the templating frameworks and other project types. Hence, it would be great to review some design decisions.

For example, whether the DOM tree from the browser should be merged into some Navigator-based view or whether we should have a separate view showing the DOM tree from the browser. Another question is whether the content of our views (like CSS Styles view or the standalone DOM Tree view) should follow the focused editor pane or whether it should follow the page displayed in the inspected browser pane.

Contents

Standalone DOM Tree view x Navigator-based views

Navigator-based views


  • some kind of merged view is required for each MIME type of a source file (HTML, JSP, PHP, etc.)
  • merged view for other MIME types
    • may not make much sense - there may be (almost) no HTML in the source file
    • may be tricky/impossible to implement
  • requires various hacks to enforce the right content of Navigator

Standalone DOM Tree view


  • needed for technologies where the matching between web page and its source is impossible/unreliable
  • more suitable for web pages whose HTML structure comes from several source files
  • no need to implement for each MIME type separately
    • easy to show a DOM tree from the browser (no matter what the source of the page is)
    • we can still keep enhanced trees for some MIME types (like the merged source-browser tree for HTML files)

Views follow focus/editor x views follow browser

Views follow focus/editor


  • work well for technologies where there is 1-to-1 mapping between web pages and source files
  • stumble/are unclear when (the HTML portion of) the web page comes from several source files (for example, included HTML fragments)
  • fail when we are unable to find source files of the web page reliably
  • were motivated by the idea of loading of the focused source file in the browser immediately but we are not doing that - it would have a negative performance impact when done in embedded browser and would be weird to do this in external browser
  • CSS Styles view is shown for any HTML/PHP/JSP file currently but it provides almost no value (i.e., it wastes the screen estate) unless the file is executed
  • there are some usability problems with the current eager pursuit of the active editor pane. For example: user finds out that some element is styled incorrectly (by selecting it and watching the content of CSS Styles view). (S)he jumps into the CSS file that contains the relevant rules => the content of CSS Styles view is replaced with the list of rules in the CSS file. This is unfortunate, the user can no longer see what is wrong with the selected element. Moreover, it is useless to show the list of rules in CSS Styles view because it is shown in Navigator already.

Views follow browser


  • makes a great couple with the standalone DOM Tree view - the content of the DOM Tree view is always defined clearly no matter what technology is used
  • CSS Styles view can be shown when some page is executed in the browser with NetBeans integration, i.e., is shown when it provides some value only
  • there is no unwanted switching of the content of CSS Styles view - the content is kept until
    • another element is selected or
    • user navigates to another page
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo