[Top]
More advice for the full screen mode.
   
Sivut toimivat riittävän hyvin MS IE 4.0+, Opera 5.x+, Netscape 6.0+/ vast. Mozilla ja Konqueror 3.x selaimilla. Yleisesti ottaen sivut toimivat parhaiten uusimmilla Opera selaimilla. Sivujen toimivuus vanhemmissa selaimissa on heikko, erityisesti Netscape 4.x kohdalla.

I list below all topic groups, which I have done according to subjects, which they handle. You can return to this topic group by using this menu and the link Table of topic groups on the top of the each page.
 
 
Search:
[Help]
Table of topic groups > Front page of CSS-guide > Guide pages > 8. How to set CSS for backgrounds and borders > Backgrounds and borders for forms and frames (section 3/6)

Backgrounds and borders for forms and frames

To apply CSS onto gathering form elements (FORM and FIELDSET) are free from problems because they fit to the existing box model of CSS2 (these elements are clear block level elements).

I had an e-mail conversation with a worker of Mozilla org. According to an e-mail response it is totally questionable to apply CSS for form control elements (BUTTON, ISINDEX, LABEL, LEGEND INPUT, OPTION, OPTGROUP (the element is supported only in new Netscape/Mozilla browsers), SELECT and TEXTAREA) because they don't conform to the CSS box model. Form controls cannot currently be described in the language of CSS (what display type, for example, would a button get?). Attempts to hack styling onto form controls are usually problematic because there is no standard how to do.

My personal opinion is that all properties, which are not depending on certain box model browsers should be able to apply to form control elements. Then at least text and font style properties should be able to use in them. At this point of view all modern browsers work fine.

The difference can be partially explained, how bordered form control elements (for example SELECT) should be overall interpreted. They are exceptional elements. They can be interpreted as if embedded objects, like the element IFRAME, which has as default frame borders. Browsers don't replace frame borders with CSS. They can be taken off only by defining frameborder="0". The style of frame borders resemble the borders of form control elements when for example the borders of the element SELECT can in principle interpret so, that it has as if frameborder="1", which can't be redefined. In this case CSS-borders becomes outside of normal borders and the element gets double borders. Because most form control elements have in HTML natural borders unlike TABLE and IMG elements, which can define borders with an attribute, borders are exceptional attributes of form elements.

Elements FRAME and FRAMESET should have borders like IFRAME.

