browser bugs

… bugging my site

While evaluating how various browsers behave when surfing my site, I do of course notice bugs and weaknesses in some browsers. In order to see if there is something I can, or should, do to work around observed bugs and weaknesses, I write down the most disturbing ones.

Very few browser bugs and weaknesses are total show‐stoppers. Most just make things look different, and maybe even ugly. Usually no big deal unless you are a designer yourself, and/or are too hung up in details.

On rare occasions a bug may prevent access to important content and/or functionality on a page, and then we do of course have some real problems on our hands for which solutions must be found.

browser bugs

  1. Not handling some cases with single INPUT properly.
    Bug affecting page(s): CSS-only Q & A lists
    Peculiarities: forcing rerendering by zooming page or otherwise, makes last clicked INPUT work.
    Browser(s): on WebKit engine.
    Temporary: solved in WebKit Chromium 32/WK537.36.
  2. Not handling some cases with multiple INPUT properly.
    Bug affecting page(s): CSS-only Q & A lists
    Note: probably same as previous bug.
    Browser(s): on WebKit engine.
    Temporary: solved in WebKit Chromium 32/WK537.36.
  3. Rendering problems for layered and positioned elements involving multiple INPUT.
    Bug affecting page(s): tabbed content.
    Browser(s): IE10 and many browsers using Trident engine.
    Note: not affecting all browsers using Trident engine.
  4. Does not handle Javascript as expected.
    Bug affecting page(s): this page, and all pages coded with script to “open/​close Addendum”.
    Browser(s): Epic.
  5. Bad alignment of absolute positioned elements.
    Bug affecting page(s): tabbed content.
    Browser(s): Midori.
  6. Flawed layering (computed z-index level) for generated content with opacity set lower than 1.
    Bug affecting page(s): all examples removed, as they could not be worked around.
    Browser(s): IE8/IE9/IE10, and all browsers using same Trident engines.
  7. Images with display: table declared, shrink into zero width/height.
    Bug affecting page(s): all examples removed, as such a case is pretty irrelevant and easy to avoid.
    Browser(s): IE8/IE9, and all browsers using same Trident engines.
    Fixed in IE10.
  8. Text with display: table declared, lose text-shadow.
    Bug affecting page(s): destructive design.
    Browser(s): IE10.
    Fixed in IE11.
  9. Text with negative text-indent declared, get cut at the end.
    Bug affecting page(s): destructive design.
    Browser(s): IE10/IE11.
  10. Transparent generated content background overlays used for area-links, must have a bg-image in them to cover designated area and function properly.
    Bug affecting page(s):NATO News link in side-column (fixed).
    see also: generated content: link styling (2)
    Browser(s): IE9/IE10. Seems to have been fixed in IE11.
  11. white-space: pre unreliable.
    Bug affecting page(s): most pages with pre.

     Browser(s): Opera30 and seemingly more/all browsers on some versions on the Blink engine.
  12. PNG images with position: relative declared on them or their parent-elements are not rendered reliable. Random PNG images - both foreground and background - flicker or get “resized” (blown up within their initial outline) when pages are scrolled. May be linked to the OS: win10, as it wasn't observed in IE11 on win7.
    Bug affecting page(s): most pages – especially those with floating PNG images in sidenotes.
    Cause: Microsoft browsers's dependency on the OS creates all sorts of problems when resources are running low.
    Browser(s): IE11, Microsoft Edge 13.
  13. Unreliable border rendering, both on links and other elements. Some borders may simply disappear when scrolling. May be linked to the OS: win10, as it wasn't observed in IE11 on win7.
    Bug affecting page(s): any page.

     Cause: Microsoft browsers's dependency on the OS creates all sorts of problems when resources are running low.
    Browser(s): IE11, Microsoft Edge 13.
  14. Images “lost in space without a trace”, not to reappear under any condition.
    Bug affecting page(s): any page.

     Cause: Have no idea, yet.
    Browser(s): Behavior only observed in Pampa 4.0.
  15. Occasional rendering of misplaced and more or less complete copies of elements that have opacity declared. Totally erratic and unstable behavior, as these artifacts may or may not show up, or be corrected, after page-reload.
    Bug affecting page(s): originally all, but see bug chasing.
    Cause: Affected browsers seem to have problems with opacity set on, or rendered over, generated content.
    Browser(s): First noticed in Chrome, Opera & Vivaldi in July 2017. May affect all browsers on later versions of the Webkit / Blink engines.

     Workaround: I have found and commented out opacity in the style-combos these browsers mishandled, and thereby confirmed that the bug is real enough.
  16. Text following right-floated image inside head­line (typically first H2 on all pages), does not recognise the existence of the image if shape- is declared on it. The text-tail ends up getting covered by the image instead of dropping to new line on narrow windows.
    Text (paragraphs etc.) after the head­line, inter­acts correctly with over­shooting part of the float + shape- styled image that ends up below the headline.
    Bug affecting page(s): any page with that combo. See: a caveman's look at the digital age on very narrow windows/​screens (one-col for small cell-phone screens) as typical example.
    Browser(s): All browsers on Chromium / Blink I have tested. Tested on Windows and Android OS'es.
    Workaround: Wrapping text after floating image in a span, declare a z-index with higher value than the image on that span, and let the text flow in front of the image instead of behind it.
    Declaring max-width on the text is an alter­na­tive workaround.
  17. Vertical scroll capability failing after page-load on some sites.
    Cause and effect not clear … keeping an eye on this bug after each browser-update.
    Browser(s): only Vivaldi on Win10.
    Site(s): Elektroimportøren.no

