What could a "spoiler tag" extension look like?

Extensions
49

I’ve handwritten and edited quotes numerous times. For example, when writing down a quote that is in printed material, embedded in an image or heard in spoken audio.

Agreed that we cannot make the assumption that the writer is using a specific editor. If the writer is quoting large blocks of text, perhaps they are an advanced user and likely to be using a more sophisticated editor? It would be good to see some use cases for long quotes. From my experience in academia it was generally frowned upon to quote more than a few paragraphs at a time; long quotes are at the expense of original content (perhaps @jgm would like to weigh in here).

With line blocks for song lyrics I can see a potential issue for marking up lengthy multi-paragraph songs.

If it is decided that a block syntax is necessary, perhaps we could use the same marker for familiarity, similar to how fenced code blocks use the same backtick as inline code:

>>>
This is a blockquote

Covering three paragraphs

Final paragraph
>>>

This could be an alternative to:

> This is a blockquote
>
> Covering three paragraphs
>
> Final paragraph

And for line blocks:

|||
This is a line block

Covering three paragraphs

Final paragraph
|||

This could be an alternative to:

| This is a blockquote
|
| Covering three paragraphs
|
| Final paragraph

I’m not entirely convinced of the need for this but it’s worth looking at options.

2 Likes
50

At this point, I see a block directive as basically a div that in addition to containing block elements, has:

  1. inline content
  2. a name (could be rendered as a HTML5 custom tag)

In absence of a filter or something handling a directive, a div is a natural fallback.

1 Like
51

To quickly recap the arguments in favour of each div-syntax proposal (nobody seems to like indented syntax):

Side-marking

  • more readable for long sections (because it’s always obvious that you’re in a div-environment, even if the section is longer than the height of your screen)
  • more local (removing one line doesn’t change large parts of your document)

Surround-marking

  • more readable for short sections (because of the almost-line-long surrounding markers)
  • doesn’t require a decent editor to write easily
  • better for copy’n’pasting / wrapping existing stuff in a div
3 Likes
52

I’d say, both should be supported at the end. Because side-marking is nice for small peaces of text. But, side-marking needs much work. Surround-marking is fenced-blocks like, and can be accepted very easy.

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.

2 Likes
53

I agree. And the longer I think about it, the more I’m convinced that we should go for surround-marking for now. An alternative side-marking syntax could still be implemented later if needed.

1 Like
54

+++ 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)?

1 Like
55

I’ve written, that those are unuseable in current state, not unuseable at all. It was in context of comparison “what is more simple”: (a) finilize attributes spec a then consider fenced style divs or (b) consider fenced style divs and then work with attributes.

56

It would be good to see some real world examples of where the current syntax is unusable.

57

We mentioned it multiple times in different topics. In all cases, where container content needs different styling & still should have markup:

  • collapsable spoiler, with title (layout, style)
  • spoiler with hidden visibility (style)
  • sidenotes, epigraphs, … (style)
  • lyrics in text (style) (if you keep \n, hard breaks can be forced vith CSS for specific divs)
  • forum quotes (source post & user info, layout, style)

That’s not complete list, only examples that i can remember immediately. But it’s enougth to demonstrate, that problem is not in single case.

Under style i mean everything, that can be done via CSS. That means, such blocks should have custom CSS class. All examples above need markup in content and can’t be implemented via fenced blocks (at least, without dirty hacks). Also, those need metadata (custom class name at least) and can’t be implemented via blockqoutes now.

I don’t see big technical problem to quickly add such blocks support to remarkable, but don’t like to introduce one more syntax and split community one more time. With plans about my own projects i can wait about 1-2 months, if there is any hope that at least 1 type of “normal” DIV will appear in spec. At least in draft state.

1 Like
58

Agreed. This discussion about <div> block syntax sounds related to Content Block/Inline Syntax

