Allow adding allowed values to existing attributes

[DanielSiepmann]

I've come to code where custom onclick is added to a-Tags.
TYPO3 already ads an onclick to allow list for a-Tags.

I could not find any way to add another allowed value to the list.
Looks like the code is too robust to allow me to add or alter the already configured behaviour.
I only could remove the already build a-Tag and build it from scratch / from reading original values excluding the onclick and rebuilding it again?
Do I overlook something here? How should a developer use the library in such situation, where a framework already adds configuration?

That's our code which is just not called, because TYPO3 onclick value already does not match. Further values are not checked anymore. I couldn't find a way to check whether at least one value matches.

class DefaultSanitizerBuilder extends Typo3DefaultSanitizerBuilder
{
    protected function createBasicTags(): array
    {
        $tags = parent::createBasicTags();
        // Allow onlick="econdaTrackMarker();" in addition to TYPO3 native onclick code.
        $tags['a']->getAttr('onclick')->addValues(new RegExpAttrValue('#^econdaTrackMarker\(#'));
        return $tags;
    }
}

[ohader]

In TYPO3 v11 this has been removed - onclick is allowed for openPic( in earlier TYPO3 versions.

In this particular case all values-definitions for attr onclick need to match. The missing piece in the TYPO3 core is this: https://review.typo3.org/c/Packages/TYPO3.CMS/+/71560

Adding new Tag::removeAttr($name) and (maybe) Attr::setFlags($flags) methods to this library seems to be useful as well.

[ohader]

Thinking a bit about that, it probably makes sense to deprecate MATCH_FIRST_VALUE and introduce MATCH_ALL_VALUES - in most cases values should be additive like OR.

[DanielSiepmann]

Thanks for the fast response.
We can actually remove the TYPO3 code via composer patch in our specific use case.
But others might run into those issues as well. Your suggestions both sound useful. setFlags() feels easier to solve the issue, but bad from current design perspective. While removeAttr() feels good compared to current design, but complicated to solve the issue.

Your proposed Change to TYPO3 should already solve the job anyway, so no need to extend the API :)

[DanielSiepmann]

Thinking a bit about that, it probably makes sense to deprecate MATCH_FIRST_VALUE and introduce MATCH_ALL_VALUES - in most cases values should be additive like OR.

Would love that. Would be easier to understand and probably reflect real world more :)

[ohader]

@DanielSiepmann Looking forward to receiving your feedback on PR #66 (which makes mentioned core change above obsolete)

[AEHluis]

Adding new Tag::removeAttr($name) and (maybe) Attr::setFlags($flags) methods to this library seems to be useful as well.

Do you have any idea if and when that will be added?