...
I realize that some parsers may be able to create nested blocks without having to vary the length of the delimiter line. However, this is not something that's currently supported in Asciidoctor, so it would be non-compliant behavior (if the spec solidifies that rule). I also think it would be extremely hard for a human to make sense of if all the delimiters were the same length. So the variation in line length is first and foremost for the benefit of the author.
Agree with everything you say, except that it is not possible to do nesting without varying length or other indication of grouping (differing start and end markups for example)
====
outer
======
inner
======
outer
====
is an inner block nested inside an outer block
====
outer
====
inner
====
outer
====
is two blocks containing "outer" with a paragraph "inner" between them, its not possible to get nesting without some method of distinguishing groups.
Whilst the computer doesn't care so long as the lengths are different and match I wonder if purely for humans a restriction should be introduced that the length must increase with greater nesting, that way it is the same as sections and lists? Or perhaps an advice and a note that it may become a requirement in version 2.0, I guess it depends on how many documents really use the smaller length for nested. In fact I wouldn't have thought many even use nested blocks since the default semantics don't nest. What is the semantics of nested example blocks for example (boom tish)? It would only make sense if at least one of the blocks has a style attribute to make it something else.
Cheers
Lex
--
Dan Allen, Vice President | OpenDevise Inc.
Pronouns: he, him, his
_______________________________________________
asciidoc-lang-dev mailing list
asciidoc-lang-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/asciidoc-lang-dev