I haven’t seen any objection for fenced ::: as the <div> block syntax. And I think it’s also a good candidate for fencing generic detectives that can fall back as normal content.

Since github does (where ‘ruby’ is a css class name I think):

```ruby
require 'redcarpet'
markdown = Redcarpet.new("Hello World!")
puts markdown.to_html
```

then a direct eqv using the spoiler example for div would be:

:::spoiler
spoiler content here
:::

to which we can prettify it like so (perhaps classnames should have no spacing):

:::::::spoiler::::::::
spoiler content here
::::::::::::::::::::::

What do you think about this approach @vitaly ?

1 Like
59

I don’t think we should be rushing new syntax additions, even if draft state, based on other project requirements. Refer to @codinghorror’s comment in the strikethrough topic; extensions are not the priority over the next six months.

My suggestion is that you use raw HTML in the meantime which is already included in the spec.

60

Most of these wouldn’t require a div. They could be marked up with either blockquotes or line blocks (pre), plus additional markup for the extra data. Here’s what I suggest:

  • Collapsable spoiler, with title. Use the blockquote syntax with a class for spoiler. Set a parser rule to make a heading and/or link directly before the blockquote the collapsable title.
  • Spoiler with hidden visibility. Blockquote with spoiler CSS class.
  • Sidenotes, epigraphs. The proposed line block syntax (|) with a specific class.
  • Lyrics in text. Line blocks again.
  • Forum quotes (source post & user info). Perhaps a blockquote/definition list combination, I’m not sure. Discourse solves this very specific requirement by using a custom tag instead of Markdown. Blockquote seems like the right element to use in any case.

The problem with using the div tag is that is contains no semantic meaning other than being a container. The HTML5 spec even advises against using it (emphasis added):

Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors.

This is a strong indicator that the div element should not have it’s own Markdown syntax, even as an extension. We should aim to add more semantic elements on a case by case basis instead.

61

There are no need to blindly follow abstract principles, if it cost nothing to satisfy more people in shorter time by swapping order of 2 steps. I’ve explained above, that 1/2 of DIV spec (for fenced style) needs very few work for acceptance.

May be i have wrong estimate about efforts. But at least, nobody said the opposite.

I would do it, but it’s not acceptable. @chrisalley, i’m not going to push anyone for making fast decisions. I just share info, to better plan my own work. Because if alternatives possible, i’ll select one, which is better for CommonMark.

1 Like
62

Comment about how div is still needed for practicality, even if we seek for mostly semantic tag. Moved to Content Block/Inline Syntax

1 Like
63

IMHO you mix completely different things. You explain that “fenced container” not needed, because it can be replaced by several things, that not exists now but will be available sometime :slight_smile: .

  1. Those are needed anyway, it’s a question of usability and preferences. For example, i don’t need lyrics, but i don’t say that line blocks are useless.
  2. Fenced blocks can be accepted faster, that other. I never said, that those are better or more important. I said, that now we have no containers at all with full attributes support, and it worth to accept at least one type. Then i explained, that acceptance of fenced block is the most easy in terms of time and efforts, not because i like those.
1 Like
64

There are quite a few different proposals being made here which has complicated the discussion.

I’ve outlined why there’s an issue with fenced blocks being used for <div>'s (very applicable to the use case of spoilers).

That leaves line blocks and blockquotes, which have proposals for both side-marking and proposals for fenced block styles.

Line blocks that are side marked are a natural extension of sidemarked blockquotes which are already in the spec. It seems likely that sidemarked line blocks will become an extension.

Given this likelihood, if fenced blockquotes and line blocks are added they would be in addition to the sidemarked blocks, and so may not be needed if sidemarked blocks are sufficient.

The question (I think) @jgm was asking is why either sidemarked blockquotes or lineblocks are unusable in their current state? I suggested that it would be good to see some real world examples of the sidemarking syntax creating problems for the writer. Examples of actual text, rather than lists of features.

65

