There are several related parts to this suggested improvement.

Recommendations:
1. Treat macros and all special editor objects (images, links, etc) the same - i.e. they would all have a frame.

2. Display all of the associated parameters of the object (macro, image, link, etc) as text in the header of the objects frame not a subset and not with ...

3. Allow the parameters in the frame to be edited as name value pairs and re-interpreted when focus leaves the frame.

4. Treat the text in the frame header like other text and support cursor movement in/out and through it. Include the text in searches.

Reasoning (by #):
1. Currently the new editor doesn't treat everything as equivalent.

• This results in issues with where the insertion point moves during editing, what is selected, what gets cut or pasted, etc. Treating everything special (i.e. macros, images, links - things with parameters and/or bodies) as a framed object allows everything to be treated as an object, just like a character of text.
• Providing the frame also now allows you to explicitly see what is inside and outside a special object and allows you to select the object. For example, there is currently no way to select a link. You can select text that is linked, you can select an image that is linked, but you can't select a link.

2. By displaying all parameters on all macros and special objects it becomes obvious how a page is constructed.

• Entering edit mode should expose all of the hidden information that is not visible when the page is rendered. Currently entering edit mode results in a subset of some parameters being displayed. This leads only to more confusion and requires the user to still having to enter a deeper edit mode (i.e. the macro browser or the special popups) to see the true values to edit. An edit mode within an edit mode is a huge productive hit.
• A guiding rule should be "While in edit mode the user will be able to inspect the page and see all the properties effecting how the page renders without needing to do any further activities." If this rule was true a majority of the productivity hit of the new editor would be resolved. To do this requires displaying all of the parameters of macros and special objects in their frame. For example, a warning macro's "show icon" is not shown in the frames parameters. This means that a users must hunt and peck across many instances if he is trying to identify one needing to be change.

3. A productivity hit of the new editor is the need to enter a sub-edit mode (the macro editor or the special popups) when making a change to a parameter that is already applied to a macro or a link/image.

• Allowing the name value parameter pairs in the frame to be edited would allow rapid changes to be made with a few keystrokes with no loss of user focus caused by having to visit a dialog.
• Allowing new parameters to be added into the frame by just typing, for example "width" which is an obvious and easily remembered parameter on many macros, would allow common edits to occur quickly.
• Parameters that could not be parsed after the edit completes (i.e. after focus leaves the frame) could be handled by highlighting or in a similar way to how firebugs lets users change the parameters in the html editor window.

4. The new editor doesn't treat everything the same. All text, in the frame or body should be editable simple by moving up/down/left/right or clicking on it. If immediately above a macro then moving down or right should move you into the macro parameters. Moving to the end of the parameters and past (right arrow repeat) should take you into the body. Pressing down arrow should take you into the parameters, pressing down arrow again should move you into the body. Cut and paste should work within these areas as well as search and replace. To be productive the content, while special, needs to be treated as text.