Snippets:
load
del
save
add
export
import
delAll
Layouts:
load
del
save
add
export
import
bldPretty
bldMin
clear
Data:
This field will contain Snippets or Layout Shorthand to build. =============================================================================== First time visitor? You really want to read the below text-field first! Congratulations, you leveled up and should first explore and play with the GUI. There are some examples loaded by default to explore and play with. You probably wish to copy generated output into your favorite live editor. You are now a re-visiting user and know where to find hints. Time to have fun!
clear
Comments / Errors:
This field will contain comments for snippets/layouts or errors when building. =============================================================================== SHORTHAND SYNTAX (exclusively used for 'Layouts'): - ONE item per line - Indentation (2 spaces ALWAYS) indicates nesting level (and thus tag-closing) - Allowed items: - HTML container element: `ELM#id.class1.class2 style` (tagname mandatory) - replacement/insert snippet: `$.snippet_name` (like tag `$` + .classname) - HTML comment (single line): `<!-- comment -->` ADDITIONALLY: - NO self-closing tags allowed (almost always is content, and snippets exist) - Snippet and layout names are CaseSensitive and consist of: /[a-zA-Z0-9_-]/ Additionally this GUI intentionally disallows JS Object.prototype names. - Indentation MATTERS when REFERENCING snippets (and comments) in layouts! Is it in the last container or next to (or higher up) the last container? - Liberal, BUT user is responsible; garbage_in == garbage_out !!! EXAMPLE: ELM#id.class1.class2 styleProp1:value;styleProp2:value; NESTED_ELM.class1 styleProp1:value; styleProp2:value; <!-- single line html comment --> $.snippet_name_in_NESTED_ELM $.snippet_name_outside_NESTED_ELM =============================================================================== RATIONALE: FIRST, a syntax was born: a simple, intuitive, even obvious 'shorthand syntax'. It was born out of simple necessity: a way to notate, communicate and reason about some HTML 'framework'. It's a simple, intuitive way to convey structural layout ideas, making it easy to work with and modify. Very likely, many others at some point have invented this syntax (or very similar) for the same purpose and reasons. In simple terms, the meaning of "HTML 'framework'" is simply the (not always semantical but 'this_is_the_only_way') 'scaffolding' markup one would expect around the common `<!-- section/content here -->`, or even a Lorum Ipsum dummy text/content. The latter will be referred to simply as 'content'. Using HTML itself (with added lines for closing tags) and in combination with separate CSS quickly becomes to impractical to quickly wrap your head around. Even with (additional) id and classnames: - one still can not see from separate CSS if these elements are correctly structured, nested (and closed), - when looking at the style-less markup then the element's structural details such as positioning/dimensioning/display type are not immediately clear, - the mental effort required to repetitively combine these seperate parts of information not only impedes the creative process by taking to much time, but also quickly becomes an excercise in futility when rapidly exploring many sleightly different ideas: How often does one assume a style rule exists or does not exist, only to discover that it was removed or modified in earlier tests? What should have been a creative brainstorming session often devolves into a frustrating endeavor, as mental clarity slips away and even false conclusions may be drawn. What is needed/wanted is to get a quick and clear overview of a particular layout 'framework', and thus small, succinct, dense notation syntax that shows STRUCTURAL OVERVIEW (position, size, display) for main layout/'framework'. Indeed, this Shorthand SHOULD contain only 'structural' CSS (but to visualize things one may add background colors and thus font-color when needed). What matters is: margins, padding, position, size, float, all that has to work in harmony to achieve the desired layout (that which will hold the content). There exist various HTML shorthands (like zen/emmet, jade, haml, slim and shh), all of which are more capable than this simple syntax, but they are all bigger: BOTH the shorthand syntax AND the corresponding tools/libs. This is NOT (and likely never will be) yet another full-fledged HTML-shorthand syntax; it would add countless complications, also for the user (to learn). In return, Keeping It Simple allows for almost trivial modification, there is no massive library or syntax to comprehend. This syntax can be manually transformed into HTML (and/or CSS) and likely needs to be filled with 'representative' (test/dummy/real) content to test behaviour. However, this is again needlessly time consuming and error-prone (requiring additional debugging time), all of which just hinder the spark of inspiration. The obvious NEXT STEP thus is to automatically transform this simple intuitive syntax into working HTML. Allowing to insert snippets makes this surprisingly powerful and makes up for some 'shortcomings' in this shorthand syntax. Additionally, snippets can provide some equivalent to wrapping generated layout in other HTML. Lastly a first GUI was created (this one) which marries the syntax to some parser/generators and compliments working with the syntax, as well as allowing to comment snippets and ideas, further amplifying and supporting creating, testing and organizing various ideas. =============================================================================== ADDITIONAL RATIONALE regarding specific choices: Candidates for replacement/insertion 'tag' would be one of `@#$%`. - `&` would be annoying in a html context - prefer character with good 'visibility' (seems to make `%#` a poor choice) - `$` initially felt more intuitive compared to `@` (which is hereby reserved for future expansion, if any) Mimicking 'dot notation' for replacement snippet name felt more logical, akin to dot property access in scripting or CSS classname (as we can use them more than once). Future expansion might use space separated strings (like current style items) for arguments (to generators/repetition or similar)... 2 spaces for indentation: this is to be small and clear and 1 item per line, so linewrapping due to excessive width would be counter-productive to the goal. Single line HTML comments: Single line because there is some elegance to the simple nature of line-based markup and thus parsing (no need for multi-line look-ahead parsing). Why SGML comment syntax? I didn't have a good initial alternative and at the moment it's actually already a 'leftover' to not break existing layout shorthand snippets. Why no attributes? It is perceived that they almost never attribute to the fundamental structure, they would likely mostly bloat the notation (and parser/generators) (if allowed to be used folk will use them (increasingly)). But above all: a lot of complexity; one would be tempted to try and create abbreviations, but which? And the user needs to additionally learn to work with them, and need some reference. Some current white-space friendlyness would likely become more complicated when having to account for (or sort out) 'valid' attributes (which might not even have a value, so no '=' (vs ':') to match for.