Just FYI, this is fully under control of CSL support. The items provided by the SPI implementors have currently no possibility to achieve that.

BTW, can you refresh my memory - what was the strong argument for making it  inconsistent with the common practice? Should the just selection of the element (by keyboard) cause the editor to be moved the corresponding location? If so, then the focus must stay in the navigator. Should the caret be moved as well or just the editor view does move?

It would make sense to me to set the "active html element" on the navigator's element selection so the properties window shows its properties and allows to change them. The editor would stay intact until the user does really want to navigate to the desired element (by the standard double-click, resp. by the go to source action).

If the CSL Navigator top component set its activated node to the node selected in its embedded ExplorerManager, then the whole flow would be more natural and consistent to the rest of the IDE. 

The properties window would become to reflect the navigator nodes selection and indirectly the editor's caret position (since the navigator node selection reflects the editor caret position).

Then such thinks like multiple nodes selection would cause the properties window to switch to the intersection mode and one may set/edit multiple properties at once.

The StructureItem would also need to be able to provide the property sets in some form so the generated navigator nodes can use and expose them.

The StructureItem could also provide its own actions sets and possibly override the default behavior. 

Svato, do you plan some redesign of the CSL's navigator in CSLv2?

I will like try to make some prototype of the described behavior if Svata won't raise a severe objections.

I will likely...

re.: plans: not currently, since there were no requirements. But please be aware that the StructureItem is becoming more and more complex:
* name
* description
* icon
---
* actions
* property sets

at some point, the StructureItem will become more like Node, which we should (IMHO) avoid.

I was thinking to separate these UI-level stuff (icon, actions, ...) in a different provider and keep the StructureItem focused on the structure and basic description of the displayed elements.

re.: prototype - I cannot allocate my brain cycles to CSL for at least the following 2 weeks, so if you need to solve a priority issue, please go ahead.

> I was thinking to separate these UI-level stuff (icon, actions, ...) in a
> different provider and keep the StructureItem focused on the structure and
> basic description of the displayed elements.

That's a good idea and I'll do the property sets binding this way.

now the property sheet reflects the selected nodes in the html navigator 

changeset:   227538:7169cf44247e
branch:      easel_css_72
user:        Marek Fukala <mfukala@netbeans.org>
date:        Wed Jul 18 14:12:57 2012 +0200
summary:     csl navigator sets the activated node according to the embedded explorer manager selection + the API/SPI extended so one may bind own property sets to the navigator nodes.

changeset:   227539:947de1feba73
branch:      easel_css_72
tag:         tip
user:        Marek Fukala <mfukala@netbeans.org>
date:        Wed Jul 18 19:09:45 2012 +0200
summary:     html navigator now allows to edit elements, rewritten the top component lookup switching mechanism

since html.navigator the properties window reflects the selected element.

as for the single click to source navigator, since it is inconsistent with the default navigator behavior in all other languages and the reason why it should behave this way is not clear to me, I recommend to keep it as it is now. 

Feel free to reopen along with adding some arguments. Thanks for understanding.

Moving back to an open status.  We will revisit and disposition as a team.  This is a usability issue for users who are used to working with structured languages like XML and HTML.  The expectation is a single click synchronizes your DT.

This is how JDeveloper works:  with Java, for example, the Structure Pane (Navigator) behaves as it does in NetBeans.  When working on XML/HTML, however, it synchronizes on a single click.  

Also, upping the severity and adding the tag for this being an issue in the august usability test.

Synchronizing on views on single selection is usually not a good idea; single selection is changed even by keyboard navigation. If we scroll/adjust editor viewport according to single-selection change, the component will become not A11Y - and even regular user experience will suffer from needlessly scrolling editor.

If this already works in JDeveloper, then I bet there must be a way to design this in a way that behaves gracefully and is accessible, no?

Possibly; impact of such change should be considered from the usability + consistency standpoint with respect to all interactions provided by Navigator, not just click > reposition source.

Such analysis is beyond my scope, btw, so cc:in Petr Somol. As I was also trying to get Navigator behaviour predictable and consistent between Java/CSS/HTML (and the CSL default support) in the past so, I'd like to aply such a resolution which will increase usability and does not confuse the user to the CSL implementation as well.

Liza, I'd like to see some real arguments, derived from real use-cases,  work-flows or scenarios, why it should behave the proposed way. Likely JDeveloper did some analysis of this topic so it would be handy if we can read it.

In Java one-click-go-to-source in Navigator would be counter-productive from one more reason - in NB7.3 we use Navigator for "Inspect Members" functionality in concert with JavaDoc panel. The typical Inspect Members use case is browsing through class members and checking their JavaDocs, navigation to particular member in source is only the second step, thus well suited to be accomplished with doubleclick instead of a single click.

With HTML or XML though I do not have this objection as the aforementioned usecase seems not to be not valid (no JavaDoc browsing seems to make sense here). I can imagine one click navigation to work without much usability distraction (although consistency of Navigator behavior would indeed be lost). Moving focus by arrow keys for instance can be done in such a way that editor contents get updated with a slight delay so that it does not update as long as focus in Navigator keeps quickly changing.

Otherwise I have no strong opinion about this issue though.