Coffeehouse Thread

29 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

IE 8 is far away from prime time...

Back to Forum: Coffeehouse
  • User profile image
    elmer

    God that "reply-to" thing is annoying... I always forget to set it to "Reply to Root" when posting a general comment.

    Anyway... the other thing I've noticed about IE8 printing is the sheer size of the output.

    As an example... printing a particular webpage I visit with FireFox generates about 1.5MB of PCL output... big, but expected.

    Printing the same page with IE8-B2... OMG... 16MB... and then I have to kill the print job, because my LaserJet will take all day to grunge through that lot.

    This means that, at the moment, any time I want to print a webpage, I fire up FireFox.

    Again, I suspect that the problem is that IE8 is printing background images regardless of the tools setting (which I have set to NO) and when people don't use a specific media CSS to disable it,  IE8 prints stuff like body-backgrounds, and presemably uses PCL graphics.

  • User profile image
    phreaks

    fabian said:


    Maybe, but you know what's not?


    Jack Bauer.

  • User profile image
    intelman

    littleguru said:
    intelman said:
    *snip*

    I hope they make the best out of it Smiley

    One thing that I really LIKE about IE8 are the suggestions in the search text box. That's a nice idea and was very handy a few times.

    Idea that is in Firefox already. Plus Firefox doesn't crash as much.

    IE has the best zoom still, I think that is where they lead. Speed, they lose, stability, they lose, UI, they lose....

    It will take a lot for me to use IE8. If the stability is improved (which I am sure it will be) that will help a lot. But even then, what am I gaining by using IE instead of Firefox or Chrome.

  • User profile image
    warren

    vesuvius said:
    warren said:
    *snip*
    I didn't mention a Release Candidate. I pray for a beta 3 though.

    Edit:  Would the mothership ship with an unfinished IE8 in Windows 7, seeing as this is the only public beta for the new OS?

     IE8 should be "leaps and bounds" ahead by now, but it is not!
    I meant to quote the original poster, not you... sorry, friend. Smiley

  • User profile image
    joechung

    Accessing the IE-proprietary filters collection in JavaScript fails; CSS repeating background image fail to cover the whole element, often leaving one transparent pixel uncovered on edges; setting CSS height and width in scripted animations leaves dirty artifacts due to incorrect redraw optimizations; and -- most disturbing -- IE8's CSS 2.1 standards implementation seems to have regressed. Pages that worked in Firefox, Safari/Chrome, Opera, and IE 8 Beta 2 fail in IE 8 RC1.

  • User profile image
    sushovande

    Just my 2 cents: I love IE8 and have been using it quite a bit.. I know it crashes a few times, but I like the fav bar, the in private mode, in private blocking, nice set of dev tools and search suggestions. Those are enough for me to stick around, so no IE7 for me Smiley

  • User profile image
    elmer

    Got stung by IE8-B2 again yesterday.

    I wrote a 'contact us' webform for a customer, for which most content was normal flow, some contained floating elements and a there were a couple of absolutely positioned divs.

    Nothing extraordinary, no hacks, and FFox, Safari, Chrome and even Opera all dealt with it exactly as I expected, without any problem.

    IE... a blank page... WTF ??

    After much screwing about, I managed to resolve the display of the normal flow content, by setting the containing div display types to 'inline-block' - which meant that all the other browsers were immediately unhappy... so I worked around that by forcing IE7 compatibility mode and using expression(‘inline-block’) so that the other browsers all continued to work.

    **EDIT: A bit more time with it, and I realised that this is the age-old 'has-layout' problem of IE, as the divs have position:relative and width/height settings of auto... so IE fails to display them. The 'inline-block' for IE is a trigger for 'has-layout' which allows them to be displayed. Once I recognised the problem, I realised that I could eliminate the stupid expression() hack, and instead implement the trusty old 'zoom:1' hack... to give IE it's required 'has-layout' status, while using display:block... and not bog down the page with expression() scripts.**

    However... the AP’d divs were still missing... so more experimenting and sleuthing ensued... and after many MANY wasted hours and banging of head on the desk... I finally found that when IE encounters an AP’d div that has a sibling which is not AP’d and which contains a float... it just doesn’t display it. What clued me into the problem was that when inspecting the html with the developer tools, and clicking on the AP’d node, it would suddenly appear on the screen... like it needed a wakeup call. Anyway, more experimenting and I found that putting an empty <div></div> in between the two gave it the smack up the side of the head required, and IE finally looked the way all the other’s looked on first try.

    I then did some hunting about on the internet, and found that this mess has been around since the olden days of IE and is *still* not fixed... so I went back and check the original problem against IE7 and IE6 and, sure enough, they has the same issues and required the same solution.

    Much as I’d love to believe MS are going to sort this all out before IE8 is released, I'm already starting to resign myself to 4-5 more years of IE-Work-arounds, as these are both problems we've been living with in IE since V5

  • User profile image
    joechung

    elmer said:
    Got stung by IE8-B2 again yesterday.

    I wrote a 'contact us' webform for a customer, for which most content was normal flow, some contained floating elements and a there were a couple of absolutely positioned divs.

    Nothing extraordinary, no hacks, and FFox, Safari, Chrome and even Opera all dealt with it exactly as I expected, without any problem.

    IE... a blank page... WTF ??

    After much screwing about, I managed to resolve the display of the normal flow content, by setting the containing div display types to 'inline-block' - which meant that all the other browsers were immediately unhappy... so I worked around that by forcing IE7 compatibility mode and using expression(‘inline-block’) so that the other browsers all continued to work.

    **EDIT: A bit more time with it, and I realised that this is the age-old 'has-layout' problem of IE, as the divs have position:relative and width/height settings of auto... so IE fails to display them. The 'inline-block' for IE is a trigger for 'has-layout' which allows them to be displayed. Once I recognised the problem, I realised that I could eliminate the stupid expression() hack, and instead implement the trusty old 'zoom:1' hack... to give IE it's required 'has-layout' status, while using display:block... and not bog down the page with expression() scripts.**

    However... the AP’d divs were still missing... so more experimenting and sleuthing ensued... and after many MANY wasted hours and banging of head on the desk... I finally found that when IE encounters an AP’d div that has a sibling which is not AP’d and which contains a float... it just doesn’t display it. What clued me into the problem was that when inspecting the html with the developer tools, and clicking on the AP’d node, it would suddenly appear on the screen... like it needed a wakeup call. Anyway, more experimenting and I found that putting an empty <div></div> in between the two gave it the smack up the side of the head required, and IE finally looked the way all the other’s looked on first try.

    I then did some hunting about on the internet, and found that this mess has been around since the olden days of IE and is *still* not fixed... so I went back and check the original problem against IE7 and IE6 and, sure enough, they has the same issues and required the same solution.

    Much as I’d love to believe MS are going to sort this all out before IE8 is released, I'm already starting to resign myself to 4-5 more years of IE-Work-arounds, as these are both problems we've been living with in IE since V5
    Did you undo the IE 7 compatibility mode and try to reproduce that bug?  If you left it on, you're basically getting behavior as designed since IE 7 compatibility mode in IE 8 strives to be as much like IE 7 as possible, including bugs.

  • User profile image
    elmer

    joechung said:
    elmer said:
    *snip*
    Did you undo the IE 7 compatibility mode and try to reproduce that bug?  If you left it on, you're basically getting behavior as designed since IE 7 compatibility mode in IE 8 strives to be as much like IE 7 as possible, including bugs.
    Yes... and it didn't work.

    I actually deveoped with FireFox, and the galling part is that every other browser renders exactly as expected... only IE continues to give me grief, regardless of the mode, and requires me to implement hacks to fix it.

  • User profile image
    esoteric

    PaoloM said:
    spivonious said:
    *snip*
    I'm using Chrome and it's all fast and stuff, but it croaks on a number of sites (codeplex, etc). So it's still IE at Casa Paolo...
    That describes my use of Internet Explorer as well - as a fallback. Still, beta is beta and there is a chance that the UI can become less bloated and it can become faster. I doubt half of that though ("by design" | "wohn't fix").

  • User profile image
    JeremyJ

    elmer said:
    joechung said:
    *snip*
    Yes... and it didn't work.

    I actually deveoped with FireFox, and the galling part is that every other browser renders exactly as expected... only IE continues to give me grief, regardless of the mode, and requires me to implement hacks to fix it.
    I have a feeling that since there is "work-arounds" that they get pushed lower in the priority list to fix.  If that is truely the case then I wish the practice would stop.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.