Filter tips improperly strips markup attributes/elements.

Does the class attribute not work?

On testing further, it does seems to affect a lot of markup besides style - for example, one of my macros should do the following:

Turn this

[spoiler]Hidden text[/spoiler]

into the output of this twig template:

{% set id = random() %}
<input id="xbbcode-spoiler-{{ id }}" type="checkbox" class="xbbcode-spoiler" />
<label class="xbbcode-spoiler" for="xbbcode-spoiler-{{ id }}">{{ tag.content }}</label>
{% endapply %}

with this CSS attached:

input.xbbcode-spoiler:not(:checked) + label.xbbcode-spoiler,
input.xbbcode-spoiler:not(:checked) + label.xbbcode-spoiler * {
  color: black;
  background: black;
}
/* Hide the checkbox. */
input.xbbcode-spoiler {
  display: none;
}

This works normally in content:

<input id="xbbcode-spoiler-1375131070" type="checkbox" class="xbbcode-spoiler">
<label class="xbbcode-spoiler" for="xbbcode-spoiler-1375131070">Hidden text</label>

But (in 10.0.2) the sample output on /filter/tips removes everything except the text of the label:

Hidden text

Class and data attributes I tested seem to go through, but they're not really usable in this context. I suppose the markup could be inserted dynamically by a script, but that seems an overly cumbersome way to circumvent the filter.

Can you determine the core version that introduced the new behavior, and from there, the issue that caused the change?

Well, this was a wild goose chase :D

After inexplicably finding this same behavior as far back as 8.6, I finally realized the issue is in my test module: My actual module here returns the result of a \Drupal::service('renderer')->render() call, rather than a string. The renderer, of course, returns a Markup object, which allows the markup and styles to pass through unscathed.

The regression therefore was not in core - it was caused by adding return type hints in my module.

Drupal\filter\Plugin\FilterInterface::tips() asks for the return type to be "string|null" in PHPDoc, and without type-hints, this polite suggestion causes no problem when returning a Markup object.

If we add string as a strict type hint, though, PHP helpfully converts the Markup object back to string before returning it, causing it to be sanitized. :D

In summary, in core this seems to be just a documentation issue for now - all such methods that expect render output should mention Drupal\Core\Render\MarkupInterface as a possible return type alongside string. Eventually as strict type hints get introduced in core (see 🌱 [Meta] Implement strict typing in existing code Active ) this could become more critical.