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. Syntax for divs #168 (comment)

[uvtc]

It does seem a little inconsistent that this syntax

{.foo #bar}
    Lorem ipsum dolor sit amet, consectetur adipiscing elit,
    sed do eiusmod tempor incididunt ut labore et dolore
    magna aliqua. Ut enim ad minim veniam, quis nostrud.

(where you're combining the {...} with the indented block syntax) would specifically mean a div, yet if one could add attributes to other blocks, for example

~~~{.foo #bar}
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore
magna aliqua. Ut enim ad minim veniam, quis nostrud.
~~~

:::{.foo #bar}
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore
magna aliqua. Ut enim ad minim veniam, quis nostrud.
:::

the addition of the attribute is separate from the syntax of the block. Sorry, not sure if that's worded very clearly...

In other words: if a writer learns the general rule that you can mark a block with {...} to add attributes, then the indented div syntax really does look like you're adding attributes to a code block.

Maybe there should be different rules for adding attributes to side-marked blocks vs adding them to delimited blocks. If so, then the indented div syntax muddies the waters of that distinction.

[uvtc]

Some points regarding side-marked div syntax (I'm already sold on ::: delim div syntax):

• It would be unusual to make a div (side-marked or delimited/fenced) without attributes. For this reason, the {} could be made mandatory for :-side-marked divs to avoid any conflict with definition list syntax.
• since divs are often nested, it would be easier to read if there were two different side-markers that could be used.
• divs are often used for warnings/notices/errors/admonitions

I've complained in the past about using ! as a side-marker for anything other than warnings/errors/etc, but

• I understand that some people like it,
• it is one of the few visually useful tall thin side-marker characters,
• it's great for warnings/notices/errors

Consider this syntax for side-marked divs:

{.info #bar}
: side-marked div block with attributes.
: Lorem ipsum dolor sit amet, consectetur
: adipiscing elit, sed do eiusmod tempor.
: incididunt ut labore et dolore magna.
:
: {.warning}
: ! For maximum flakiness, remove
: ! crust from toaster oven after
: ! it turns tacit brown but before
: ! it turns falsetto brown.
:
: Second paragraph. Aliqua ut enim ad
: minim veniam, quis nostrud exercitation
: sulaco dusty vanagon.


{}
: side-marked div block with no attribs.
: Lorem ipsum dolor sit amet, consectetur
: adipiscing elit, sed do eiusmod tempor.
: incididunt ut labore et dolore magna.


! side-marked div block with no attribs.
! No leading `{}` needed when using `!`'s.
! Lorem ipsum dolor sit amet, consectetur
! adipiscing elit, sed do eiusmod tempor.
! incididunt ut labore et dolore magna.

Regarding generic syntax for marking attributes on blocks, while you could leave the future option open for adding attributes to anything side-marked or delimited (line blocks, blockquotes, paragraphs (!)), for now just white-list:

• sidemarked blocks that can have attribs: divs
• delimited/fenced blocks that can have attribs: divs and code blocks

I think the syntax being discussed here (::: delimiters and :|! side-mark) both look good, and suspect they'd probably see fairly equal usage. This has been my experience with code block syntax btw (though, I don't typically ever use ```, as I think ~~~ looks much better).

[mb21]

While side-marking (and maybe even an indentation-based syntax) have their advantages
for certain use cases as well, I think it's fair to say that surround-marking
(aka delimited) is the least controversial. So let's focus on its variants for now.

Of the some-character-followed-by-`---`-variants, the following
two seem the most popular:

; --------------- info -------------------- {.class #ident}
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore

Another paragraph here.
; ---------------------------------------------------------

(Btw, I'm posting this comment as one big code block, so we get an example of
how the different div syntax proposals look among some blocks of text.)

:--------------- info -------------------- {.class #ident}
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore

Another paragraph here.
:---------------------------------------------------------

Then, there is the simplicity of using only one character. AFAIK, the following
two markers seem to fit best and cleash least with existing markers.

:::::::::::::::::::: info ::::::::::::::::: {.class #ident}
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore

Another paragraph here.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::

Yes, the dots in the following example are a bit low on the line, but why not?

..................... info ............... {.class #ident}
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore

Another paragraph here.
.........................................................

It's true that both the colons and dots are a bit more bulkish than the slender
dashes. But I kind of like that aspect: the div stands out in a long document
and is clearly differentiated from headings and horizontal-rules, which already
use dashes.

Finally, while I like some more than others, I really think all of the examples
I just listed here are fine.

[iandol]

This thread reminds me of what it is like in my brain when choosing food in a Cantonese restaurant... 😄

So many factors, I am quite persuaded by the recent worries against indentation, and then we are left with delimited vs. side marking, and I think the practicality during writing of delimiting wins. And I think the : has the upper hand overall, so i vote for:

:::::::::::::::::::: info ::::::::::::::::: {.class #ident}
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore
:::::::::::::::::::::::::::::::::::::::::::::

[Drezil]

So to sum the last posts up (before things start to drag along for years again -.-) i see the following trends in the discussion:

For delimited syntax we seem to have a winner (voted for: DaveJarvis, uvtc, iandol, me; proposed at least as option by: mb21, ickc; voted against: noone):

::: {.class #id}
text here
:::

with possible expansions (at least 3 :) and an interspersed class:

:::::::::::::::: oneClassName ::::::: {.allOther #attributes}
foo
:::::::::::::::::::::::::

Further discussion-point for delimited syntax:

• should we allow other chars than : like ., -, etc.?

---

For the side-marking syntax there was suggested:

{.any #attributes .orEmpty}
: this is sidemarked
: Lorem ipsum..
: you know what i mean

! sidemarked without
! special {}-Attribute
! at the beginning of the line
! though it can also be added

I personally would prefer having : play the role of ! in the latter example - but i don't know if that would clash with Description-Lists.

Further discussion-point for side-marked syntax:

• does : side-markings indeed clash with description-lists?
• what chars would be allowed under which circumstances? (like above: ! always? : only with Attr in front?)
• should we allow any other chars beside : or !? The same as with delimited-syntax?

[uvtc]

This thread reminds me of what it is like in my brain when choosing food in a Cantonese restaurant... 😄

Although there's a lot here, for me, this thread (reading, and contributing to it) has helped clarify a number of things about Pandoc Markdown. I've seen better and better suggestions, and changed my mind on at least a few things. Some bits I've learned:

• side-marked blocks are more markdownish: generally easier to read, more work to write, tends to look better. Side-note: there are precious few really good ascii side-marker characters.

• delimited blocks are less markdownish, but convenient (sometimes, much more convenient): easy to write, generally don't look quite as nice as side-marked blocks.

• it's not necessarily required, or even advised, to try and use the same character for both a side-marked and a delimited syntax for a given type of block. Example 1: code blocks use spaces for side-marking, but ~~~ (or ```) for delimiting. Example 2: blockquotes use > for side-marking, but don't/can't use >>> for delimiting because that already means a twice-nested blockquote.

  {.proposal}
  ! Given that last bullet point, if going ahead
  ! with a *side-marked* div syntax, it would
  ! probably make sense for now to only allow `!`
  ! and not `:`. I must admit that `!` is the
  ! better side-marker. Add to that that it may
  ! be visually confusing/inconsistent to use a
  ! list marker (`:` in definiton lists) also as
  ! a side-marker.
  

• commonly-used/needed syntax must look good to be acceptable (ex. > for blockquotes). This also implies that side-markers should be at least vertical-ish, and delimiter characters should be at least passably flat-ish (::: is a pretty good compromise as a delimiter, in that it's symmetrical, centered, not too heavy on the page, and the character isn't already used for HRs, tables, or headings.)

  One initial litmus test I have for a prospective new markdown syntax: given a reader seeing the new syntax once or twice, will they instantly understand what it means and then maybe even naturally start using it themselves without being told it's markdown syntax? If the answer is "yes", then it may be a good idea.

• it's becoming common usage to add attributes to blocks and spans using ~~~{.foo #bar} and [can of span]{.foo #bar}. ...But probably not everything can or should support attribute syntax (for example, indented code blocks, list items, paragraphs).

• any new syntax added should not look too much like markup (but should look good). Hence, Markdown/Pandoc prefers delimiters like ~~~ ... ~~~ rather than "opening/closing" ones like [[[ ... ]]]. I think an issue with ;--- is that it looks more like markup than :::.

• There is strong hesitance to breaking backcompat (ex. stealing | to use for side-marked divs).

• There is strong hesitance to making pandoc markdown more strict (for example, requiring blank lines below setext headers and around HRs, which might then allow --- and === delimited divs).

• Pandoc Markdown supports "laziness" for list items. Trying to come up with a lazy variant for everything (ex. a lazy-style div block) may lead to unhealthy (er, unhealthier) amounts of bike-shedding.

• Markdown sometimes offers multiple ways do the same thing (ex. italics, bold, list item markers). It's useful for very commonly-used syntax when you want to make nested parts look different from eachother (like nested list markers, or * a *cool* list item vs * a _cool_ list item), or when people have their own hardwired text/email habits (some people just like - or + instead of * for lists). But given how quickly that uses up markup characters (and adds parsing complexity), not sure I'd do that for new --- and assumedly less-often-used --- syntax.

• Given that = and - are already so overloaded (used in setext headings, tables, and HRs), and that a blank line after an setext heading marker is optional, it's exceedingly difficult to use = or - for any additional syntax.

[uvtc]

One qualm: if the side-marked syntax is supposed to be the handsomer more markdownish one, it should as a special case provide a less-marked-up-looking syntax for when supplying exactly one class to the div. Could this:

Note:
! Lorem ipsum dolor sit amet, consectetur adipiscing
! elit, sed do eiusmod tempor incididunt ut labore et
! dolore magna aliqua. Ut enim ad minim veniam, quis
! nostrud exercitation ullamco laboris nisi ut
! aliquip ex ea commodo consequat. Duis aute irure
! dolor in reprehenderit in voluptate velit esse cil.

work as a synonym for:

{.note}
! Lorem ipsum dolor sit amet, consectetur adipiscing
! elit, sed do eiusmod tempor incididunt ut labore et
! dolore magna aliqua. Ut enim ad minim veniam, quis
! nostrud exercitation ullamco laboris nisi ut
! aliquip ex ea commodo consequat. Duis aute irure
! dolor in reprehenderit in voluptate velit esse cil.

?

[Drezil]

I updated my PR to reflect the new syntax.

Two minor things that came up:

• The ! leading on line clash with ![](...) so i had to add a special case in birdTrackLine
• Having

  ! foo
  ! ! nested
  

  would not parse as expected (as foo is parsed as inline and parses for blocks are then already done), whereas

  ! foo
  ! 
  ! ! nested
  

  works fine.
  Same with

  sominline
  ! suddenlyBlock
  

  I think this comes up in some other places as well (where block & inline gets mixed) - so i don't know if that behaviour is intended.

Otherwise the testcases should be complete.

[ghost]

Additional test cases to consider (content and closing ::: removed for brevity):

:::info

::: info {.combine}

::: !info

::: {#id}

::: {#{id}

::: {#\{id}

::: {.class #id}

::: {.-1}

:::#id

::: #id

::: #id:class

::: #識別子

::: #{.class}

::: ###id

::: #id #id

::: #id #info

::: #id #info #bar

::: #id #info {.class}

::: #id ::: #info :: {.class}

[tarleb]

Awesome 🎉 😄 🎆

[saivan]

WOW! ITS DONE! 🎈 🎈 🎈
Great job guys! :)

[alerque]

I think I hear an angel choir…

[sergiocorreia]

Same here! It took a while but this looks amazing!!!

[mb21]

This is great, really happy to see this arriving!

Two things:

1. Maybe add the following sentence to the MANUAL:

   The attributes can also be replaced with a single word which will form the class name.
   

2. Add and fix the following test case (And another should be Para instead of Plain)

   % pandoc -t native
   ::::: Warning
   Here is a paragraph.
   
   And another.
   :::::
   ^D
   [Div ("",["Warning"],[])
    [Para [Str "Here",Space,Str "is",Space,Str "a",Space,Str "paragraph."]
    ,Para [Str "And",Space,Str "another."]]]
   

[jgm]

Good suggestions, I've just done both. +++ Mauro Bieg [Oct 24 17 14:58 ]:

…

This is great, really happy to see this arriving! Two things: 1. Maybe add the following sentence to the MANUAL: The attributes can also be replaced with a single word which will form the class name. 2. Add and fix the following test case (And another should be Para instead of Plain) % pandoc -t native ::::: Warning Here is a paragraph. And another. ::::: ^D [Div ("",["Warning"],[]) [Para [Str "Here",Space,Str "is",Space,Str "a",Space,Str "paragraph."] ,Para [Str "And",Space,Str "another."]]] — You are receiving this because you modified the open/close state. Reply to this email directly, [1]view it on GitHub, or [2]mute the thread. References 1. #168 (comment) 2. https://github.com/notifications/unsubscribe-auth/AAAL5D1LZG7SgPA2N-t4Rzm_6heK-fJVks5svfsIgaJpZM4AOGXV

[ousia]

Many thanks for this implementation.

[bpj]

At last! 👍 🎆
Really good news, I'm really happy. Thanks to everyone who contributed!

[simonmichael]

Just curious, and I hope I don't open a can of worms, but was the idea of a side-marked syntax dropped ?

Thanks for all the care that was put into this.

[jgm]

+++ Simon Michael [Oct 30 17 07:25 ]:

Just curious, and I hope I don't open a can of worms, but was the idea of a side-marked syntax dropped ?

I wanted to keep it simple, I guess. We could reconsider a side-marked syntax later, but let's see how this works out.

[chaoxu]

It's been a year, are we interested in discussing side-marked syntax again? Indentation is great. How about the following one. It avoids fences, and use indentation.

::: block title
    block contents spanning
    multiple lines.
    yeah.