Spec bug: Arbitrary CSS classes from fenced code blocks

Spec
1

The spec says that the fenced code block info string is used to populate the class attribute of the <pre> tag.

An info string can be provided after the opening code fence. Opening and closing spaces will be stripped, and the first word is used here to populate the class attribute of the enclosing pre tag.

However, this is dangerous. Consider the following CSS and Markdown:

.spin {
  animation: spin 2s infinite linear;
}

```spin
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (continued)
```
```spin
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (continued)
```
```spin
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (continued)
```

You now have the ability for people to cause visual “griefing” via constantly spinning lines of text.

It would be safer to put the info string into a data- attribute, or a prefixed CSS class.

2

“Don’t do that then.” This is a job for a user-submitted-content sanitizer, not for Markdown proper. (In other words: if I’m the sole author of a document I ought to be able to set my CSS classes to whatever I damn well please.)

4 Likes
3

I’m still worried about conflicts, e.g. in cases like

```c
int main(void) {
    return 0;
}
```

What if you are using the .c class somewhere else?

It should use something like “code-c”.

Yes, but you can still do that with the HTML elements.

4

There could be an unintentional name collision with existing classes on a page however. For example, reddit.com uses .title for various elements. If ```title results in <div class="title">, then that causes an issue.

1 Like
6

That seems like a good idea, however I think that’s some kind of implementation detail that should be left to the implementation. I could imagine having a preference of some kind for “code class prefix” or something like that.

1 Like
7

This thread gives a pretty good solution.

2 Likes