While adapting the plugin for oEmbed, I wanted to maintain 100% backwards compatibility with existing defaults and shortcode attributes. Here are the current size defaults:

array(
    'height' => get_option('documentcloud_default_height', 600),
    'width' => get_option('documentcloud_default_width', 620),
    …
);

(Quick aside: oEmbed services, including ours, expect maxwidth/maxheight, but WordPress standardized on height/width for its embed shortcodes, so it does a dance to map height/width to maxwidth/maxheight right before the oEmbed provider is called. I'll support both, with a priority preference for height/width out of deference to WordPress.)

The existing plugin has this priority order (lower number = higher priority):

1. Shortcode attribute ([documentcloud width="…"])
2. User-defined default setting (Settings > DocumentCloud > "Default embed width (px)")
3. Plugin default (Second param in get_option() above)

Normally, in the absence of user input, WP applies the theme's own content width to the embed's width (and applies a standard multiplier to set a height). You can track this back from WP_oEmbed->fetch() to wp_embed_defaults() to the $content_width in a theme's function.php file. But we never fall through to that case because of the plugin defaults.

I'd like to recommend we remove the plugin defaults and, absent an explicit shortcode or user-defined default, let WordPress push through its theme-specific default embed sizes.

Impact: any existing plugin user who hadn't set widths explicitly (either in a shortcode or in their default settings) and then upgraded the plugin might be surprised to have their existing embeds "upgraded" to the theme's idea of a proper embed width/height. (Though presumably they'd have to open and save the post to have the shortcodes reprocessed.)

@eyeseast / @aschweigert, y'all know this landscape far better than me. What do you think?