Support for custom injected classes or attributes

[jaywhj]

Does SuperFences support customizing injected classes and attributes? Or does it allow extending custom attributes?

Like supporting custom attributes without curly braces, for example:

```yaml hl_lines="6" linenums="10" title="xxx.yaml" data-download="https://xxx"

I'm not quite clear about the design philosophy behind attribute injection. Currently, it seems only the built-in attributes title, hl_lines, and linenums are supported.

Also, I have another question:Why is the following syntax valid?

```yaml {data-download="blob"}

But this syntax causes rendering issues?

```yaml title="123" {data-download="blob"}

[facelessuser]

1. attributes and are enabled only with the attr_list extension, using their format ({}).
2. When not using attr_list, any key=value pair is treated as options for the current SuperFence parser, not as HTML attributes.

In short, adding attributes is done through attr_list using their format {}. If you aren't using the {} format (with the attr_list extension), attributes are not applied.

```yaml {data-download="blob"}

This format is allowed specifically to provide compatibility when parsing content from other parsers. Paired with relaxed_headers, you can also ignore erroneous syntax after the code block name that allows blocks to behave more like how GitHub and some other parsers handle such content.

Originally, the legacy approach was similar to CodeHilite: key=value was only treated as options to the Pygments parser. We added attr_list style attributes on top. Later, we expanded the options and attributes to live together within {}. We keep both the non-{} and {} for legacy compatibility. If I had my way, I'd probably consolidate them to {}.

[jaywhj]

Yes, I have already enabled attr_list.

In other words, are the brace‑free attributes designed just for compatibility with legacy syntax? Is using curly braces for all attributes the more standard and recommended approach?

However, most users of mkdocs-material and zensical have already gotten used to writing attributes without curly braces. It would be ideal if there were a class or extension that could automatically convert brace‑free syntax into the braced format.

For example, this used to be valid:

```yaml title="123"

However, after I added an attribute wrapped in curly braces, it became invalid — either the page renders incorrectly or the feature stops working. (I just tested it: setting relaxed_headers to true can filter invalid syntax and keep the page rendering normal, yet the feature still does not take effect):

```yaml title="123" {data-download="blob"}

But this form works fine:

```yaml {data-download="blob"}

This inconsistent behavior is quite confusing for end users and unnecessarily raises the learning and usage barrier.

[facelessuser]

Do one or the other:

```yaml title="123"

or

```yaml {title="123" data-download="blob"}

[jaywhj]

Since you've implemented special handling for attributes such as hl_lines, linenums, and title, would it be feasible to extend the design to support all custom attributes?

For example, automatically convert the syntax without curly braces into the curly‑brace format.

[facelessuser]

Since you've implemented special handling for attributes such as hl_lines, linenums, and title, would it be feasible to extend the design to support all custom attributes?

I'm not sure what you mean by this statement.

What I will say is that non-bracketed are a holdover from CodeHilite as originally, we provided a bridge between CodeHilite and SuperFences. But general HTLL attribute support is done with the bracket logic and requires attr_list to be enabled. Currently, we don't have plans to add HTML attribute support without attr_list in a non-bracket form.