[wp-trac] [WordPress Trac] #14746: Post Formats

[WordPress Trac]

#14746: Post Formats
----------------------------+-----------------------------------------------
 Reporter:  ryan            |       Owner:                             
     Type:  task (blessed)  |      Status:  new                        
 Priority:  normal          |   Milestone:  3.1                        
Component:  Template        |     Version:                             
 Severity:  normal          |    Keywords:  ongoing-project ui-feedback
----------------------------+-----------------------------------------------

Comment(by greenshady):

 Replying to [comment:104 markjaquith]:
 > The idea here is to standardize. Post Formats are, to start, not much
 more than a taxonomy convention with a UI wrapper. So if you have “Asides”
 on one theme, you can transport them to another theme. If people create
 their own formats, their portability will be zero, or close to zero. While
 this feature is getting started, at least, I think it makes sense to have
 requests for new formats go through core. That way we can announce new
 ones with fanfare, put them on the Codex page, and themers can update
 their themes to support them. Maybe once we’ve iterated a few times and
 have covered all the common use cases, we can make it easier to deviate.
 But to start, a managed economy will result in better standardization.
 >
 > It’s an unusual way to do things for WordPress — the difference here is
 that the main sell we’re offering is portability, and flexibility would
 hamper that goal.

 Here's what's going to happen though if we limit flexibility:

  * A theme dev is going to figure out a way to work around this.
  * That theme dev is going to share this code with other theme devs.
  * Other themes will start being packaged with extra code just for a
 workaround.

 With a simple filter hook, we could offer the flexibility some of us will
 make happen on our own anyway while still providing a standard for most of
 the theme development community.  We could also avoid needless hacks for
 something that's much better handled with one line of code in core.

 Suppose we stick with a standard pool of formats.  Further suppose that
 the "audio" format isn't within this pool.  Essentially, this tells theme
 developers that they must wait until the next major release of WordPress
 to hope (because it's not guaranteed) the audio format will be pushed into
 the standard pool.  It'd be much easier for theme developers to go ahead
 and use the audio format while trying to get it added to the standard list
 at the same time.

 Also, it's us theme developers who will have to explain to users how to
 create new formats.  I can guarantee you that I'll receive requests to do
 so from users the very day I add this feature to one of my themes.  It'll
 be some off-the-wall format that none of us have thought of, but it'll be
 important to a user.

 I like the idea of standardization and portability, but intentionally
 limiting flexibility is just not the WordPress way.  If that's the route
 we take, then we need to cover more scenarios.  A lot more scenarios.
 And, this pool needs to be decided upon by a much larger set of people
 than the developers viewing this ticket.

 Here's a few other ideas for the standard pool of post formats:

  * slideshow
  * audio
  * media
  * list

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