\
**Category:** Spec\
**Created:** [September 15, 2014, 6:28pm UTC](https://talk.commonmark.org/t/drawing-a-distinction-between-html-block-elements-non-element-tags/606 "2014-09-15T18:28:15Z")\
**Posts on this page:** 3\
**Page:** 1
**Author:**  [@Burt\_Harris](https://talk.commonmark.org/u/Burt_Harris)\
**Post date:** [September 15, 2014, 6:28pm UTC](https://talk.commonmark.org/t/drawing-a-distinction-between-html-block-elements-non-element-tags/606/1 "2014-09-15T18:28:15Z")
The CommonMark spec has a good definition of [HTML block tag](http://jgm.github.io/stmd/spec.html#html-blocks) in section 4.6. This includes a specific list of tags considered to be blocks, which is great. The list of block tags is critical in CommonMark because it takes a blank line to end an HTML block. For non-block HTML tags, we don’t want HTML block processing, so that for example, the 2nd and 3rd lines below are treated as CommonMark list items, and not part of the HTML.
```auto
Underlined Heading
* List Item
* List Item
```
The way CommonMark handles the above is pure goodness. But in the next paragraph the spec lumps this well thought out concept with four other non-element tags: HTML Coments, declarations, processing instructions, and CDATA Sections.
While the angle brackets make these all look visually similar, I wonder if we shouldn’t do a better job on preventing the HTML block mechanism kicking in inappropriately for these other SGML-inspired non-element tags.
For example, let’s start with comments:
```auto
# Introduction #
```
I propose the right HTML output for this should be
```auto
Introduction
```
But instead, the spec currently considers the Introduction heading to be part of an HTML block, and fails to convert it to a heading, producing exactly what was input:
```auto
# Introduction #
```
This same problem occurs for declarations, processing instructions, and CDATA sections, _unless a blank line follows them_. But that seems unnecessary because an important distinction between block HTML and these earlier SGML notations is easy while finding the end of an HTML block might be difficult.
I don’t remember ever seeing a need for nesting these non-HTML element tags, so I so I think we could just define them with the following terminators, and allow use of backslash escaping to resolve any conflicts.
> ```
> `-->` for a comment.
> `>` for a declaration
> `?>` for a processing instruction
> `]]>` for CDATA
>
> ```
Making this work right would be helpful in introduction of a [`` declaration](http://talk.commonmark.org/t/the-case-for-a-commonmark-declaration-tag/584/2).
---
**Author:**  [@Burt\_Harris](https://talk.commonmark.org/u/Burt_Harris)\
**Post date:** [September 16, 2014, 5:15am UTC](https://talk.commonmark.org/t/drawing-a-distinction-between-html-block-elements-non-element-tags/606/2 "2014-09-16T05:15:43Z")
Another counter-intuitive case:
```auto
What about **this**.
```
geneates HTML containing stars, while
```auto
What about **this**.
```
generates emphasis on the word this.
Any thoughts about how to deal with the former?
---
**Author:**  [@joallard](https://talk.commonmark.org/u/joallard)\
**Post date:** [October 3, 2014, 9:20pm UTC](https://talk.commonmark.org/t/drawing-a-distinction-between-html-block-elements-non-element-tags/606/3 "2014-10-03T21:20:27Z")
Totally agree, just got surprised by such a snippet:
```md
### Communications Director
The Director of Communications is responsible for public communications,
online and offline.
```
Just for fun, I copy-pasted this exact markup right here, and added blockquote marks:
> ### Communications Director
>
> The Director of Communications is responsible for public communications,
> online and offline.
(I use the comments for Vim-diff to keep track of position across translated documents)