Visual improvements in dialogs

[Wiktor Walc]

While designing dialogs we used to check how they look having the English language enabled.

It might be worth checking how CKEditor looks like in other popular languages, like German, Russian and also in languages which translation files are much bigger than en.js (like Thai).

Changing the design of some dialogs would be a relatively small change in the code, but a possibly big improvement in the quality of user interface.

[Wiktor Walc]

The attached images show the difference between how dialogs look right now and how they could look like.

[Garry Yao]

It make sense to introduce an "auto-wrap" feature for dialog fields, the idea is that when dialog has a fixed size and thus is not big enough for horizontal label layout (e.g. when resized), input could wrap it self to form a layout same as if labelLayout : 'horizontal' is specified.

[Frederico Caldeira Knabben]

KISS for now... let's simply fix the evident issues, rearranging the dialog structure.

I'm totally ok for the image dialog changes.

The cell properties dialog must definitely be reviewed, and have a new design just like we did for the table dialog. Basically, we should always try to have labels on top of the fields.

[Sa'ar Zac Elias]

I also included a fix for a small layout bug in which the choose color button had the wrong margin in the tableCell dialog in RTL UI.

[Sa'ar Zac Elias]

#6264 is a dup.

[Krzysztof Studnik]

Table cell properties dialog box under Opera 10.61, CKE 3.4.1 Nightly

[Garry Yao]

The two color boxes looks really unhealthy as Krst pointed out, we should go with the following layout I think

[label]: 
[field][picker]

[Sa'ar Zac Elias]

Fixed with [5930].

[Sa'ar Zac Elias]

The last patch brought some regressions for IE7 and Quirks.

[Garry Yao]

IE7 is the only browser that doesn't get applied the [defined left margin ​http://dev.fckeditor.net/browser/CKEditor/trunk/_source/plugins/tabletools/dialogs/tableCell.js#L486].

[Frederico Caldeira Knabben]

Other than any other issue, the mixed formatting we have after patch is NOT acceptable:

• Labels must be at the top of ALL fields, not only half of them.

• Spacing between fields must be coherent and the same in all cases (e.g. there is space between background and border color fields)

[Sa'ar Zac Elias]

As I don't have the same result as you all get, I'd better leave that ticket to someone else and confirm that it doesn't brake my side.

[Garry Yao]

Changes to the dialog plugin are mandatory to make dialog body auto expands in IE7 while doesn't introduce any side effects for other browsers, note that now all browsers expect for IE quirks are now auto expanding.

[Sa'ar Zac Elias]

• Let's have the same width for the "width" and "height" fields in the cellProperties dialog.
• Also, the top margin that was added to the the buttons is only valid for Kama appearently, it doesn't look good on other skins.

[Garry Yao]

We need to resort to skin part to resolve those issues from Saar.

[Tobiasz Cudnik]

IE7 strict

[Tobiasz Cudnik]

Ive attached 2 screens from IE7 strict, one from LTR, second from RTL sample. Both contain an error.

Besides that, what with the Image dialog, it won't be included?

[Garry Yao]

Updates in new patch:

1. Have picker button fixed width as with footer buttons;
2. Re-layouted "image" dialog.

[Frederico Caldeira Knabben]

The file naming convention for the new CSS file is wrong. It must be all lowercased.

Ideally, we should not have plugin specific files inside skins. Even if not a big issue, if we do that now, it'll open a precedence for this, and we may start having several of these files there, which is wrong.

If a specific dialog element type is missing (in this case the button), the right approach would be instead creating the infrastructure to support this *generic* element. Right now it would be used by this dialog only, but it could be then easily reused by other dialogs.

But, aren't buttons already used in dialogs in that way?

[Frederico Caldeira Knabben]

Other than that, it's clear that the fields are not all left aligned in the Image dialog. Probably an old issue, but it's a fact.

[Garry Yao]

Replying to fredck:

Ideally, we should not have plugin specific files inside skins. Even if not a big issue, if we do that now, it'll open a precedence for this, and we may start having several of these files there, which is wrong.

I agree, but unfortunately there's currently no way of introduce plugin specific CSS without bloating dialog.css which just slows down dialog loading, this skin part hack was initially used in "templates" dialog to resolve such an embarrassment, but eventually we'll still need a solution for this.

[Garry Yao]

Fixed with [6137].