More advice for the full screen mode.
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.
Table of topic groupsFront page of CSS-guideExtra pages > Q What CSS-implementation errors are in Opera browsers

Q What CSS-implementation errors are in Opera browsers



Because Opera is from the 5.0 version available as half-free ad-sponsored (adware) application I handle in this page primary Opera 5.x browsers. I refer to the 3.x series on a little. It is reasonable if pages would work at least fair in Opera 3.x series.


Problems in Opera 5.0-6.0x

Opera has fine support of different media types, but just usage of them has some problems, which should be aware. I have handled some matter in the page 6[S]. I addition of matters, which I have handled in that page in order to get pages to work well as printed and on screen it is important to take account also following matters:

  1. The browser supports media="projection". If for the screen presentation style sheets has been given by using media="screen" or corresponding media blocks[S] the browser doesn't get at all CSS in the full screen mode. If you have Opera 4.x+ and you press the F11 button in this site, the page looks quite different (I have advice[S] for this mode and every page have short hints how to navigate in this mode).

  2. Opera behaves incorrectly if media types have been given at the following ways:

    • If to the same CSS-files has been referred at the following way:

      The problem in the latter solution is that Netscape 4.x doesn't support several values at the same time for the media attribute. I the style sheet has been intended to use both in Opera and Netscape 4.x browsers, the media type projection should give an own CSS-file.
    • If media block doesn't exactly match to the value of the media attribute:

      /* Doesn't work with following media blocks: */
      @media screen {...}
      @media projection{...}

      /* It works only with following kinds of media blocks:*/
      @media screen, projection{...}
      The problem of this solution is the fact that randomly the same CSS-file has been needed both for one and several media types.. Then it is necessary to use several media blocks for the same CSS. For example in order to get media blocks to work with both and <link media="screen" type="text/css" href="Screen.css"> the same CSS needs two media blocks:
      @media screen {
      #linkSet a {color:red}}
      @media screen, projection{
      #linkSet a {color:red}}
    • The attribute media doesn't work correctly with the @import at-rule if the at-rule doesn't have the media type (for-example @import url() print;). It doesn't work in all browsers (in Opera browsers it works starting from the version 5.10).
    • @media doesn't work in the Opera 3.x series.
  3. The media type projection has problems keeping "slides" continuous. In order to avoid incorrect page breaks I give two hints:

    • Write tight code. Except tables and lists I have written start-tags and end-tags one after another.
    • If the browser breaks inside or after the first paragraph I have added an empty DIV element with a class attribute before the content of the slide (I have defined for media types print and screen div.noScreen {display:none}).

Media blocks can be use in situations, where MS IE 4.0 for Windows need certain CSS, which is not intended for other browsers. In addition inside media blocks can write such CSS, which is not intended for Netscape 4.x and MS IE 5.0 for Mac browsers because these browser skip all CSS, which is inside media blocks. I have given an example in the extra page, which handles MS IE problems[S]. When media types are used clever, they allow fine solutions especially with Opera.

Another big problem concerns fixed or absolute positioned elements if they need the z-index property. The problem concerns always certain embedded objects (they are embedded to Web-pages through OBJECT, APPLET and EMBED elements) and until Opera 6.x form control elements (EMBED, IFRAME, INPUT, ISINDEX, OBJECT, SELECT, TEXTAREA). Any text or images can't set above these elements. It is possible to avoid this problem by positioning problematic elements so, that they newer go over each others - it is especially important to remark this with elements, which are fixed positioned (position:fixed). In my updated navigation system navigation elements are on the left and right and problems have been avoided as far as possible. Concerning form control elements this matter has been fixed in Opera 7.0 Beta 1.

Opera has also a small problem with the visibility property. Opera hides always such elements, which have visibility:visible if they are inside elements, which have been defined visibility:hidden (look at a test page[S]) (MS IE 6.0 for Windows works always correctly but new Netscape/ Mozilla browsers work in some circumstances incorrectly). This matter has been fixed in Opera 7.0 Beta 2.

Opera 5.x and Opera 7.0 Beta 2 might position horizontally incorrectly nested absolute positioned elements. The property left doesn't always work. Concerning Opera 6. I found that position:absolute + nested relative positioned elements positioning didn't work for innest elements.

In addition position:fixed has also following special problems (if you have Opera 5.x+ I have a test page in order to demonstrate these problems):

  1. The combination position:fixed + position:absolute doesn't work in official versions of Opera 7.0x (in Beta 2 nested absolute positioned elements don't work correctly). One of the consequences is that background colors of links don't always follow the movement of the mouse in the state :hover

  2. Using the positioning right Opera 7.0 Beta 1 - Opera 7.01 might move elements too much to the right and Opera 7.02 might randomly hide elements.

  3. In Opera 6.0x the padding-top and padding-bottom properties for the BODY elements affects to bottom property. For example div#fixedNavigation {position:fixed; bottom:0; left:0;} together with body {padding-top:50px; padding-bottom:50px;} cause that the fixed element is 100px from the bottom of the viewport (this problem is not in the 5.x series). This problem is possible to avoid but at least Opera 7.0 Beta 2 has not this problem (I have not tested in Beta 1).

  4. If the fixed element is on the bottom of the viewport, the min-height property can't be used. This matter has been fixed at least starting from Opera 7.0 Beta 2.

  5. Fixed positioned elements, which are inside positioned elements scroll among the page (this problem is not in Netscape 6.1+; in Opera 7.0 Beta versions the element might disappear from the screen or the position moves a little bit if the element has been clicked). This problem is possible to avoid at the same way as the next problem.

  6. If an element, which is later in the content (for example position:fixed; bottom:0; left:0; z-index:3), has been set as fixed, it might disappear from the screen. I tested in this page with Opera 7.0 Beta 2, which had no problems at least in this page. This problem is possible to avoid by setting fixed positions elements only to the top of the page and as direct child-elements of the element BODY.

  7. If dynamic menus have been positioned by using position:fixed menus don't work as expected (and how they work in Netscape 6.1+ and other corresponding browsers, which use the Mozilla Gecko rendering engine). This problem can't be avoided but it is fixed in Opera 7.0 Beta 2.

  8. If fixed positioned elements have background images, Opera browsers which are older than 7.x series scroll them among the page, if background images have not defined as fixed (background-attachment:fixed). If they have defined as fixed, Opera calculates the position against the CSS2 specification according to the element. This cause problems with newest Mozilla Gecko based browsers, which calculates background images correctly. This matter has partially been fixed in Opera 7.0 Beta 1 because it is not necessary to use fixed background images (the positioning problem remains, but in Opera 7.0 Beta 2 also this matter has been fixed). This problem can be solved only by writing conditional CSS.

  9. If links have with dynamic pseudo-classes (a:hover and a:active) borders, borders work only in the top of the page. This is fixed in Opera 7.0 Beta 2.

  10. If fixed positioned elements have position:absolute defined descendants, this matter cause problems in some Mozilla Gecko builds[S] (this is not a bug in Opera but instead in some Mozilla Gecko based browsers). This matter is impossible to avoid except setting conditional CSS for certain Gecko browsers, where the position has been set by using position:fixed (Gecko browsers have so much version-dependent differences that position:absolute doesn't give equal result for all such Gecko browsers, which support position:fixed).

  11. Position:fixed doesn't work in the 5.x-series for elements IFRAME, OBJECT and EMBED, but this matter has fixed in the 6.x-series.

  12. Form control elements move horizontally one pixel when the page has been scrolled. This matter has been fixed in Opera 7.0 Beta 1.

  13. Internal links don't always work as expected. I must put the link to the top of the page ([Top]) immediately after the anchor (<a name="Top" id="Top"></a>), which it refers. Otherwise Opera didn't go exactly to the top of the page. This matter has been fixed in Opera 7.0 Beta 1.

The third remarkable feature is quite weird implementation of xx-small-xx-large properties, which resemble most the implementation of MS IE 5.x for Windows browsers (look at Model8c.html[S]).

Opera browser don't have as wide working two different rendering modes (in the 7.x series is some kind of DTD-switch) for the screen presentation like new MS IE and Netscape 6.x+ browsers, it can't follow in certain respects the CSS2 specification as strict as MS IE 6.0 for Windows in the standard-compliant mode[S]. Opera would wider working DTD-switch.

I mention smaller problems in other connections. You can read them for example from the following pages:

Because Opera is a visual browser it naturally doesn't support aural style sheets. The widest area in visual media of CSS2 is missing of supporting the @font-face at-rule. Other missing features are missing of some individual property values and some rules, which I have mention in my CSS How to set CSS for table elements (table 1[S], table 2[S]).

If for Opera is necessary to give partially own CSS, I have in an another extra page[S] hints for browser detections.

Opera 7.0 Beta 2 has some setting, which are different compared to other browsers:

Opera 7.x series browsers print worse than 6.x series browsers. In Beta 1 the printing is relative good but bad at least until 7.03 in these respects: