ToC 5... debugging page

go to debugging notes

GårdsdriftenFarming (rev:14.jun.2004)

debugging-phase..... (01.feb.2005 ...)

Last Update: 21.nov.2005: I've picked as many ideas out of this test-page as I possibly can, and used them to fine-tune some real pages, like my web design menu. All comments below are made during the early debugging-stages, and are mostly of purely academical interest now.

The solution used will work in all standard-compliant browsers, and IE5+/win (with IE6 in quirks mode). Time for me to move on.

So, this is as far as I've come. Using "position: fixed" may reduce the amount of layout elements in a page like this to a minimum, while giving me plenty of options when it comes to styling a page.

The layout method is described more in detail here, and is working quite well in Opera, Firefox, Safari and IE6. Lynx is also fine with the source-order used. IE/Mac won't render much (it doesn't like @media rules — so that's it).

I've blocked some future panel-switching for multiple languages, so there is some "noise" in the page source. That's not an issue.

Despite everything, some more problem-solving needed before this is a complete cross-screen and cross-browser solution. I'd like to know the limits, so they can be overcome or avoided.

Update: 03.feb.05: IE6 no longer pose a problem — apart from relying on activated javascript for its expressions to work. See below. Only 4 minor bugs/problems left to look into...

Update: 04.feb.05: some minor design-changes. Finetuning position of sidebar, and width of footer. More nasty bugs found in Firefox. Mozilla and Safari aren't doing too well either. Se below.

Update: 05.feb.05: new versions of Mozilla are doing better. Firefox still buggy. See below.

Update: 06.feb.05: A solution to the 'General 'position: fixed' problem' also avoids most browser-weaknesses. Opera and Safari are close to perfect. IE6 is doing quite well, and Moz/FF do their 'text-dance' buggy. See below.

Debugging status: 06.feb.05: Pretty well there, so I can copy this layout back into the main site-folder in a few days time, and start populating it with some real content and include the site-wide style-swapper. A few variants of this styling are also ready for launch, as replacements.
Now, if I wanted to add anything, it might be shadows on both page-edges. These will only be visible on wide screens, so I can leave them till later. A dozen other style-ideas are also waiting to be tested.

Update: 12.feb.05: Gecko-browsers are slow repainting with fixed positioning, so I've releaved them from some of the stuff. I'm also testing a few ordinary 'design-features', that may end up being used sitewide.

Update: 13.feb.05: The winner is: Opera. See below.

Possible (human) bugs

  1. IE6: Hover only works reliable on the text itself in links in main part of the menu above. Some links working "full-space" some of the time, and some not at all. Sidebar-links are fine all the time. (IE6 is in quirks mode — by choice).
    - Have tried most tricks, but have probably missed the right one...
    - Yes, I'd missed it, as pointed out via css-d. Thanks Ingo.
    solved 1: by changing z-index on the centered background-text from 0(zero) to -1, the interference was eliminated. This also eliminated the need for some extra source-code for IE/win. Looks like anchors defaults to z-index: 0 in IE, despite any definition in CSS [updated: 03.feb.05]
    solved 2: by adding "margin-bottom: -1000px; position: relative;" to my "sidebar float" - in IE/win only, the zero height, "fixed positioned" container that holds the sidebar, now holds its zero height— instead of being expanded (invisible) in IE/win and interfering with links in the main column. [updated: 03.feb.05]
    Update: IE6 is very sensitive to the order in its commented stylesheet, because of the many expressions used. The bug surrounding link:hover is best killed by applying a blank or non-existent background-image to the links. [updated: 06.feb.05]
  2. Safari1.2.4 and Mozilla1.7.2 won't apply min-width to any fixed elements. Min-width is working for the rest of the page, but fixed elements, like the sidebar, may overlap on narrow windows. [updated: 04.feb.05]
    - Not much of a problem, but is there a workaround?
    - Is this problem present in latest version(s)?
    Update: Safari won't apply 'width: auto' on fixed elements. Have a work-around, using percentages, at the moment. It's not a good solution. [updated: 04.feb.05]
    - What can I do for Safari?
    Update: response from Phil on css-d says Mozilla1.8 do apply min-width correctly. No hacking for Moz needed then... [updated: 05.feb.05]
    Update: avoided problems in Safari through the solution to the General 'position: fixed' problem. [updated: 06.feb.05]
  3. Firefox1.0-pre seems to be a bit slow to update position for the fixed sidebar. Not much of an issue on fast computers like mine, but there's a visible "shaking" when I scroll. Not sure what will happen if I add more fixed elements.
    - Does this "shaking" looks bad on slow computers now?
    Update: if we hover anything on a window below min-width: 600px, Firefox shakes the sidebar like mad — or rather briefly "copies" it in a new position. This is caused by a bug related to 'overflow: auto'.
    - Is this bug present in latest version(s)?
    Update: response from David says FF1.0 is still buggy. I can not correct FF alone, so "below min-width" is no good. [updated: 05.feb.05]
    Update: the solution for General 'position: fixed' problem also avoids the 'overflow: auto' bug in Firefox, by moving that rule from 'position: fixed' to 'default position: static'. Gecko-browsers still have a font-size instability bug, which may be solved in future versions. [updated: 06.feb.05]
    Update: the fixed background in the center is gone. Firefox, and Gecko-based browsers in general, are too slow repainting when page is scrolled, so it ended up looking a bit too ugly. Several other shortcomings in Gecko-browsers are avoided by simply not rendering it in those browsers. [updated: 12.feb.05]
    Update: Firefox, and Gecko-based browsers in general, screw up on positioning of anything in relation to a fixed element. That is: 'position: relative' or 'position: absolute' on any element inside a fixed element causes extreme delays and positioning-errors on reflow/repaint. Still working on it. [updated: 13.feb.05
  4. Opera7.54 shrinks the height of the "the norwegian cow..." image at the top, on windows wider than 1000px. That's 'max-width: 500px' set on the image itself, and it has a width of 50% of the outer container, and a height of 55px (that is shrinking).
    - Is this bug present in latest version(s)?
    Update: no news on this one, so I created a workaround: I'm wrapping the image in a div and scaling this div, with the image at height/width 100% of the div. [updated: 06.feb.05]
    Update: Opera can handle a lot more positioning, so I've added some for the future — today.
    More to come... [updated: 12.feb.05]
    Update: Opera seems to have no problems whatsoever with nested and positioned elements inside 'position: fixed' elements. No noticeable delays or visible positioning-errors on reflow/repaint — even with heavy nesting.
    The future looks good.
    Note: don't feed these nested styles to Gecko-browsers, until their engine is improved. [updated: 13.feb.05]
  5. General 'position: fixed' problem: Is there a way to width-limit the page with fixed positioned elements and all, and still make centering work? I've tried several methods, but haven't found a way to control fixed positioned elements while keeping their width flexible within limits.
    - Any working solutions?
    Update: a solution found, which involves an extra, static, wrapper inside each fixed element (2 in this page), to separate the visual from the actual display. Width-limits and centering is applied to these static wrappers, so it all appears as I want it - across browser-land. Don't like these extra elements, but 'position: fixed' is not all that web-author friendly. The source-code is still quite light, so I think I can live with it for a while. [updated: 06.feb.05]
Georg; sign.

All inputs are most welcome