# What could a "spoiler tag" extension look like?

**URL:** <https://talk.commonmark.org/t/what-could-a-spoiler-tag-extension-look-like/767>\
**Category:** Extensions\
**Created:** [October 6, 2014, 4:05am UTC](https://talk.commonmark.org/t/what-could-a-spoiler-tag-extension-look-like/767 "2014-10-06T04:05:05Z")\
**Posts on this page:** 1\
**Showing post:** 54

<div class="post-metadata">

**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\
**Post date:** [November 3, 2014, 10:58pm UTC](https://talk.commonmark.org/t/what-could-a-spoiler-tag-extension-look-like/767/54 "2014-11-03T22:58:47Z")

</div>

+++ Vitaly Puzrin [Nov 03 14 13:25]:

> For me, it’s more management question, how to reorder spec priorities. Having one well working DIV markup is much better than having zero. I don’t count blockquotes, because i think those are unusable in current state.

Blockquotes are just a form of side-marking, and you don’t seem to be against side-marking in principle. Blockquotes can already contain arbitrary block elements. Why are they “unusuable” (supposing a mechanism was provided to add attributes)?

---

_[View the full topic](https://talk.commonmark.org/t/what-could-a-spoiler-tag-extension-look-like/767)._