More bugs will be noted as they are discovered.

browser weaknesses

  1. Rounded borders missing/​proprietary only.
    Affecting page(s): all pages.
    Browser(s): IE8 and older on Trident engine. Older Gecko engines.
  2. Box shadow missing/​proprietary only.
    Affecting page(s): all pages.
    Browser(s): IE8 and older on Trident engine. Older Gecko engines.
  3. Text shadow missing/​proprietary only.
    Affecting page(s): all pages.
    Browser(s): IE9 and older on Trident engine. Also found in older browser versions any brand.
  4. Lacking in basic Unicode support.
    Affecting page(s): all pages.
    Browser(s): QtWeb, Links & WebbIE. Same weakness also found in older browser versions any brand.
  5. Bad text rendering.
    Affecting page(s): all pages.
    Browser(s): Midori.
  6. Overrides font-size.
    Affecting page(s): all pages.
    Browser(s): Google Chrome.
  7. Text shadow wonky.
    Affecting page(s): all pages.
    Browser(s): Arora.
  8. Unstable positioning of generated content with content offset from its background. One piece of generated content styled this way that is part of the “heading”, is missing, presumably positioned off screen.
    Affecting page(s): all pages.
    Browser(s): AOL 9.7 (older WebKit / Chrome 21).
  9. CSS support limited to CSS 2.1 level.
    Affecting page(s): all pages.
    Browser(s): IE8.
    Note: nearly all CSS hacks on site are related to optimizing rendering wherever possible in this old IE version. IE8 and older versions are no longer supported.
  10. Old engine cannot position generated content outside original container. See: 10.
    Affecting page(s): all pages.
    Browser(s): all on older WebKit / Chrome engines.
  11. Cannot access and modify existing address in address/search field directly, to for instance add an in-page :target ID.
    Affecting page(s): any page.

     Browser(s): Only observed in Pampa 4.0 so far.
  12. Failing CSS filter functionality despite claiming support.
    Affecting page(s): any page.

     Browser(s): MS Edge (12 - 14).
    Note: I choose to ignore this weakness/bug in this browser.

what browsers are in use

I have a rough idea about what browsers are in use… Browser usage share - Source: Wikipedia
… but details are a bit more unclear. No big deal really, as no matter what they are called nearly all browsers in somewhat regular use are built around versions/​variants of the same 3 rendering engines.

Browsers are not necessarily using the same, or latest, engine versions though, and this causes most problems. Web designers design in and for the latest versions and their bugs and weaknesses, and don't want to also be bothered with older versions' bugs and weaknesses.

End‐users on the other hand all too often can not, or will not, update their browser or switch to a better one once they have figured out how to use the one they got. Some even turn off automatic update in browsers that have that option.

Browser‐land looks somewhat chaotic, with a lot of alternative browsers available. That some of these browsers use outdated engines, and are too weak and buggy for today's web, is an understatement. Luckily the number of such weak browsers in actual use, is relative small.

We who design for the web today, may at best make a note when we see how bad certain minority/​alternative browsers do their job. After that we can for the most part simply ignore them.

sincerely  georg; sign

Hageland 01.apr.2012
last rev: 25.jul.2023

side notes.

naming a browser bug

I call it a browser bug when: a browser is supposed to handle a HTML/​CSS combination in a particular way – in accordance with web standards, but instead handles it badly and/or not at all.

What the browser vendor claim their browser supports, is of course crucial when identifying browser bugs. What they don't claim support for, can not be called bugs in the regular meaning of the word “bug”.

naming a browser weakness

