HTML API: Only pass a single class name to add_class() #5325
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In some places, multiple classes are being passed to the Tag Processor's
add_class()
method. They are being passed as a string containing class names separated by whitespace. This produces the expected behavior because the Tag Processor doesn't enforce its expectation in theadd_class()
method, but allowing this can lead to mistakes when interacting with classes.In this patch these places are updated to only add a single class at a time, and a helper CSS class is created with a commonly-used method
class_list()
to split such combined strings.The Tag Processor could be changed so that
add_class()
splits CSS strings implicitly, but that introduces a hidden form of runtime overhead that may not be evident from the name. It also leads to confusing code patterns, as seen in this patch, where plurality mismatches appear:add_class( $classes )
Another method,
add_classes()
could be introduced in the Tag Processor, and that could split the class names, or it could accept an array of tag names. It's not clear which of these would be more useful, clear, or likely to avoid mistakes.For now, by leaning into the existing API definitions it's probably best to clarify expectations and behaviors rather than to start blurrying definitions and interfaces, and that's what this patch proposes doing.