Explicit section not possible?

Extensions
1

From HTML: The Living Standard

For the following fragment:

<body>
 <h1>Foo</h1>
 <h2>Bar</h2>
 <blockquote>
  <h3>Bla</h3>
 </blockquote>
 <p>Baz</p>
 <h2>Quux</h2>
 <section>
  <h3>Thud</h3>
 </section>
 <p>Grunt</p>
</body>

…the structure would be:

  1. Foo (heading of explicit body section, containing the “Grunt” paragraph)
  2. Bar (heading starting implied section, containing a block quote and the “Baz” paragraph)
  3. Quux (heading starting implied section with no content other than the heading itself)
  4. Thud (heading of explicit section section)

Notice how the section ends the earlier implicit section so that a later paragraph (“Grunt”) is back at the top level.

Is explicit section is not possible in pure markdown ?

2

It’s possible via html blocks injection.

3

I would like to be able to type:

# Foo

## Bar

p

and have:

<h1>Foo</h1>
<section>
  <h1>Bar</h1>
  <p>p</p>
</section>
4

This is exactly what pandoc’s --section-div flag does. Remember that CommonMark specifies primarily an AST and that the HTML examples are only one valid serialization of that AST.

$ pandoc --section-divs -t html5
# Foo

## Bar

p

<section id="foo" class="level1">
<h1>Foo</h1>
<section id="bar" class="level2">
<h2>Bar</h2>
<p>p</p>
</section>
</section>
3 Likes
5

AFAIU, the current spec treats this snippet as a flat AST such as:

  • h1: Foo
  • h2: Bar
  • paragraph: p

If it was treated as this instead:

  • h1: Foo
  • section
    • h1: Bar
  • paragraph: p

it would make the hierachiecal interpretation standard instead of relying on the implementation to rebuild the structure from the flat view.

From the hierachical AST, it is easy to uild the both the hierachical serialisation and the flat one.

6

Attempting to place attributes to sections to allow for easier slideshow coding. Metadata in documents

Harder than it seems (anything not recognized as valid html attribute is displayed as a div):

----
:id: slide1
:class: slidestyle
note: this is a test slide    

# slide title

normal text here

---

renders as

 <hr>

 <section id="slide1" style="slidestyle" >
  <div class="metadata note" > this is a test slide </div>
  <h1> slide title </h1>
  <p> normal text here </p>
 </section>

 <hr>

edit: To into consideration that people may display addresses on the “metadata field”, so better give people the option of displaying it or not.

7

+++ Randomstuff [Oct 29 14 22:49 ]:

AFAIU, the current spec treats this snippet as a flat AST such as:

  • h1: Foo
  • h2: Bar
  • paragraph: p

If it was treated as this instead:

  • h1: Foo
  • section
    • h1: Bar
  • paragraph: p

it would make the hierachiecal interpretation standard instead of relying on the implementation to rebuild the structure from the flat view.

Well, in Markdown these two documents are different:

# Foo

### Bar
p

# Foo

## Bar
p

On your proposal, as I understand it, they’d be parsed into the same AST, so there’d be no way to go back; information would be lost. The problem is that there are multiple flat structures corresponding to a single hierarchical structure.

8

Markdown was created in the XHTML era, whereas <section> is from HTML5, so it wouldn’t have been a consideration.

The use of sections is considered good practice. It’s worth taking a step back and asking if they need to be explicit in Markdown. A rule could be added to the parser to add opening and closing HTML section tags based on the header level. This would cover a lot of cases and save the writer from having to explicitly add them. We’re then left asking how to implement sections for only the sections that do not follow a pattern based on heading level.

9

Well if we consider section+header > header in the hirachy of importance then could we do this via flowerbox headers? e.g. with mb21 example, we would instead type

======================
 Foo 
======================

---------------
 Bar
---------------

p
1 Like
10

There may be no need for any kind of explicit section syntax. Instead, just get the parser to add the sections based on a parser flag and the locations of the headings. This would be an extension to the default rendering mode (no sections). Adding the sections based on implicit considerations keeps the document significantly lighter; this feels more inline with the rest of Markdown.

4 Likes
11

There maybe be no need for any kind of explicit section syntac but if people want to reliably markup sections using the existing syntax, there probably needs to be an interoperable way to infer section from the existing markup (i.e. write the algorihm in some spec). And it might be useful to be able to add classes (and other attributes) to the sections. Another possible need which is not covered at all is how to end a section.

1 Like