bldLayout v24-07-23

Snippets:
Layouts:

Data:

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): ``

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;
    
    $.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 ``, 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.