Syntax for divs

[jgm]

I've been missing a way to specify a div markdown
without using HTML tags.  The (relatively) new 
delimited code block syntax gave me an idea however.
Consider using a line of four or more periods to
start a div:

    Para before div

    ....
    First para inside div

    Second para inside div

    Third para inside div
    ....

Since one will often want and need to apply an ID
and/or class to a div one should be able specify
those.  I suggest a CSS-like syntax inside braces
after the opening line of periods

    .... {#id .class}
    div content
    ....

One problem would be nested divs.  I suggest marking
those by indenting.  A code/pre block containing div
syntax would need to be doubly indented, similar to 
such blocks inside lists:

    .... {#outer_div}

    Para of outer div

        .... {#nested_div}

        Para of nested div.

        A code block illustrating div syntax
        (a most unusual thing!):

                ....{#example_div}
                This is how you specify a div
                ....

        Another para in nested div

        ....

    Another para in outer div

    ....
markdown
Of course one could mark nested divs by more periods in the
line (and then at least two more!):

    .... {#outer_div}

    Para of outer div

    ...... {#nested_div}

    Para of nested div.

    A code block illustrating div syntax
    (a most unusual thing!):

        ....{#example_div}
        This is how you specify a div
        ....

    Another para in nested div

    ......

    Another para in outer div

    ....

But I think indenting makes things cleaner, making it
easier to remember closing the divs you have opened, and not 
to close more divs than you have opened.  If you have very 
many nested divs you should probably pause and consider why 
anyway!

Google Code Info:
Issue #: 195
Author: bpjonsson
Created On: 2010-01-07T13:54:47.000Z
Closed On: 

[uvtc]

I think that using the delimited code block syntax as a model for a new div syntax is a good idea. It will be familiar to Pandoc users, and will be easy to remember.

Since delimited code blocks require only 3 or more tildes, I think a div syntax requiring only 3 or more characters would be consistent and desirable.

Using dots for delimited divs may not be the best choice because it's not uncommon to type "..." into a document (and "..." & "...." are too similar). Also, since the dot glyphs are at the bottom of a line, the closing dots look a bit odd hanging there all by themselves. Dashes would be nice but are too similar to the tildes used for delimited code blocks. Angle-brackets (greater-thans) might be nice, but are already used for blockquotes. "At" signs are a bit too obtrusive looking, IMO. Percent signs might be ok...

IMO though, forward slashes probably look the nicest:

/// {.some-class #some-id}
some text here some text here
some text here some text here
///

They look unobtrusive enough to me. The "///" is not a pattern that anyone uses in their writing with any regularity (that I know of). And I think that folks who have worked with html will think "closing html element" when they see "///", so that should make users feel fairly comfortable with them.

As for nested divs, I very much do not like the idea of using indentation. In markdown, indentation is for code blocks and for making lists look pretty. :) If you want to support nested divs, but in a way that makes it obvious how many levels deep you are, how about requiring a space between each set of 3 forward slashes:

/// {.foo}
some text here some text here
some text here some text here
some text here some text here
/// /// {.bar}
more text more text more text
more text more text more text
more text more text more text
/// ///
///

[jgm]

As I noted on the mailing list, I like the looks of this:

______________________
{.Note #some-id}

paragraph one.

- list
- list
_______________________

Optionally the attribute could be put on the same line as the underlines.

(Note: currently the attribute parser requires the id to come first; this ought to be changed in any case.)

Nesting can be handled the way I handle it with delimited code blocks -- a block is only ended by a string of underline characters that is at least as long than the one that opens it. So, you can use long strings of underlines for outer divs, shorter strings for inner divs.

_________ {#outer-div}
blah
blah
_____ {#inner-div}
ok
_____
blah
blah
____________

[uvtc]

Yes, I think that syntax fits nicely along with the syntax for delimited code blocks.

The only thing I don't like is using underscores, because:

• their glyph is vertically too low on the line. It looks odd to use them, and they look weird hanging there when you close the id/class.
• Pandoc Markdown is already using dashes for h2 headings, and for tables, and horizontal rules ... underscores look too similar to them. Too many straight horizontal lines everywhere in ones documents.
• multiple underscores already mean "horizontal rule", so human readers wouldn't know if ___ means horizontal rule or closing delimited element

Since Pandoc is already using tildes for delimited code blocks, I think it would be consistent to also use tildes for generic delimited blocks -- however, maybe do it like so:

~ ~ ~ ~ ~ ~ {#outer}
blah
blah
~ ~ ~ {#inner}
ok
~ ~ ~ 
blah
blah
~ ~ ~ ~ ~ ~

That is, the repeated pattern is "~ " (with a space), rather than "~" (no space). Some benefits of this syntax:

• less obtrusive than forward slashes or underscores
• doesn't interfere with the syntax for horizontal rules
• adds syntax consistency, that is: "all delimited blocks (code or otherwise) use tildes" --- easy to remember. For that matter: "Blocks of code are dense, so the tildes are dense." ;)
• the tilde glyph is in the vertical center, so it looks nice and symmetrical

[hansbkk]

FWIW I like the tilde-space idea over underscores

[bpj]

I think that it's desirable that the syntax for divs is clearly different from the syntax for both horizontal rules and code blocks, so that neither of the three is easily mistaken for the other by a human or computer reader. A distinction between tildes and tildes/spaces would be unfortunate for two reasons:

1. It would be directly contrary to the syntax for horizontal rules, where the following are equivalent:

   ****    * * * *
   ----    - - - -
   ____    _ _ _ _

2. It would be easy to mistype tilde/space as tilde-tilde, especially since the tilde key only is available as a AltGr + deadkey combination on the keyboards of some countries (admittedly including my own!). While it's reasonably easy to hold AltGr and hit the right key eight times to get four tildes in a row, alternately holding down AltGr and hitting the key twice and releasing AltGr and hit the spacebar would be a great nuisance, and lead to frequent typos

The reason I originally suggested a row of four periods as the syntax for div delimiters was that I was under the false impression that ==== and ++++ were among the permitted syntaxes for horizontal rules! My actual preference was and is for a row of equals signs: as that is sometimes used as a kind of section delimiter/cut here in emails in would be a choice in keeping with the markdown philosophy.

[thejohnfreeman]

+1 for this. I would love to set attributes (especially classes for styling) on more generated entities than just code blocks.

[ousia]

I agree with the ability to set attributes (at least, id, classes and languages) for other blocks than code blocks.

And having a RawSpan would be also interesting to be able to set attributes to any arbitrary text passage, not being an element. (I'm thinking of languages, but different font properties, such as small caps, fit here.)

The syntax for spans in extended markdown should be different than periods, because this would be misleading.

[ousia]

And how about square brackets for marking divs?

[[[ {.note #n32}
this is the div
]]]

[uvtc]

Wow! This issue is still open. :) Just stumbled upon it searching for something else.

Not sure any of these proposals (including my own from a year ago) are significantly better than just using raw html.

This may be one of those cases where Markdown wins simply by being able to embed raw html.

[uvtc]

For your consideration:

Hi.

^^^{#some-id .some-class}
This doesn't
look half bad.
^^^

Next paragraph.

The carets make me think "metadata" (data, ^up there^, see?), and I can live with the space underneath much better than the space above (like you'd get if using dots).

That, together with some [span syntax]{.other-class} would be very nice. :)

[uvtc]

Also, the carets look nice; not too obtrusive. Almost look like an underline at the bottom, but go ok at the top too.

Clojure uses a similar caret syntax to mean metadata, and it looks pretty right to me.

And, I think Pandoc is currently only using the caret for footnotes and for superscript, so it wouldn't conflict to allow it to be used here for this purpose (which would always be at least three carats).

[hholst80]

What about something from Bash and similar shells? http://en.wikipedia.org/wiki/Here_document

[mpickering]

I think it's agreed that some syntax for div and span elements is needed to tidy up markdown code which uses them. This discussion has turned into an exercise in bike shedding.

Suggestions so far include

///
...
\~\~\~
___
^^^
[[[
:::

and various combinations of the above.

To move things forward - I'm personally a fan of ^ and using surround-marking instead of side-marking. I will implement this in the near future and then people can feel free to fiddle with the specifics as they please.

[jgm]

For what it's worth, the most popular idea on the CommonMark forum is :::: http://talk.commonmark.org/t/generic-directives-plugins-syntax/444/100

I'm still undecided, including about side or surround marking, but I think I like ::: better than ^^^.

Also, if anything is done on this, it should work like fenced code blocks -- the opening sequence can be of variable length, and the closing sequence must be of equal or greater length. That allows these things to be nested.

[bpj]

^^^ somehow rubs me the wrong way, as it looks like three up-arrows, which doesn't make sense in this context. I still think === would be best as it looks like 'cut here', but if the CommonMark people are leaning towards ::: that's probably what we should use.

Disclaimer: I still feel that smallcaps should be ^^foo^^, so my first thought when seeing ^^^ is 'a block of smallcaps', which is rather silly of me.

[bpj]

BTW it has occurred to me that having successively fewer marks for nested divs would lead to unpleasantness if you run out of markers. I'm not convinced that having an editor smack on a few extra markers to the beginning of each matching line would do the right thing in all cases.

[jgm]

I really like === myself. There's more potential for a clash with setext headers, though, which may make ::: safer.

[bpj]

@jgm said: I really like === myself. There's more potential for a clash with setext headers, though, which may make ::: safer.

Absolutely true. I keep forgetting that because I always use only ATX-headers. My commandline wrapper is set to pass --atx-headers at all times.

[MarLinn]

Hi there. I'm completely new here, but these are my two cents anyway... I like the idea of having distinct start and end elements an in

[[[ {.this}
suggestion.
]]]

because that makes the desired result really obvious to both humans and parsers. But markdown started off as a minimal markup, so here's an idea how to simplify this further:

{.this}
is a simple div with class "this".

  {.here}
    is a second div with class "here", inside the "this" div.
    The indentation is optional, but helpful.
  }
  Thus ends the "here" div.

{{.instead}
  of indentation, one could also allow several "{" to start a nested div.  

  But how to start divs without classes or ids, you ask.

  {} How about doing it this way?}

}}
That was the end of "instead" with an optional, additional "}".

{#last .idea}
  ending two divs in one line could be achieved
  with a simple space in between, like this:
} }

And I'm outside!

What do you think?

[ousia]

@jgm, would it be possible that syntax for generic division and spans make its way into release 1.14?

I would say that having different opening and closing characters (such as previously proposed [[[ and ]]]) helps to nesting and readabiliy, so that most errors can be easily recognized. (I’d say it also makes parsing easier.)

Indenting is more problematic because not everyone feels comfortable with a coding editor (or you may not have one in your mobile device [tablet or smartphone]). And it doesn’t necessarily increase readability.

But after more than five years that the original message had been posted in the mailing list, I guess it is time to implement a syntax for generic division and span elements.

[jgm]

1.14 is going to be released very soon, so I'm not adding new features at this point.

+++ Pablo Rodríguez [May 24 15 08:31 ]:

[1]@jgm, would it be possible that syntax for generic division and spans make its way into release 1.14?

I would say that having different opening and closing characters (such as previously proposed [[[ and ]]]) helps to nesting and readabiliy, so that most errors can be easily recognized. (I’d say it also makes parsing easier.)

Indenting is more problematic because not everyone feels comfortable with a coding editor (or you may not have one in your mobile device [tablet or smartphone]). And it doesn’t necessarily increase readability.

But after more than five years that the original message had been posted in the mailing list, I guess it is time to implement a syntax for generic division and span elements.

— Reply to this email directly or [2]view it on GitHub.

References

1. https://github.com/jgm
2. https://github.com/jgm/pandoc/issues/168#issuecomment-105027444

[uvtc]

I think the colons look good.

Would also be nice to see some [span syntax]{.cool-feature} make it in as well.

[uvtc]

jgm wrote:

I really like === myself. There's more potential for a clash with setext headers, though, which may make ::: safer.

Sorry for the bikeshedding. I agree with you and bpj that === looks the best. Is the concern that it could lead to a clash in the Pandoc implementation, CommonMark implementation, CommonMark spec, or just that it will visually clash?

[jgm]

+++ John Gabriele [Jul 27 15 09:51 ]:

jgm wrote:

I really like === myself. There's more potential for a clash with
setext headers, though, which may make ::: safer.

Sorry for the bikeshedding. I agree with you and bpj that === looks the best. Is the concern that it could lead to a clash in the Pandoc implementation, CommonMark implementation, CommonMark spec, or just that it will visually clash?

I think my main concern was the potential for ambiguities:

Is this a setext header
===========================
or just a paragraph
followed by a fenced block?
===========================

This could be avoided by requiring a blank line before the fenced block, but in CommonMark we normally don't require these lines (they're not needed before fenced code blocks, for example).

Of course, we can just settle the ambiguity with an explicit stipulation, as we already need to do for horizontal rules and setext headers. So this may not be a big concern.

[ousia]

Is this a setext header
===========================
or just a paragraph
followed by a fenced block?
=========================== 

This could be avoided by requiring a blank line before the fenced block, but in CommonMark we normally don't require these lines (they're not needed before fenced code blocks, for example).

Either with === or ::: if no blank line is required before the fenced division, I think that nesting divisions would be harder than it should.

BTW, what is the gain in not requiring blank lines before code blocks? Sorry, but I don’t see it. At least from the writer’s perspective, it doesn’t make the text more readable.

[uvtc]

Of course, we can just settle the ambiguity with an explicit stipulation, as we already need to do for horizontal rules and setext headers. So this may not be a big concern.

Oh my. My purpose in using markdown is to make my plain text look clear. Which means, I always put blank lines around blocks, and for that matter underneath headings, whether Pandoc requires it or not.

I think this is an easy one: just require the blank lines and be done with it.

[jgm]

+++ John Gabriele [Jul 27 15 10:58 ]:

Of course, we can just settle the ambiguity with an explicit
stipulation, as we already need to do for horizontal rules and
setext headers. So this may not be a big concern.

Oh my. My purpose in using markdown is to make my plain text look clear. Which means, I always put blank lines around blocks, and for that matter underneath headings, whether Pandoc requires it or not.

Good for you. But not everyone does. It's established practice in Markdown not to require blank lines before fenced code blocks, or after headings. Requiring them here makes things less consistent and will surprise users.

Generally, Markdown's approach is to be incredibly forgiving. (Contrast reStructuredText.)

[jgm]

+++ Pablo Rodríguez [Jul 27 15 10:31 ]:

Is this a setext header

or just a paragraph

followed by a fenced block?

This could be avoided by requiring a blank line before the fenced
block, but in CommonMark we normally don't require these lines
(they're not needed before fenced code blocks, for example).

Either with === or ::: if no blank line is required before the fenced division, I think that nesting divisions would be harder than it should.

Nesting would be handled as it is with fenced code blocks. The block is terminated by the first line of =s of length equal to or greater than the initial one. That is simple and is not affected by this question.

[uvtc]

It's established practice in Markdown not to require blank lines before fenced code blocks, or after headings.

Ah, didn't know that. I've never seen a code block written without blank lines around it, and only rarely a heading without a blank line under it (maybe in a unix util changelog somewhere?). In either case, I'd assume the lack of blank line(s) was just a typo.

Generally, Markdown's approach is to be incredibly forgiving. (Contrast reStructuredText.)

Interesting. My impression has been that first and foremost, Markdown's approach is to look good/natural/readable, while secondarily being flexible (ex., regular vs. "lazy" lists, multiple table formats, etc.), and lastly being pretty forgiving. But that could be simply because I don't ask it to be forgiving. :)

Would there be any value in requiring at least an empty trailing {} for code blocks without a leading empty line? As in:

This is the end of a paragraph. Div block
with no attribs coming up.
=== {}
Div block without a newline in front of
it requires at least the `{}`.
===

?

Otherwise, could Pandoc use the heuristic that if the length of the line of equal signs is the same as the length of the line above, then it's a setext heading, otherwise it's the start of a div block?

[bpj]

Alas pandoc already accepts non-equal length text and underline in headers.

I have nothing against the colons alternative -- in fact I like it.

[hadley]

It would be useful if this mechanism could also be used to generate arbitrary environments in latex, e.g.

:::{#someid .someclass}
This doesn't
look half bad.
:::

would become

<div id="someid" class="someclass"> 
  <p>This doesn't look half bad</p>
</div>

or

\begin{someclass}
  \label{someid}
  This doesn't look half bad
\end{someclass}

(I don't think label plays well in arbitrary latex environments, but I don't think it does any harm, and you're unlikely to use it unless you specifically need it.)

This would be extremely useful when you're generating both latex and html from the same source doc (as is common if you're writing a book that has both a website and a final printed pdf)

[felixsanz]

is this implemented? FP is almost 5 years old :older_man:

[jgm]

+++ Felix Sanz [Feb 16 16 02:02 ]:

is this implemented? FP is almost 5 years old :older_man:

My, the time flies. Yes, we should probably settle on something and do this.

[felixsanz]

If my tiny opinion counts, this is the way to go:

::: {#id .class data-attr=""}
text inside a div
:::

Just like fenced codes but with :. Other markdown parsers do it that way too

[jgm]

+++ Felix Sanz [Feb 16 16 19:08 ]:

If my tiny opinion counts, this is the way to go: ::: {#id .class data-attr=""} text inside a div :::

Just like fenced codes but with :. Other markdown parsers do it that way too

Which ones support that syntax?

[felixsanz]

official markdown-it container plugin: https://github.com/markdown-it/markdown-it-container

(It doesn't support {attributes}, but that's why exist markdown-it-attr and markdown-it-decorator)

[ousia]

If my tiny opinion counts, this is the way to go:

::: {#id .class data-attr=""}
text inside a div
:::

Just like fenced codes but with :. Other markdown parsers do it that way too

Which ones support that syntax?

I’d rather prefer [[[ and ]]]. But if not, ::: syntax is better than no syntax at all.

Please, don”t forget the syntax for spans. In that case, links already use [ and ].

I think it is essential to implement a special syntax for both divs and spans in the next stable version (1.17, i guess).

[felixsanz]

:::
div
:::

:span:

is this even possible?

[mb21]

If I remember previous discussions correctly, they tended to be in favour of surround-marking (like fenced-code blocks but different symbol). No consensus was found over which symbol to use, however. But I think markdown-it using ::: is setting a strong precedent, and I think vitaly et al chose this following the discussion on talk.commonmark.org.

AFAIK the span syntax is pretty much agreed upon to be: a [span]{.myClass} in the text

[bpj]

With the new link attributes we are only a pair of parentheses away from that span syntax. For what it's worth I've written a filter which converts a link with an empty URL into a span so that I can write:

[this *is* the span content](){#id .class}

The only disadvantage is that such a 'span' can't contain links...

I agree about colon-fences for divs, especially since others have already adopted it, so forget everything I've said earlier to the contrary

[bpj]

Just one thing: since the start and end of a div can be much farther separated than what is usually the case with code blocks, and contain other divs it would be good if one be allowed to have more text as a comment on the same line as the closing fence, so that one can put the id of the div or something similar there, as a help to the human writer. I always put an HTML comment to that effect at the end of a long div. There could be an option to have the Markdown and LaTeX writers automatically insert a comment with the div id, if any, at the end. Note that it is possible to do that by hand at present but the comment ends up on a line of its own.

<div class=foo>
Blah blah
</div><!-- #foo -->

<div class="foo">
<p>Blah blah</p>
</div>
<!-- #foo -->

So I'm thinking along the lines of

:::{#foo}
Blah blah

Blah blah...
:::<!-- #foo (This comment is ignored by pandoc!) -->

[jgm]

I think the only natural syntax for spans is [the square bracket syntax]. We already parse these as inline containers, so it makes sense. We'd have all these combinations:

[regular span]{#id}
[link](url)
[link with attributes](url){#id}
![image](url)
![image with attributes](url){#id}

Probably

[regular brackets]

should not be a span. This occurs naturally in text.

[jgm]

I think long ago I suggested a side-marking syntax for divs, similar to what is used now for block quotes. This has the advantage that scope is visually clear. It is also very consistent with original Markdown, since we already have > for block quotes.

Nobody liked this at the time, but I still think it makes sense (which might be why I've hesitated so much to adopt one of the other proposals).

Example:

: {#id .warning} : Here is a special warning section. : : It can go on as long as you like. : :: {#subid color=blue} :: and it can contain sub-divs like this. :: It's clear when this ends. : : Back to the outer div.

"Laziness" would apply just as with block quotes. So, you could just do:

:{#id .warning} This is a warning! Lazy style.

+++ Benct Philip Jonsson [Feb 17 16 03:54 ]:

Just one thing: since the start and end of a div can be much farther separated than what is usually the case with code blocks, and contain other divs it would be good if one be allowed to have more text as a comment on the same line as the closing fence, so that one can put the id of the div or something similar there, as a help to the human writer. I always put an HTML comment to that effect at the end of a long div. There could be an option to have the Markdown and LaTeX writers automatically insert a comment with the div id, if any, at the end. Note that it is possible to do that by hand at present but the comment ends up on a line of its own.

Blah blah

Blah blah

So I'm thinking along the lines of :::{#foo} Blah blah Blah blah... ::: — Reply to this email directly or [1]view it on GitHub. References 1. https://github.com/jgm/pandoc/issues/168#issuecomment-185169965

[uvtc]

I like that symmetry of using the colons for both the delimited div syntax and also for the side-marking div syntax. (And colons are one of the handful of characters that look pretty good as a side-marking character. Actually, they look good as a side-mark as well as bunched-up for start and end markers.)

I think long ago I suggested a side-marking syntax for divs, similar to what is used now for block quotes. This has the advantage that scope is visually clear. It is also very consistent with original Markdown, since we already have > for block quotes.

And, of course, also symmetrical with | for lineblocks.

*

Incidentally, I notice that if you currently write:

:{.some-class}
: this
: that
: other

it gives you a definition list (one term with multiple definitions).

[mb21]

Ultimately, I think both syntax proposals are pretty good; one is analogous to blockquotes, the other to fenced code blocks... so we could even have both, but preferably not I guess.

btw, why were fenced code blocks introduced in markdown processors (in addition to indented code blocks)? I suspect some of the reasons would apply to this discussion as well...

[bpj]

@jgm I think a side-marked div syntax would be very frustrating to use, because divs can be big, and you would have to remember to put the marker on every paragraph-ish throughout the div.

[van-de-bugger]

My two cents...

[regular span]{#id}

Looks very good for spans.

However, I do like neither === nor ::: for divs. ``` is ok for code blocks, but code blocks cannot be nested, while divs can.

I believe it is important to have different div begin and div end marks. It will help parser to detect missed mark.

Also, most programmers text editors can highlight matching brace/bracket/parenthesis and jump from open brace/bracket/parenthesis to closing one (and back). Thus, if div begin and div end marks are made of parenthesis-like characters (e. g. [[[ and ]]], or ((( and ))), or {{{ and }}}), we will have cool navigation across divs for free.

[ousia]

I think long ago I suggested a side-marking syntax for divs, similar to what is used now for block quotes. This has the advantage that scope is visually clear. It is also very consistent with original Markdown, since we already have > for block quotes.

And, of course, also symmetrical with | for lineblocks.

If you ask me, I must confess I hate both side–markings. I have no other choice than to use it for blockquotes. And lineblocks are even harder than the previous syntax (with the ending \). I avoid lineblocks as much as I can.

I agree, they may be visually clearer to read, but much harder to type. Please, don’t forget that Markdown users shouldn’t be compelled to use a text editor for programmers (what @jgm called “a decent editor” [some of us are “indecent users”]).

Probably

[regular brackets]

should not be a span. This occurs naturally in text.

And even in that case, I don’t think that a span without attributes makes much sense.

Also, most programmers text editors can highlight matching brace/bracket/parenthesis and jump from open brace/bracket/parenthesis to closing one (and back). Thus, if div begin and div end marks are made of parenthesis-like characters (e. g. [[[ and ]]], or ((( and ))), or {{{ and }}}), we will have cool navigation across divs for free.

{{{ and }}}) should be avoided, since attributes use {#id .class}. Too confusing (or misleading).

I think that for consistency with spans, [[[ and ]]] should be selected for divs. But @jgm is the one that has to decide this.

BTW, @jgm, I wonder why is [span] is the only natural way and it isn’t in the case of [[[division]]]. Visual and basic consistency for people (not in a logico–philosophical sense) is important for ordinary humans (they aren’t as familiar with computers as coders).

[van-de-bugger]

BTW, @jgm, I wonder why is [span] is the only natural way and it isn’t in the case of [[[division]]]`. Visual and basic consistency for people (not in a logico–philosophical sense) is important for ordinary humans (they aren’t as familiar with computers as coders).

BTW, can spans be nested?

Recently I added RDFa attributes to few my documents. I have managed it by m4, which inserts span elements, then md document with <span>s is passed to pandoc . I found that I need nested spans, e. g.:

RDF_DESCRIPTION({ RDF_NAME({ XXX }) is *RDF_HEADLINE({ RDF_KEYWORD({ 
... }) ... RDF_KEYWORD({ [...] }). })* ... XXX is RDF_KEYWORD({ 
RDF_OFFER({ RDF_PRICE({ 0.0 },{ free software }) }) }). })

[jgm]

+++ van-de-bugger [Feb 17 16 13:26 ]:

My two cents... [regular span]{#id}

Looks very good for spans.

However, I do like neither === nor ::: for divs. ``` is ok for code blocks, but code blocks cannot be nested, while divs can.

It's important to allow nesting. The way this would be done with ::: (say) is to say that the div ends when you hit a string of 3 or more colons that is longer than the string that opened the div. (We already have a similar rule for fenced code, to allow inclusion of lines with backticks in code, so this is consistent.)

:::::: outer div

::: inner div :::

outer again :::::::

I believe it is important to have different div begin and div end marks. It will help parser to detect missed delimiter.

Also, most programmers text editors can highlight matching brace/bracket/parenthesis and jump from open brace/bracket/parenthesis to closing one (and back). Thus, if div begin and div end marks are made of parenthesis-like characters (e. g. [[[ and ]]], or ((( and ))), or {{{ and }}}), we will have cool navigation across divs for free.

Yes, these are good points. But the [[[ format is really ugly and doesn't look natural to me in the source. I suppose one could do something like

[========= outer div

[== inner ==]

==========]