Opened 12 years ago
Closed 11 years ago
#23537 closed feature request (maybelater)
Require attributes, not classes
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | |
| Component: | Themes | Keywords: | |
| Focuses: | template | Cc: |
Description
Currently themesmust 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.
<html <?php html_attrs(); ?>> <body <?php body_attrs(); ?>> <article <?php post_attrs(); ?>> <li <?php comment_attrs(); ?>>
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.
Change History (7)
#1
@
12 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#2
@
12 years ago
- Milestone set to Awaiting Review
- Resolution invalid deleted
- Status changed from closed to reopened
Sorry, I misunderstood the post. This is fine for core trac.
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.
#5
@
12 years ago
I did think of a use case, but it's pretty thin for plugins.
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.
#6
@
12 years ago
Another use case would be to provide data- attributes to JavaScript-based plugins. I agree schemas may be better implemented by themes. Even in themes I'd rather use hooks than create separate files just for different attributes. The point is the current API is restrictive rather than free.
This isn't appropriate for discussion on the core trac. Post it on the theme reviewers mailing list, let them talk about it.