Interferring Style Affecting Dialog Text Box Heights

[Lee]

Prior to version 4.4.7 I used to have issues with interfering styles such as table-layout: fixed and underlines on links. I've been able to remove all of my CSS hacks but I have one final interfering style:

input[text='text'], input[type='password'], select {

height: 18px;

}

This affects all the text boxes within the dialogs.

It would be good if the reset could handle this.

Thanks

[Lee]

Actually the underline on links is still happening. Courtesy of the following style:

a:hover {

text-decoration: underline;

}

Replying to nfplee:

Prior to version 4.4.7 I used to have issues with interfering styles such as table-layout: fixed and underlines on links. I've been able to remove all of my CSS hacks but I have one final interfering style:

input[text='text'], input[type='password'], select {

height: 18px;

}

This affects all the text boxes within the dialogs.

It would be good if the reset could handle this.

Thanks

[Jakub Ś]

This affects all the text boxes within the dialogs.

I have added styles directly to HTML page. Height of input fields in dialogs is not affected, so is the hover on links. Could you send me some reduced sample HTML file that shows how styles in default editor dialogs can be affected?

[Lee]

To test this I simply downloaded the standard package and then replaced the contents of the sample.css file within the samples directory with the following:

a:hover {
  text-decoration: underline;
}

input[type="text"], input[type="password"], select {
  height: 18px;
}

Now open one of the samples (tested in IE10). If you click on the image plugin and hover over the tab you will see the text underlines. The height of the textbox is a little harder to spot. However you will see it's not the same height as the select element.

Hope this helps.

[Jakub Ś]

Thanks, I haven't noticed you need to modify sample.css to see the result.

In CKEditor 3.x we have input.cke_dialog_ui_input_text which seems to have same ​specifity as input[type="text"] but dialog.css file containing this rule is loaded after samples.css, the later rule takes precedence.

In CKEditor 4.x we also have input.cke_dialog_ui_input_text but in this case this rule doesn't contain height property. Instead we use .cke_reset_all, .cke_reset_all * rule which is less specific than input[type="text"]. In such case no matter the loading order, the more specific selector will be applied.