Let’s clarify. DIV is HTML term. We are speaking about block containers, not divs. Term DIV was used with meaning “block element with markup content”. Representation depends on renderer. For example, spoiler can be rendered to several nested divs. Other containers can be rendered to articles, sections, asides and anything else.

Probably, i missunderstood you, because your replied to my post. None of listed examples can be now expressed with sidemarking, because the only existing container (blockquote) in current state do not support attributes. That’s the root of problem. I would agree to use sidemarking as temporary solution, if attributes are supported. But i don’t believe, that it’s possible to add attributes support in reasonable time.

There are no reasons to say, that one type of block is better than another one. That depends on content type, size, editor and user preference. Even in this thread >1 users prefer sidemarking and >1 users prefer fencing.

1 Like
66

Forgive me for bumbling in but I really want this feature now that me and my team have a use case for it.

I’m assuming that because the discussion has shifted from ‘what should the markdown look-like to users’ to ‘how many div tags should we use and by the way what exactly is a div tag anyways’ that this issue has been sort’ve accepted. But the last post on this issue is from last year and I’m not sure where it would move forward. Any news?

The use case I’ve got is, on github, my team now reads and votes on issues before sprint kickoff. Right now those votes are just plaintext as comments, so if you’re voting as a junior dev and a senior dev has already voted you cant help but be biased by glancing at the comments. I’d like to put the votes in spoiler tags so that a reader has to have an explicit intent to see the vote. I noticed that stackoverflow was already doing this with a scheme that was perfect for my use case, but github was not.

Again, for this use case, the >! syntax is pretty good. It might get a little terse if vote-commenters simply do

>! 3

instead of

>! my vote is 3 points

but terse comments aren’t really markdowns fault (or problem).

Alternatively this could be a feature request with github. A reasonably elegant work-around would be to leverage the systems typically put in to reduce spam. If Github supported a ‘flag this comment’, which hid the comment (a le youtube or stack overflow), I could leverage that system to achieve this goal.

my .02, hope this happens soon!

67

>! probably would work neatly and the nice thing of it is that a diff-view extension would fit as well as
>+ and >-.

a spoiler can still be implemented attaching the css class to a normal blockquote.

>
>  Fooo
>
{: class}
68

+++ Groostav [Apr 23 15 21:00 ]:

I’m assuming that because the discussion has shifted from ‘what should the markdown look-like to users’ to ‘how many div tags should we use and by the way what exactly is a div tag anyways’ that this issue has been sort’ve accepted. But the last post on this issue is from last year and I’m not sure where it would move forward. Any news?

No proposal has been accepted.

The use case I’ve got is, on github, my team now reads and votes on issues before sprint kickoff. Right now those votes are just plaintext as comments, so if you’re voting as a junior dev and a senior dev has already voted you cant help but be biased by glancing at the comments. I’d like to put the votes in spoiler tags so that a reader has to have an explicit intent to see the vote. I noticed that stackoverflow was already doing this with a scheme that was perfect for my use case, but github was not.

I’m a bit unclear about what you’re looking for. If you’re trying to do this on github, then only changes to github’s Markdown processor will help you, and this isn’t the right place to be asking.

If you’re asking how one might achieve this with a setup that used a CommonMark parser, then it seems to me that you could achieve what you want without any syntax changes at all, by establishing conventions.

For example, you could establish the convention that any block quote beginning with a single ! will be treated as a spoiler. On the server, you’d then walk the AST after parsing, looking for blockquotes that fit this description, and inserting some raw HTML around them to make them display hidden by default, with a button to display them.

No fancy block attribute syntax is needed for this, and there are some advantages to NOT using a fancy block attribute syntax (your document will degrade nicely on github or another Markdown renderer). Note also that, even if there were a fancy block attribute syntax, you’d still have to do some custom processing of the AST. Although we might consider generic block attribute syntax, “spoiler” seems far too specialized a thing to be part of the spec.