17198.showcase.2.diff adds full loop functionality back to the $featured query since we can't rely on sticky posts being available (may be trashed) and ensures all loop actions are fired correctly, while avoiding invoking it at all when no stickies are set.

Also makes better use of $feature_class and uses the native current post counter in the $recent query.

3.2 is marked as EOL for IE6 (for the admin), however themes (front end) should still support it so they have best compatibility. There are still people that are stuck in IE6. For them the admin would have limited functionality but the front end site should work.

17672.status-quote-formats.diff adds support for Status and Quote format display, excludes those formats from the Showcase Recent Posts, and adds them to the posts included in the custom "Ephemera" widget. It also adds CSS section headers for each Format and the 404 styles in style.css.

I was hoping the above patch would solve the /twentyeleven/ directory being included in any updates used from within your dashboard, if you used say the WordPress Beta Tester plugin. Turns out I already had the theme there, after I uploaded it myself. But I'm finding that /twentyeleven/ isn't included when I went from 3.1.1 to 3.2-bleeding, so I can't try it out online!

Adding that line should've done it. However, it should be fine as '3.2', and it also needs to be set in the file -during- the 3.1.x -> 3.2 update, ie. within the update zip. There may be other things at play here though, so I'll check it during testing.

(In [17737]) Twenty Eleven: Fix up the color picker JS. Use a separate color swatch rather than the input background. While cool, it doesn't have suffficient contrast. Also set farbtastic as a JS dependency. see #17198.

(In [17740]) Rename twentyeleven_color_schemes hook to twentyeleven_enqueue_color_scheme, so its purpose is clear. Also rename twentyeleven_color_styles() to twentyeleven_enqueue_color_scheme(), and twentyeleven_link_color() (which sounds like a getter) to twentyeleven_print_link_color_style(). Some tidying in twentyeleven_layout_classes(). see #17198.

Fix up the color picker JS. Use a separate color swatch rather than the input background. While cool, it doesn't have suffficient contrast.

Farbtastic has the contrast built in, but we were calling it wrong. I'll fix it up — the color change on the input element is the intended interaction, and much cleaner and simpler than the extra swatch.

Farbtastic has the contrast built in, but we were calling it wrong. I'll fix it up — the color change on the input element is the intended interaction, and much cleaner and simpler than the extra swatch.

I'd be interested to see a patch. I've seen that behavior before, but it's not what we do elsewhere in core, and I don't think it would be sufficiently high-contrast per accessibility standards. To be honest I found it annoying and tough to read even when using light colors with the black text.

it's not what we do elsewhere in core, and I don't think it would be sufficiently high-contrast per accessibility standards.

(Idea of how I'd do it on the input element is in "farbtastic-color-input.diff" patch — purely as an example.)

Good points, Nacin. Looking at Background color chooser and Header text color chooser it makes sense to match the same UI and interaction. That means we'll need to use a button instead of text link for the "Select a color" action.

Talking it over with Ian, he likes the swatch, too. But suggests we make it a link so it would also open the color selector.

Not sure if it's up for discussion, but I'm not sure what I think of them?

Yeah, fair enough, I like that we're trying to make it look a lot different from TwentyTen, but I feel they're just out of place within TwentyEleven. Would having icons, or similar, not make for a better change?

Small but vexing question: the Theme Options Admin Screen in Twenty Eleven has only two generic links in the contextual help tab... Does the theme-options file in the theme folder in wp-content call something in wp-admin that could be fixed to apply to all themes that have theme options? (Like Background and Header do) I think it would be easier, but less optimal to add help tab content in the Twenty Eleven file itself.

And, yes, this screen provides highly obvious options, but we could say it changes colors and layout and then come up with a few nuggets/links for people who wanted to make more such changes, go under the hood, use the theme editor, modify some CSS, create a child theme...

This is more of a design preference. Is there an option to keep the sidebar active on single.php instead of having it no longer there? I've never been crazy about the look of the default one-column width/centering in Twenty Ten and it seems to be carrying over to Twenty Eleven. I'd suggest just keeping the widgets on single.php by default.

There isn't an option on posts for including a sidebar in Twenty Eleven but there is an optional custom page template for pages that includes a sidebar.

So I guess that's pretty definitive to leave off widgets on single.php? While aesthetically pleasing I think it may be too brazen for most WordPress users to suddenly lose one of the most crucial WP content areas on post pages. It's easy enough for me to put it back in as a developer but I think it will be a turnoff to regular bloggers if there's no easy/non-code option to choose whether to display widgets on posts. So much important stuff happens in widgets (ads, widget context, secondary navigations etc.). I think widgets are just as important on post pages as anywhere else (actually I'd argue they can be even more important on post pages for some cases). Just some food for thought. I love the theme and will use it and just put the sidebar back in for my child themes. But I'm just making this suggestion to save me, other developers and bloggers a little time as I can't think of any theme I'd make for a client that wouldn't utilize a sidebar on post pages. If the majority agrees with me I'm happy to adjust the single.php template and modify the CSS and contribute that in the appropriate place :-)

I'm taking a more design practical approach. If you're selling ads on your blog, putting them in the footer is just not going to cut it. I really feel pulling the sidebar from the single.php is going to be a deal-breaker for non-developer bloggers. If there's a good rationale for taking it out by default I'm all ears.

I see. I hadn't tried out those types of blockquotes and images. It is quite elegant. I think allowing users to have a choice of template in the admin for single.php may still be the best bet. I already use a plugin for this so I guess I'll just have to bundle that with sites I deliver for clients.