Re pic: #1 - That looks like a Seven bug to me. That is a regular fieldset with a description, and I'm pretty sure nothing in this patch is touching it. Definitely a problem, but should be a separate issue.

Re pic: #2 - I agree the sliders don't look nice enough. I'm not digging them in Firefox or Safari either. Maybe we can get one of the designers to weigh in on that. Tagging this "Needs design review."

This is an important opportunity for promoting consistency in admin UI. To do so, follow Sevens lead:

- Can't have the rounded corners for the accordions and dialogs, nor the messages. Rounded corners are for buttons and links (not content blocks) with only the progress-bar as the exeption for just looking nicer with round corners.
- Try one of the accent greys for the current day in the calendar, this yellow is too loud.

The icons don't get any margins or positioning by default in jQuery UI by design. This is actually a tough problem to solve here. In the demo I setup (clone of the ThemeRoller demo), the dialog link and the icons shown in the highlight/error samples have CSS applied that handles the positioning and margins of the icons that are not part of this commit. I can't target the icons directly because they are used all over the place. I also can't target .ui-state-highlight .ui-icon without potentially screwing up the icons in the accordion or any other widget that decides it wants icons & gets a highlighted state in the future. The best thing I can think do here is target icons in <p> tags, but it's not foolproof either.

This is "fixed" in the latest patch, and I changed the underscores to dashes in the icon file names. It's also updated on the demo site so you can see it there. :)

In general, it's tough to set reasonable defaults without knowing how/where this stuff is going to be used within Drupal. Having theme functions (or Drupalized widgets) for this stuff, and also substituting classes in existing theme functions for the jQuery UI classes (like changing <div class="messages error"> to <div class="messages ui-state-error">) would go a long way towards achieving some consistency and would greatly improve the TX! I hope to spend some time on this stuff over the weekend.

ok, well with the filter tips modal patch applied, my popup for the filter tips looks like this (see attached). I'm using the overlay and I believe this is due to line 377 of ui.seven.css where the background of the title bar is set to transparent. Why is this done? Surely the dialog titlebar should still have a background colour when displayed on top of the overlay...

@mrfelton - Both overlay windows, the child (filter tips) and the parent (the overlay itself) use the same class. The overlay dialog title needs a background: transparent for the overlay because this file loads after the overlay's CSS file, and overrides the styles set by it.

Regarding #87994: Quit clobbering people's work when they click the filter tips link, it hasn't been committed so I don't think it's a valid reason for this patch to need work. In addition, the overlay module itself hasn't supplied any CSS for these dialogs yet. If you look at the module, overlay-parent.css exists, but overlay-child.css does not. That is where most of the styling will need to happen. Until that is addressed in core, any dialog inside the overlay will inherit the styles of the main window. After it's addressed, we may or may not need need to style it here, but attempting to fix it here will only cause problems for person writing overlay-child.css if they want to style it in a different way. Hopefully that makes sense.

- Will make it quicker/easier for developers to stay consistent with default Seven admin theme.
- Less styling to undo for admin themers.
- Wich is a UX win for any user that gets to visit contrib module settings pages.

Having a quick re-look at the patch, it looks like we are switching the weight of ui.theme.css. We could probably fix that in system_library() instead and save all other themes from doing the same. JS_THEME - 10 will put it before all other theme's CSS, but after all the jQuery UI base CSS stuff. Means less line of code in the patch, which is good.

Oh... or did you mean within the same screenshot there are two themes? :) If so, yes, that's the standard setup there... but the problem is that the patch seems to remove the opacity in that situation.

- overlay opacity mentioned in #44 is no longer overridden as it doesn't use jQuery UI dialog any more.
- even though the stylesheet is provided by a theme we shouldn't override weight at all; it should stay on the position where it was added as part of the jquery ui library.

This issue was RTBC in #42. Problems identified afterwards should be resolved. So RTBC again?