Let's dig in

Multiplicity

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

Inheritance

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

*/

Nominal templates

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

*/

descendant substance

/*

    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

Dynamics

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]

*/

It's <<omplicated

Complex CSS approach can be described with CSSG.

Alternative (mutual exclusive) blocks example:

/*

    post
        post_b

            [1]
            post_cnt
                post_cnt_lst

            [2]
            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