Because CSS-borders remove or replace by HTML defined borders for TABLE and IMG elements, the replacing principle is also logical, but in this case form control elements are understood differently - more like ordinary elements, not like embedded special objects. At this way the generic principle of CSS (I have mentioned it in the page 1b[S] can be implemented better.

A member of the working group of CSS in W3C said, that browsers should have to right to use so-called widget libraries, because the usage of widget libraries is much faster. Form control elements can be borrowed from the platform, when it is not possible to change the borders of them. I would however reasonable to give for Web-authors change border, but then browsers can't anymore borrow form control elements from the platform. Because the usage of CSS might overall increase download times of Web-pages, the author should be always responsible, if he wants to create slower working pages by using CSS. The browser should not make the decision instead of the author! Missing features will be added into the CSS3[S], when form control elements can be implemented at standard ways. When the CSS3 will be ready, W3C should oblige browser designers to follow it.

W3C: User Interface for CSS3.

My recommendations:

  1. I recommend that you would define for form control elements just font-related properties and widths.

  2. If INPUT elements have been used as buttons, don't define for them border and background properties. I regard defining borders for any form control element quite qestionable.

  3. Don't define for INPUT elements heights with CSS. It would be also reasonable to avoid using the padding property.

  4. Don't change the presentation of conventional frames with CSS.

Browser-specific notes:

  1. Older versions of Opera (4.x and older) and Netscape don't support even all these text properties for form control elements.

  2. According to an e-mail Mac browsers handle form control elements totally differently. For example Mac IE 5.0 SELECT resemble a button and it is not rectangular.

  3. Form buttons look in many browsers better without background and border properties by using CSS. MS IE for Windows XP, MS IE for Mac use rounded form buttons. Also some skins of Opera 7.x use nice rounded form buttons.

  4. Opera (until the 6.x series) doesn't support background properties for form control elements.

  5. The functionality of CSS-borders is extremely bad in Netscape 4.x, because applying CSS-border onto the SELECT element destroys the functionality of the element.

  1. Until 6.x series Opera adds borders to elements SELECT, OPTION and TEXTAREA outside of the original borders. Opera interprets previous mentioned form control elements as if embedded objects borrowing them from the platform. Starting from Opera 7.x Opera renders forms exect radio buttons and OPTION-element like Mozilla Gecko browsers. It is not possible to set for OPTION-elements different color and background properties than for the SELECT-element and background images don't work for OPTION-elements.

  2. MS IE for Windows, Mozilla Gecko and Opera 7.x+ browsers CSS replace original borders with the element INPUT in certain circumstances (<INPUT type="text">) and with the element TEXTAREA (in Opera 7.x+ and Mozilla also with the element SELECT but MS IE doesn't support CSS-borders for this element).

  3. Dynamic pseudo-classes work with form control elements only in Opera 7.x+ and Mozilla Gecko browsers.

  4. Opera 7.0 Beta 1is the only browser, which renders correctly the BUTTON element. In newer Opera brossers don't work display:block. In Mozilla Gecko browsers don't work the text-align property.

  5. Among Mozilla Gecko browsers dimension calculation principle are different for form control element. In order to get as exact result as possible -moz-box-sizing:border-box or -moz-box-sizing:content-box should be added (into CSS3 has been added the property box-sizing, which I handle in an [S]).

  1. Mozilla Gecko browsers give proposals how form control elements could be rendered with a browser, which supports CSS3. I took a screen capture[S] from Mozilla 0.7. If you can, test the example form below with Opera 5.x+, MS IE and Netscape 6.x+ browsers ([M][S][Pw]):

    *{font-family:Verdana, Arial, sans-serif; font-size:14px}
    form {border:1px solid black; background-color:aqua; padding:10px;}
    fieldset, isindex {border:1px solid black; padding:2px; margin:2px; width:100%}
    fieldset#first {background-color:white}
    fieldset#second {background-color:olive;}
    fieldset#third {background-color:lime;}
    legend, label {font-weight:bold; color:red; border:1px solid red; background-color:white}
    select, input, textarea {border:2px outset red; background-color:#ffc; width:200px; font-weight:bold}
    optgroup#two {background:aqua url(./Css/Kuvat/pallo.gif) no-repeat; padding-left:16px;}
    option, textarea, input {background:#ffc url(./Css/Kuvat/pallo.gif) no-repeat; padding-left:16px}
    button {background-color:#ccc; border:3px outset gray; padding:10px; width:200px} input[type="radio"]{height:15px;}

    The aim of CSS is to replace presentational features of HTML as far as possible. Concerning <INPUT type="radio"> it is open question, if according to CSS3 the radio button should have additional rectangular borders around it or should CSS-borders replace the original border.

  1. Even if Netscape 6.x+ can alter the presentation of all form elements, if forms are used in XML-documents, CSS2 doesn't have enough rules and properties to express all natural properties of form element. For example official CSS-specification don't handle at this moment rounded borders, which are used in radio buttons. Indeed Netscape/Mozilla use proprietary CSS to define presentational features in /res/forms.css, when in principle it could implement presentational features of forms in XML. I handle proprietary features of Mozilla in my CSS How to set CSS for table elements(form-related pseudo-classes[S] and outline[S]).

  2. Opera 7.x+ support outline, but it doesn't work properly with form control elements.

  3. Width and height properties of form control elements are in MS IE 6.0 DTD-dependent[S]. Defining heights might cause remarkable different results in different browsers.

  4. CSS works with FRAME and FRAMESET elements only in MS IE in situations, where the framesets have actual contents. Mozilla Gecko browsers hide normally defined CSS behind the defined or imaginary frame documents. If the defined documents can't be found with Mozilla 1.1a it is possible to define border and background properties for FRAME and FRAMESET elements (with some older versions it is only possible to get visible border properties for the FRAMESET element).

[Top]