[wp-trac] [WordPress Trac] #18548: Add a better option for <title> tags

[WordPress Trac]

#18548: Add a better option for <title> tags
------------------------------------------------+--------------------------
 Reporter:  joostdevalk                         |       Owner:  joostdevalk
     Type:  enhancement                         |      Status:  new
 Priority:  normal                              |   Milestone:  Awaiting
Component:  Template                            |  Review
 Severity:  normal                              |     Version:  3.3
 Keywords:  has-patch dev-feedback needs-codex  |  Resolution:
------------------------------------------------+--------------------------

Comment (by chipbennett):

 Replying to [comment:79 nacin]:
 > Replying to [comment:78 chipbennett]:
 > > By all means, correct me if my inference here is incorrect, but IMHO
 this sounds like an effort to discourage - if not prevent (as I suspect
 Plugin developers would prefer) - Theme developers from modifying the
 doctitle content.
 >
 > Correct.
 >
 > They would be able to pass defaults through the add_theme_support()
 call, and I imagine these default settings would be akin to what power
 they're normally given in wp_title().

 It would be instructive to see an example of this written up in code-form;
 I ran through the ticket, patches, and comments so quickly that I'm not
 exactly sure what the current state of everything is.

 > Additionally, there would be filters in this new callback, though I'd
 hesitate to suggest a theme should use it.
 >
 > Point is, themes shouldn't be dealing with the content of a title tag.
 It's exactly that: content. Not presentation.
 >

 I disagree; an argument could easily be made that the doctitle content is
 simply presentation. It is not new/unique content; rather, it's simply
 presentation of ''already generated/defined'' content.

 I think the best solution is for this presentation to be defined in core,
 both through more robust doctitle markup in core, and through a UX for
 user configuration. That way, neither Theme ''nor'' Plugin needs to modify
 the doctitle content.

 So, I understand where you're going with the `add_theme_support()`.
 Though, why not just make it assumed? There was certainly no
 `add_theme_support()` added for the Admin Bar, which required
 `wp_footer()` to be present.

 (I guess what I'm saying is that I'd like to see better-defined, more-
 consistently defined "WordPress standard" practices, implemented more
 consistently. Too many such features are handled differently from each
 other.)

 >
 > The biggest problem right now is a theme can optionally take absolute
 control over what appears in the title by avoiding wp_title() all
 together. We'd rather force our own <title> tag to ensure that a user or
 plugin can equally make modifications.

 In the short-term, that is equally (and more easily) achievable by
 changing the Theme Review Guidelines with respect to `wp_title()`, to
 require that if modified, it must be modified via filter.

 > It's not that a theme would lose all power, it's that they would be on
 equal footing.

 I'm with you 100% on this.

 > It's the same idea as `wp_title('')` but wp_title() is crap, our own
 default themes even want something better, we can't change it without
 breaking old themes, and we will need the add_theme_support() registration
 in order to show a user interface in the admin.

 I think you could convince me, if the UX and more-robust core doctitle
 markup were implemented simultaneously (along with `wp_title()`
 deprecation), so that Theme developers both only needed to make one change
 to Theme code, and would benefit from a significantly reduced need to
 filter the doctitle content in the first place.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/18548#comment:82>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software