WordPress.org

Make WordPress Core

Opened 14 months ago

Closed 3 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:

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)

comment:1 Otto4214 months 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.

comment:2 Otto4214 months 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.

comment:4 chipbennett14 months ago

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

comment:5 Otto4214 months 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.

comment:6 ryanve14 months 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 14 months ago by ryanve (previous) (diff)

comment:7 nacin3 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.