Let’s dig in
Multiplicity happens to be typical for some substances, e.g. list elements or some blocks sequence.
In CSSG it will look like this:
/* post_cnt post_cnt_ul post_cnt_li + */
or like that:
/* post_cnt post_cnt_i * */
The main difference between ‘+’ and ‘*’ is in multiplicity specifics.
‘+’ says that element will appear at least 1 time (which is typical for list items - <li>)
‘*’ however says that element may appear more than 0 times (any other elements - you name it)
it’s important to feel the distinction between optional elements ([element]) and appearing 0 and more times (element *)
insignificant on the first sight, it appears to have contextual meaning
Modificators - more and meaningful
As it was mentioned in basic, modificators complement substance and theoretically their simultaneous presence is possible.
Crucial logic described with the help of special syntax.
For example, alternative is illustrated this way:
/* post ( __current | __regular ) __deleted */
and even like this:
/* post ( ( __current | __regular ) | __compact ) __deleted */
Dot (.) illustrates robust connection between class and another class or modificator
/* post __compact __featured post_h post_h_tx . __bold post_b post_b_cnt ... */
alignment on the right for connected class is not necessary
Substance can be direct descendant of other substance.
To point this out, define ancestor via “@” symbol.
/* post-advanced @ post post-advanced_h post-advanced_b */
it’s not necessary to list all modificators, because they inherited by default
however, if there is any difference, we must list all possible classes
it’s accepted that these defined modificators will only be possible
For instance, it is illustrated in the following code, that post-advanced will have one possible modificator __new, regardless the fact, that post has some modificators as well
/* post-advanced @ post __new post-advanced_h post-advanced_b */
Inheritance is directly connected with nominal templates.
We simplify illustration of descendant substance and avoid code duplication by setting changeable parts in ancestor substance.
This is not mandatory, but turns out to be helpful if you have at least two such substances.
As an example, let’s say ancestor substance looks like this:
/* post post_cnt % content % */
or like this, if there is any default content
/* post post_cnt % content % post_cnt_i */
/* post-advanced @ post % content post-advanced_cnt post-advanced_cnt_i */
when “filling” the template second % symbol is unnecessary
In this case post-advanced_cnt will be inside post_cnt and will override default content from second code piece.
Without nominal templates, CSSG may look like this:
/* post-advanced @ post post_cnt post-advanced_cnt post-advanced_cnt_i */
There’s almost no difference in this case.
However all notation potential can be seen in context of describing more complex structure
the % content % element has no DOM implementation, it is just a template name
By dynamics it’s meant that some class or element may appear in layout due to scripts and user activity.
/* post $__disabled | $__active post_h post_b post_cnt */
To define dynamic blocks complemented syntax for optional parts is used:
/* post $[post_msg] post_h post_b post_cnt $[post_cnt_msg] post_cnt_tx $[/post_cnt_msg] */
Complex CSS approach can be described with CSSG.
Alternative (mutual exclusive) blocks example:
/* post post_b  post_cnt post_cnt_lst  post_cnt2 ... [/] */
When it’s necessary to illustrate some valueable class somewhere on the upper level in DOM tree:
/* blog . __complex /// post post_b post_cnt */
CSSG is self-explanatory as a rule, but some tough situations may require comments:
/* post post_h (1) post_b post_cnt (2) _______________________________________________ (1) comment on post_h (2) another comment */
Proceed to legend