Make WordPress Core

Opened 3 years ago

Closed 21 months ago

#23537 closed feature request (maybelater)

Require attributes, not classes

Reported by: ryanve Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Themes Keywords:
Focuses: template Cc:


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 @Otto42
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

This isn't appropriate for discussion on the core trac. Post it on the theme reviewers mailing list, let them talk about it.

#2 @Otto42
3 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.

#4 @chipbennett
3 years ago

I agree with Otto. I don't see the use case for this.

#5 @Otto42
3 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 @ryanve
3 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.

Last edited 3 years ago by ryanve (previous) (diff)

#7 @nacin
21 months ago

  • Component changed from Template to Themes
  • Focuses template added
  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from reopened to closed

I don't see a pressing need to go down this path, either.

Note: See TracTickets for help on using tickets.