I call it a browser weakness when: most browser handle a HTML/​CSS code‐snut in a particular way, but one browser because of deviating interpretation and/or aging engine handles it different or not at all.

Older browser versions quite naturally often show weaknesses when served designs styled for the latest and greatest browsers. Failures are usually not serious enough to cause real problems, but now and then workarounds have to be found for a weak and failing browser.

I may also call it a browser weakness when: browser's own functions deviate from “the norm” in ways that makes it less useful for me personally, and does not allow me to manually change the problematic behavior. Such functional deviations may not affect how the browser renders pages, only reduce the usefulness of the browser itself.

handling temporary failures, or not…

Regressions do occur in browsers, as new versions may be released prematurely containing undiscovered bugs and weaknesses not found in previous versions.

Such “temporary failures” are usually discovered pretty quickly once browsers are put under scrutiny by many end‐users on the world wide web, and fixed in later version releases. Thus, I usually do not try to find workarounds in my own designs for what I expect to be short‐lived setbacks in otherwise good browsers.

a bug is a bug when…

What is written in web standards is important in and off itself, but standards frequently are rewritten to reflect what browsers actually do. Along those same lines, I decide if a bug is a bug based on my interpretations of web standards and actual behavior in the majority of browsers.

As a simple example: that some elements, borders, text or images are rendered ±1 pixel off in one browser compared to in others, is in my view acceptable deviations that at best may be characterized as minor weaknesses.

If deviations grow to ±2 pixels or more with none of my own HTML/​CSS flaws to blame, then something is seriously wrong. That is when I start suspecting “browser bugs” to be playing tricks on me.

Have in later years only seen really large deviations as the result of multi‐element alignment, where small deviations add up – see: loony lineup. And, even that example does not cause real problems for my designs.

There are a few potential “browser bugs” on site that I haven't listed yet. Need to study them a little while longer before making up my mind what to call them, and whether to work around or simply ignore them.

not too hasty

As you can see: I am pretty relaxed about the entire “browser bug” issue. After all, most “bugs” are the result of flawed coding at my end, and browsers can't be blamed for those.

There are a few of my very own “designer bugs” left on this site. I know where they are and how to fix them, but they are not serious enough to demand quick fixes for, so they may be around a little while longer.

general comments on browser engines

  1. a) WebKit engines used in some alternative browsers, show some age-weaknesses.

     b) Blink engines are new, and can for the time being not be differen­tiated from latest WebKit engines.
    c) WebKit engine used by Microsoft Edge can for the time being not be differen­tiated from latest WebKit engines. Microsoft have however added some exclusive “ms-signs”.
  2. a) Gecko engines used in some alternative browsers, show some age-weaknesses.
    b) For Gecko engines released in later years – from version 20 or so – I expect excellent standard support on screens.
  3. a) Trident shells do, for obvious reasons, for the most part show same bugs and weaknesses as my local IE11, although some alternative shells actually seem to do slightly better than the genuine IE11.

tools

css support, etc

short and incomplete notes

I am famous for writing short and incomplete notes, that others often simply cannot make heads or tails of. Cannot help it I'm afraid, as keywords and short phrases are all I need to trigger my own thought-pro­cesses.

On-line notations about browser bugs and weaknesses vary greatly, from very detailed to nonsensical to nonexisting. Here follows a selec­tion…

There are of course also all the lists of bugs in browsers that are long since obsolete, but they only makes for a bit of fun read for us who had to battle all those bugs back in time.

I do like a good read of web standards and drafts, and also about browsers' standards support and failures, with my break­fast. Not so much that I want to get involved though – all that is in the past for me.

What interests me is what I can and can not do regarding design in latest browser versions. Always something I haven't thought of yet, and the various sources often present ideas worth looking into.

mobiles vs desktop

Although I do design for mobile devices as well as desktops, I'm not too concerned about the potential and/or real differences in how browsers handle standardized web page code on various devices. Think “touch screens” vs “mouse pointers” vs “keyboard navi­ga­tion” for on-site func­tion­ality and navi­ga­tion.

My simple philosophy is that those who make devices and those who create software for them, also should make sure they actually work with stan­dard­ized web page code. It most certainly isn't my responsi­bility to fix them.

If everyone and their dog who build and populate web sites should come up with their own solutions for device depen­dent con­flicts and failures, we will be worse off than back in time when we had to hack around old IE6/7.
It was kind of fun then, but it wouldn't be fun to have to go through all that again, and again, and again.

I will continue to serve responsive designs to browsers on any screens and devices, and leave any problems caused by the device itself to whomever it concerns.

www.gunlaug.com advice upgrade advice upgrade navigation