&gt; &gt; And isn&#39;t there only one instance of $content-width? What about a situation<br>
&gt; &gt; where the user wants a video in both the content area and a sidebar or<br>
&gt; &gt; header or where ever? Will the oEmbed still work?<br>
<br>
&gt; oEmbed doesn&#39;t work anywhere but in the main post, like all shortcodes<br>
&gt; do. If you are using special code to process shortcodes, then one can<br>
&gt; specify the width manually in an [embed] shortcode. [embed<br>
&gt; width=123]<a href="http://youtube.com/etc%5B/embed%5D" target="_blank">http://youtube.com/etc[/embed]</a><br><br>I take this for agreement that using per page view for $content-width will only work for one area of the page (the content). Well - <br>
<br>1. I personally believe that one goal of WordPress and a given theme is to make life easier for the site builder. Why should a user have to figure out what that width is - ever? From a theme user&#39;s viewpoint, a shortcode should do all that automatically: in the content area, in a header, in a sidebar, a single column of a multi-column content area layout - maybe all on the same page. (I know of several professional videographers who do that, and who use YouTube or Vimeo to host their videos, but it would not be uncommon to find on any site that uses videos.)<br>
<br>2. I can give an example of a common, everyday situation where forcing the user to provide a width for the video in a sidebar or other non-content area simply will not work correctly - an iPad. One commonly used approach to responsive display for content/sidebar widths is to use percentages - works great for an iPad. So, given a legitimate user need to put a YouTube video in both the main content area and a sidebar, what&#39;s that width to be? Something that will fit correctly in the iPad sidebar width (thus leaving it too small for the standard browser view), or to fit properly in the standard view (thus being clipped in the iPad view)? In general, using specific px values is really not a good idea in a responsive theme. A theme based shortcode or widget can handle this correctly.<br>
---<br><br>If not YouTube, then there are other instances where it would be really infeasible to do it other ways - how about a responsive iframe shortcode, a responsive recent post slider (similar to Twenty Eleven&#39;s), even a shortcode to show a few related posts. All should be responsive for any area of the page, and all should completely match the styling of the rest of the theme. Perhaps if there were a standard for specifying the ids/classes of all the elements of a post, for example, one could write a theme independent show post shortcode, but I think WP is a long way from that point.<br>
<br>And theme lock-in doesn&#39;t stop at shortcodes. What about theme specific widgets, or even widget areas? How is using one of those much different than a shortcode? What about page template or features like Twenty Eleven&#39;s recent post slider? Use that or a specific page template, and you&#39;re locked in to Twenty Eleven? Really, any feature of any theme that provides something beyond basic styling would tend to lock one into that theme. That&#39;s why users pick a theme, I think - because it looks good to the user, and it provides other features the user wants to use. Most users understand that using anything other than a basic theme will result in some extra effort if they decide to switch to a different theme.<br>
<br>I&#39;m really just trying to make a case that there should be minimal WP theme restrictions on features provided by a theme. Shortcodes don&#39;t seem that different than any other theme specific feature. Some shortcodes really do require intimate theme knowledge, others may simply may make it easier to use features of a theme. If a theme designer has created a specific functionality for the theme (say a magazine theme), then perhaps they understand how specific widgets or shortcodes will make it easier for the user to create content for that theme. In such cases, lock-in may be both unavoidable, but desirable.<br>
<br>Bruce Wampler<br>