Require attributes, not classes

Description

Currently themes​must use ​language_attributes, ​body_class, ​post_class​comment_class. Rather then requiring direct usage of those, it'd be far more useful to have (and instead require) functions for the entire attributes output, with corresponding filter hooks. The current _class functions/hooks would still run, albeit internally via these new functions. This approach is scalable to future attribute needs.

There also should be get_ versions. Using the get_ version in the theme (or manually applying the hook) should suffice to meet requirements. The hooks are the underlying reason for requiring these functions. Hooks would run in the get_ versions. #23236 can ensure safe output and DRY code.

I don't see that moving all the attributes into the realm of filters is really desirable or necessary, unless core itself is going to add more than the class's (or language in the case of the html tag). The theme itself can easily add its own attributes directly, making them use a filter to do so is a bit unusual, at best. It's abstraction without a purpose for it.

Just my 2 cents. Show me a reason to do this and I'll reverse position. But I don't see many plugins needing to modify anything other than the classes for those cases, 99% of the time, and core itself has absolutely no need to do so.

The use case is adding Google's schema.org metadata to sites. However, if you've examined schema.org at all, then you'd know that it is highly content and markup specific, so much so that I'd say the theme should be doing it and not a plugin.

Another use case would be to provide data- attributes to JavaScript-based plugins. I agree ​schemas may be better implemented by themes. Even in a theme I'd rather use hooks than create separate files just for different attributes. The point is that the current API is restrictive rather than free.