A "Snippet palette" where devs can define a piece of markup, give it a title and a programmatic name, thus making this snippet easily available to end users of the Visual Editor. Those users will see a list of snippet titles, typically titled like "Flash movie", "YouTube movie", "Image gallery", "Table for prices", "Stacked boxes", "2 columns layout" (devs control this).
__(UPDATED)__ A snippet can be inserted into the Code Editor at the caret position/selection via "Insert | Feature", this invoke the selection list. In the Visual Editor snippets are shown in the right pane, below the template / place holder selector for where you can single click a snippet title and have it inserted at the caret position/selection. (Visual Editors that don't sport an existing template pane will get a pane introduced by default. Form Markup and Widget functions will get a bool "ShowSnippetPalette" defaulting to true).
Snippet output can be xhtml blocks (like a prepared table, with class's, th's etc. already done) and function markup with some or all params pre-specified. In function situations, if any required params need to get a value, the function call editor dialog is popped.
Packages should also be able to easily introduce snippets when installed.
__UPDATE:__ Rather than just being flat xml documents snippet sources could also be C1 Functions that return markup (XhtmlDocument etc.). When a user choose to insert a snippet - and the source C1 Function has parameters - we pop a "fill in the blanks" dialog where user can override values (like changing a heading text, selecting a specific image, choosing a variant). The function then execute and the resulting markup is inserted. This should enable end-users to realize the desired result in a more structured view (as opposed to pure visual editing) and should allow for more advanced snippets (example is a image parameter, where user select image and the result contains the final resize/crop image url). Idea via @napernik .
__UPDATE 2:__ When registering a snippet you can specify one or more [CSS selectors](http://www.w3.org/TR/CSS2/selector.html#pattern-matching) which will restrict or highlight the visibility of the snippet in the Visual Editor (either pushing it to the top of the list, show it as secondary, tertiary or not show it at all). This ability to push most relevant snippets up and hide very specialized and unrelated snippets will allow for more convenient "LEGO building" where an end user - once selecting some container snippet, will see relevant "sub snippets" as the primary elements in the Snippet Palette. If a snippet has no rules on it, it is tertiary. Primary should only be used by devs for very specific css selectors - so most of the time the secondary ones are the important ones. All non-hidden snippets are shown; the primary snippets - if any - are shown first in a slightly more highlighted way, then secondary and tertiary follow in that order, each group with some margin. Example: A "Stacked boxes" snippet which emit ```HTML: ``` and expect ```HTML: ``` children - here a specialized "Stack box" snippet would become primary when the selector ```CSS: div.stackedboxes``` is active, while hidden for the selectors ```CSS: *, div.stackedboxes *```. The end user would not be bothered by "Stack box", unless a "Stacked boxes" is inserted/focused, in which case "Stack Box" jumps to the top and gets highlighted, helping the end user along.
__UPDATE 3:__ A dev should be able to attach CSS rules to the Visual Editor, making it possible to have things like ```CSS: div.stackedboxes div.stackbox: border:2px dashed green; margin: 10px inherit;``` which only affect the Visual Editor. It would be convenient for the end user if there are visual markers on zones that is expected to be filled in. Example is a "Stacked boxes" snippet that emit ```HTML: ``` - existing site CSS will (like today) ensure that the stacked boxes are rendered with sizing, spacing, coloring etc. in the Visual Editor, but a CSS rule that the snippet attached could ensure the 3 boxes are visually highlighted - for instance with a thick green dashed border. We should provide guidance on visual styling to use. Perhaps a toggle button in the visual editor could turn "snippet CSS" on/off for all snippets, enabling a quick WYSIWYG without the markers.
Comments: ** Comment from web user: burningice **
__(UPDATED)__ A snippet can be inserted into the Code Editor at the caret position/selection via "Insert | Feature", this invoke the selection list. In the Visual Editor snippets are shown in the right pane, below the template / place holder selector for where you can single click a snippet title and have it inserted at the caret position/selection. (Visual Editors that don't sport an existing template pane will get a pane introduced by default. Form Markup and Widget functions will get a bool "ShowSnippetPalette" defaulting to true).
Snippet output can be xhtml blocks (like a prepared table, with class's, th's etc. already done) and function markup with some or all params pre-specified. In function situations, if any required params need to get a value, the function call editor dialog is popped.
Packages should also be able to easily introduce snippets when installed.
__UPDATE:__ Rather than just being flat xml documents snippet sources could also be C1 Functions that return markup (XhtmlDocument etc.). When a user choose to insert a snippet - and the source C1 Function has parameters - we pop a "fill in the blanks" dialog where user can override values (like changing a heading text, selecting a specific image, choosing a variant). The function then execute and the resulting markup is inserted. This should enable end-users to realize the desired result in a more structured view (as opposed to pure visual editing) and should allow for more advanced snippets (example is a image parameter, where user select image and the result contains the final resize/crop image url). Idea via @napernik .
__UPDATE 2:__ When registering a snippet you can specify one or more [CSS selectors](http://www.w3.org/TR/CSS2/selector.html#pattern-matching) which will restrict or highlight the visibility of the snippet in the Visual Editor (either pushing it to the top of the list, show it as secondary, tertiary or not show it at all). This ability to push most relevant snippets up and hide very specialized and unrelated snippets will allow for more convenient "LEGO building" where an end user - once selecting some container snippet, will see relevant "sub snippets" as the primary elements in the Snippet Palette. If a snippet has no rules on it, it is tertiary. Primary should only be used by devs for very specific css selectors - so most of the time the secondary ones are the important ones. All non-hidden snippets are shown; the primary snippets - if any - are shown first in a slightly more highlighted way, then secondary and tertiary follow in that order, each group with some margin. Example: A "Stacked boxes" snippet which emit ```HTML: ``` and expect ```HTML: ``` children - here a specialized "Stack box" snippet would become primary when the selector ```CSS: div.stackedboxes``` is active, while hidden for the selectors ```CSS: *, div.stackedboxes *```. The end user would not be bothered by "Stack box", unless a "Stacked boxes" is inserted/focused, in which case "Stack Box" jumps to the top and gets highlighted, helping the end user along.
__UPDATE 3:__ A dev should be able to attach CSS rules to the Visual Editor, making it possible to have things like ```CSS: div.stackedboxes div.stackbox: border:2px dashed green; margin: 10px inherit;``` which only affect the Visual Editor. It would be convenient for the end user if there are visual markers on zones that is expected to be filled in. Example is a "Stacked boxes" snippet that emit ```HTML: ``` - existing site CSS will (like today) ensure that the stacked boxes are rendered with sizing, spacing, coloring etc. in the Visual Editor, but a CSS rule that the snippet attached could ensure the 3 boxes are visually highlighted - for instance with a thick green dashed border. We should provide guidance on visual styling to use. Perhaps a toggle button in the visual editor could turn "snippet CSS" on/off for all snippets, enabling a quick WYSIWYG without the markers.
Comments: ** Comment from web user: burningice **
whuuut!! this is sweet %-]