Fix: CSS border-radius not working in Internet Explorer 11

In doing browser compatibility testing in a new web form I was developing on my PC this morning, the form looked great in all browsers I had on my local Windows 8.1 PC – except for Internet Explorer 11, where it looked awful: div and form field border corners were squared instead of rounded, form fields rendered with excess height, some text was slightly truncated, and a few other issues.

When I looked at the CSS styles in use on the page in IE11’s built-in F12 developer tools, I noticed that the border-radius property on my form’s enclosing div was present, but it was missing its enable/disable checkbox, and the name of the style was shown with a red squiggle underline, as though IE didn’t recognize it.  It seemed almost as though IE11 was behaving like a legacy browser that didn’t recognize that newer CSS property.

In fact, that did turn out to be exactly the problem. IE11 was rendering the form (running on my local IIS) with its legacy “Compatibility View” engine, which it is by default configured to do for intranet sites.  (Oddly, my IE11 was not using Compatibility View to render another copy of the form that I was trying to use to debug the issue that I had IE loading via the “localhost” domain, which had me confused for a while.)

The solution was to disable IE11’s Compatibility View for intranet sites by doing Setting (gear icon) > Compatibility View Settings > uncheck “Display intranet sites in Compatibility View” checkbox.  Making that configuration change immediately got IE11 to start rendering the page properly.

UI Annoyance: Unselectable text in a disabled form field

A usability annoyance that I've encountered on a few occasions is a disabled field on an desktop or web application form which doesn't allow text in the field to be selected, and therefore, prevents the value in the field from being copy & pasted to another location.  (This side-effect of not allowing a clipboard copy of the field's value may or may not be above and beyond the developer's intention of simply not allowing the contents of the field to be modified).

For example, the web application server WebLogic Server 9 (WLS9) includes a web-based administrative console where database connection strings and other settings for hosted applications can be defined.  In the WLS9 console, one user at a time can obtain a lock on the console, preventing other users from concurrently making conflicting changes; when the current user does not have the lock, all editable fields are disabled.  In this state, field values can't be selected and copied to the clipboard.  This effectively prevents the user from doing things like copying settings from admin console form fields to another WebLogic instance, or copying a hosted application's settings from the console to document them in the application's internal documentation. 

There's no reason that the WLS9 console needed to be coded to prevent clipboard copying of values in this way; after all, the disabled field values are still visible, and the user can always just manually read and retype them elsewhere.  It's just an annoyance for the user to have to do manual retyping of values (such as long, complex database connection strings) when they could be using a clipboard copy to get the values.

HTML form fields: Disabled vs. Readonly

In HTML, an input type="text" field can be set with the attributes disabled or readonly.  The attributes have similar behavior; both prevent the field contents from being modified.  One key difference, though, is that the readonly attribute still allows the value in the field to be selected (and copied to the clipboard); the disabled attribute may prevent the value from being selected and clipboard copied, depending on the client browser's implementation.  (For example, Firefox 3 prevents the value from being selected; Internet Explorer 6 does allow the value to be selected.)

Try dragging with the mouse inside each of these fields, to see what behavior your browser allows:

<input type="text" value="Try selecting this text" readonly> :

<input type="text" value="Try selecting this text" disabled> :

Conclusion

Web application developers, before using the disabled attribute on a text input field on a web form, consider whether your users may ever want to clipboard copy the value in cases when the field is disabled.  If so, consider using the readonly attribute instead.

The same principle holds true for desktop application developers as well.  Consider whether your users will ever want to clipboard copy values from your disabled form fields when defining the behavior of whether the field values can be selected or not while disabled.

New Variable-Width Blog Template

I just updated this blog to use a new template. The main reason for the update was to get the content column of the blog (this column) to be variable-width. Thus, if you increase the size of your browser window, the text in this column should rearrange itself to take advantage of all of the available width.

Previously, the content column was fixed-width. In addition to not taking advantage of the full available width of large browser windows, the previous template also limited me to posting no wide non-wrapping items (in particular, images and code snippets); if such items were too wide, the template would break (and break rather spectacularly on IE!).

It took me a while to come up with HTML/CSS code that would work for what I wanted to do, given that IE (at least through version 6) does not support the min-width CSS style property. Eventually I came across this excellent page by Stu Nicholls which demonstrates a method of getting IE to emulate the min-width style property. (More details on the technique used available here.)

I took advantage of Stu's technique to put together this template, which (seems to!) behave properly in both IE 6 and Firefox 2: The right column is always a constant 270px, and the left column resizes dynamically to take advantage of the remaining available width of the browser window, but never shrinks below 400px or the width of the largest non-wrapping item in the column (whichever is greater). Thanks Stu!