OT: IE8 Madness

Discussion in 'HTML' started by Adrienne, Jun 14, 2009.

  1. Adrienne

    Adrienne Guest

    Recently, I've been lurking in microsoft.public.internetexplorer.beta
    and I'm amazed at how many people are furious with Microsoft for
    pushing out IE8. Mass exodus!


    --
    Adrienne Boswell at Home Arbpen Web Site
    Design Services http://www.cavalcade-of-coding.info Please respond to the
    group so others can share
    Adrienne, Jun 14, 2009
    #1
    1. Advertising

  2. Adrienne

    Neredbojias Guest

    On 13 Jun 2009, Adrienne <> wrote:

    > Recently, I've been lurking in microsoft.public.internetexplorer.beta
    > and I'm amazed at how many people are furious with Microsoft for
    > pushing out IE8. Mass exodus!


    It's an improvement over ie7 but, alas, there are still bugs. Of
    course, I just ran into 2 css-bugs I'd never seen before in Firefox,
    too. Ultimately, all browsers will have bugs - forever. The fewer and
    the less intrusive, the more successful (and eventually popular) the
    browser.

    --
    Neredbojias
    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Jun 14, 2009
    #2
    1. Advertising

  3. Adrienne

    C A Upsdell Guest

    Adrienne wrote:
    > Recently, I've been lurking in microsoft.public.internetexplorer.beta
    > and I'm amazed at how many people are furious with Microsoft for
    > pushing out IE8. Mass exodus!


    I've been in the IE newsgroups for many years, and it is my perception
    that there are *fewer* complaints for IE8 than there were for earlier
    versions, and that many of the IE8 complaints result from its higher
    compliance with standards.

    A lot of designers are annoyed that their broken sites no longer work as
    they used to work, and they get even more annoyed if they are told that
    it is their fault, not the browser's fault. Some people are livid when
    they are told that their sites break with IE because they use Microsoft
    tools which create badly broken code, and they blame Microsoft -- not
    their choice of tools -- when IE8 does not do as they expect.
    C A Upsdell, Jun 14, 2009
    #3
  4. Adrienne

    dorayme Guest

    In article <h139f4$4ch$-september.org>,
    C A Upsdell <> wrote:

    > A lot of designers are annoyed that their broken sites no longer work as
    > they used to work, and they get even more annoyed if they are told that
    > it is their fault, not the browser's fault.


    A bit like some used to get annoyed here that their sites were broken in
    FF and Safari.

    --
    dorayme
    dorayme, Jun 14, 2009
    #4
  5. Neredbojias wrote:

    <snip>


    > It's an improvement over ie7 but, alas, there are still bugs. Of
    > course, I just ran into 2 css-bugs I'd never seen before in Firefox,
    > too.


    Well, what have you discovered? No need to keep them a secret.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Jun 15, 2009
    #5
  6. Adrienne

    Neredbojias Guest

    On 15 Jun 2009, "Jonathan N. Little" <> wrote:

    > Neredbojias wrote:
    >
    > <snip>
    >
    >
    >> It's an improvement over ie7 but, alas, there are still bugs. Of
    >> course, I just ran into 2 css-bugs I'd never seen before in Firefox,
    >> too.

    >
    > Well, what have you discovered? No need to keep them a secret.


    Hah, that question is more difficult to answer than you might believe.
    I run across these bugs in making pages and simply don't have the time
    or inclination to "document" them at the moment; my focus is on getting
    the page to work, not to correct the mistakes of others at the expense
    of my primary goal. Anyway, one of them had to do with z-index
    layering and how something, possibly opacity, negated or changed it
    (-which didn't occur in other browsers.) I still have the old
    trial-version step, and if you really, really, really, need to know can
    revisit it for your edification.

    Just so you're not too disappointed, I encountered 2 bugs in the new
    Safari (4) today. I upgraded from Safari 4 beta (which didn't have at
    least the 1st bug) and now cannot open local php pages. What's the
    story with that? Checked Google and there wasn't much there, but if
    it's "me", why did the beta work? Also, their cache is screwed up:
    doesn't retain contents across pages (basically).

    Cherio.

    (Btw, a new Opera is due for release tomorrow. Maybe I'll get to bash
    that, too.)

    --
    Neredbojias
    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Jun 15, 2009
    #6
  7. Jan C. Faerber, Jun 16, 2009
    #7
  8. Adrienne

    Neredbojias Guest

    On 16 Jun 2009, Ben C <> wrote:

    > On 2009-06-15, Neredbojias <> wrote:
    >> On 15 Jun 2009, "Jonathan N. Little" <> wrote:
    >>
    >>> Neredbojias wrote:
    >>>
    >>> <snip>
    >>>
    >>>
    >>>> It's an improvement over ie7 but, alas, there are still bugs. Of
    >>>> course, I just ran into 2 css-bugs I'd never seen before in
    >>>> Firefox, too.
    >>>
    >>> Well, what have you discovered? No need to keep them a secret.

    >>
    >> Hah, that question is more difficult to answer than you might
    >> believe. I run across these bugs in making pages and simply don't
    >> have the time or inclination to "document" them at the moment; my
    >> focus is on getting the page to work, not to correct the mistakes of
    >> others at the expense of my primary goal.

    >
    > Unless you get to the bottom of it, you can't be sure it's a bug and
    > not you relying on unspecified or incorrect behaviour. The specs
    > allow quite a bit of latitude so differences between browsers don't
    > always imply bugs.
    >
    >> Anyway, one of them had to do with z-index
    >> layering and how something, possibly opacity, negated or changed it
    >> (-which didn't occur in other browsers.)

    >
    > In most browsers setting opacity to anything other than 1.0 causes it
    > to start a stacking context, which affects z-index.
    >
    > opacity is only in CSS 3, but CSS 2.1 hints that setting opacity
    > ought to start a stacking context (and it certainly should-- the
    > alternative is insane).


    That sounds like it (er, the problem) but I'm not sure I follow the
    reasoning. Why should opacity (or anything else) affect a stacking
    order established by z-index? Or is this just a sophisticated way of
    saying they can't do it right so they'll do it somehow?

    As for latitude in specs, yeah, that makes it real easy to construct an
    innovative page, doesn't it?

    --
    Neredbojias
    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Jun 16, 2009
    #8
  9. Adrienne

    Neredbojias Guest

    On 16 Jun 2009, Ben C <> wrote:

    > On 2009-06-16, Neredbojias <> wrote:
    >> On 16 Jun 2009, Ben C <> wrote:

    > [...]
    >>> opacity is only in CSS 3, but CSS 2.1 hints that setting opacity
    >>> ought to start a stacking context (and it certainly should-- the
    >>> alternative is insane).

    >>
    >> That sounds like it (er, the problem) but I'm not sure I follow the
    >> reasoning. Why should opacity (or anything else) affect a stacking
    >> order established by z-index?

    >
    > Because of the way opacity is defined.
    >
    > If you set opacity: 0.5 on an element, it's supposed to look as
    > though that element _and all its descendents_ were rendered into a
    > temporary buffer that was then blended on top of whatever the element
    > is on top of with an opacity of 0.5.
    >
    > If the element didn't start a stacking context, then its descendents
    > could be interleaved with other "foreign" elements from different
    > stacking contexts that have full opacity.
    >
    > This creates a contradiction. If those foreign elements are rendered
    > into the temporary buffer, then they will end up partially
    > transparent, which they shouldn't be as they are not descendents of
    > anything with opacity not equal to 1.0.
    >
    > But if they are not rendered into the temporary buffer, then they
    > can't be interleaved with the descendents of the opacity: 0.5 element
    > and that would break the rules for stacking order.
    >
    > Here is an example:
    >
    > <div id="one" style="opacity: 0.5">
    > <div id="two" style="z-index: 1"></div>
    > <div id="three" style="z-index: 3"></div>
    > </div>
    > <div id="four" style="z-index: 2"></div>
    >
    > Suppose all divs are absolutely positioned, have widths, heights and
    > solid background colours, and overlap each other.
    >
    > According to the rules as they stand, the browser does this (or
    > equivalent):
    >
    > 1. Paint #one into a temporary buffer
    > 2. Paint #two on top of #one in that temporary buffer
    > 3. Paint #three on top of #two
    > 4. Blend the temporary buffer onto the screen at opacity: 0.5
    > 5. Paint #four onto the screen.
    >
    > The stacking order here is #one, #two, #three, #four (because #one
    > starts a stacking context).
    >
    > But if opacity didn't start a stacking context, what would the
    > browser be expected to do?
    >
    > 1. Paint #one into a temporary buffer.
    > 2. Paint #two into the temporary buffer.
    > 3. Paint #four on top of #two, but somehow not into the temporary
    > buffer
    > [impossible because #two _is_ in the temporary buffer]
    > 4. Paint #three on top of #four, into the temporary buffer
    > [impossible
    > because #four _isn't_ in the temporary buffer].
    > 5. Blend the temporary buffer onto the screen at opacity: 0.5
    >
    > The stacking order here would be #one, #two, #four, #three, on the
    > assumption that opacity didn't start a stacking context.


    Criminey! Without perabusing the specs, I would've said the order from
    top-to-bottom is four-three-two-one because two and three are contained
    in/descendants of one (-even tho one has no positioning) and four has a
    bigger z-index than one whose children's z-indexes are at a lower
    stacking level and irrelevant to that of four. Er, is this what you
    said in reverse? Anyway, one and anything contained within it should
    be opacity .5 and four should block out the whole "one thing" solidly.

    Is this what the specs prescribe? FWIW, the situation you proffered is
    similar to the one I encountered. All other browsers blocked-out lower
    levels with the overlaying "four" container while ff simply made it
    transparent (or so appear).

    > The important point about a stacking context here is that it is
    > "atomic": if an element starts a stacking context, you know that it
    > and all its descendents are not interleaved with anything from
    > another stacking context.


    I agree and was not trying to do anything of the sort.

    > It only makes sense to use a temporary buffer for an atomic sequence
    > of objects in a stack. Of course browsers don't necessarily have to
    > actually use temporary buffers, but it has to look like they did, and
    > the specification (which is written in terms of temporary buffers)
    > has to make sense.


    It should work, too.

    --
    Neredbojias
    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Jun 17, 2009
    #9
  10. Adrienne

    Neredbojias Guest

    On 17 Jun 2009, Ben C <> wrote:

    > On 2009-06-17, Neredbojias <> wrote:
    >> On 16 Jun 2009, Ben C <> wrote:
    >>
    >>> On 2009-06-16, Neredbojias <> wrote:
    >>>> On 16 Jun 2009, Ben C <> wrote:
    >>> [...]
    >>>>> opacity is only in CSS 3, but CSS 2.1 hints that setting opacity
    >>>>> ought to start a stacking context (and it certainly should-- the
    >>>>> alternative is insane).
    >>>>
    >>>> That sounds like it (er, the problem) but I'm not sure I follow
    >>>> the reasoning. Why should opacity (or anything else) affect a
    >>>> stacking order established by z-index?
    >>>
    >>> Because of the way opacity is defined.
    >>>
    >>> If you set opacity: 0.5 on an element, it's supposed to look as
    >>> though that element _and all its descendents_ were rendered into a
    >>> temporary buffer that was then blended on top of whatever the
    >>> element is on top of with an opacity of 0.5.
    >>>
    >>> If the element didn't start a stacking context, then its
    >>> descendents could be interleaved with other "foreign" elements from
    >>> different stacking contexts that have full opacity.
    >>>
    >>> This creates a contradiction. If those foreign elements are
    >>> rendered into the temporary buffer, then they will end up partially
    >>> transparent, which they shouldn't be as they are not descendents of
    >>> anything with opacity not equal to 1.0.
    >>>
    >>> But if they are not rendered into the temporary buffer, then they
    >>> can't be interleaved with the descendents of the opacity: 0.5
    >>> element and that would break the rules for stacking order.
    >>>
    >>> Here is an example:
    >>>
    >>> <div id="one" style="opacity: 0.5">
    >>> <div id="two" style="z-index: 1"></div>
    >>> <div id="three" style="z-index: 3"></div>
    >>> </div>
    >>> <div id="four" style="z-index: 2"></div>
    >>>
    >>> Suppose all divs are absolutely positioned, have widths, heights
    >>> and solid background colours, and overlap each other.
    >>>
    >>> According to the rules as they stand, the browser does this (or
    >>> equivalent):
    >>>
    >>> 1. Paint #one into a temporary buffer
    >>> 2. Paint #two on top of #one in that temporary buffer
    >>> 3. Paint #three on top of #two
    >>> 4. Blend the temporary buffer onto the screen at opacity: 0.5
    >>> 5. Paint #four onto the screen.
    >>>
    >>> The stacking order here is #one, #two, #three, #four (because #one
    >>> starts a stacking context).
    >>>
    >>> But if opacity didn't start a stacking context, what would the
    >>> browser be expected to do?
    >>>
    >>> 1. Paint #one into a temporary buffer.
    >>> 2. Paint #two into the temporary buffer.
    >>> 3. Paint #four on top of #two, but somehow not into the temporary
    >>> buffer
    >>> [impossible because #two _is_ in the temporary buffer]
    >>> 4. Paint #three on top of #four, into the temporary buffer
    >>> [impossible
    >>> because #four _isn't_ in the temporary buffer].
    >>> 5. Blend the temporary buffer onto the screen at opacity: 0.5
    >>>
    >>> The stacking order here would be #one, #two, #four, #three, on the
    >>> assumption that opacity didn't start a stacking context.

    >>
    >> Criminey! Without perabusing the specs, I would've said the order
    >> from top-to-bottom is four-three-two-one because two and three are
    >> contained in/descendants of one (-even tho one has no positioning)

    >
    > It only works like that if #one starts a stacking context. If you
    > don't set opacity on #one, the order should be 1, 2, 4, 3. Try it.


    Indeed, I did, and indeed, that is how it is. So, apparently, the fact
    that divs two and three are contained within div one (which is
    positioned) does NOT subordinate the inner divs' stacking context in a
    manner in keeping with other attributes assigned to elements "nested"
    within a positioned container. At least the spec seems to indicate
    thus. And, of course, I think they're dead wrong. What would be the
    problem of doing so? It seems more logical, no?

    >> and four has a bigger z-index than one whose children's z-indexes
    >> are at a lower stacking level and irrelevant to that of four. Er,
    >> is this what you said in reverse?

    >
    > That's what I said in reverse for the case where opacity _does_ start
    > a stacking context.
    >
    >> Anyway, one and anything contained within it should
    >> be opacity .5 and four should block out the whole "one thing"
    >> solidly.
    >>
    >> Is this what the specs prescribe?

    >
    > Yes, assuming opacity does start a stacking context, as it should.


    Well, not only opacity. I took your example -

    <div id="one" style="opacity: 0.5">
    <div id="two" style="z-index: 1"></div>
    <div id="three" style="z-index: 3"></div>
    </div>
    <div id="four" style="z-index: 2"></div>

    ....removed the "opacity: 0.5" and replaced it with "z-index: 0". An
    example page with and without this z-index on div one and the means of
    applying opacity (via javascript) to both can be found at -

    http://www.neredbojias.net/opa_z_tst.html

    The set on the left has no div-one z-index thus allowing div four to
    interleave stackwise between divs two and three which are contained in
    div one, domed on the same "level" as div four. The set on the right
    HAS a div-one z-index of "0" which I assume, like opacity, establishes
    a "stacking context" under current specs and effects operation in a
    manner I believe should be the norm. Mozilla and Safari seem to agree
    to be, uh, "right" (-although doesn't Safari use the or similar to the
    Gecko engine?) Opera, on the other hand, does something different.
    (Explain that one to me... It seems to be worse.)

    --
    Neredbojias
    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Jun 17, 2009
    #10
  11. Adrienne

    Neredbojias Guest

    On 17 Jun 2009, Ben C <> wrote:

    > On 2009-06-17, Neredbojias <> wrote:
    >> On 17 Jun 2009, Ben C <> wrote:

    > [...]
    >>> It only works like that if #one starts a stacking context. If you
    >>> don't set opacity on #one, the order should be 1, 2, 4, 3. Try it.

    >>
    >> Indeed, I did, and indeed, that is how it is. So, apparently, the
    >> fact that divs two and three are contained within div one (which is
    >> positioned) does NOT subordinate the inner divs' stacking context in
    >> a manner in keeping with other attributes assigned to elements
    >> "nested" within a positioned container.

    >
    > Correct. You've effectively got "positioning contexts" (aka
    > containing blocks) and "stacking contexts". The tree of stacking
    > contexts is much flatter for most pages than the tree of positioning
    > contexts.


    Your explanations have been illuminating. If one views "stacking"
    more-or-less on a par with "positioning" but of a different genre, I
    can see the point.

    >> At least the spec seems to indicate thus. And, of course, I think
    >> they're dead wrong. What would be the problem of doing so? It
    >> seems more logical, no?

    >
    > The problem with that is that sometimes you might want something to
    > jump further forward in the stack than its positioning ancestors. If
    > every containing block started a stacking context (which is what
    > you're suggesting) you would be able to do very little with z-index.


    Well...maybe. I would have opted for that very thing since I can't
    to-date image a real need for the other, but perhaps the future will
    bring us more than cylons.

    <snip>

    > Exactly right, z-index: 0 also starts a stacking context, and this is
    > the basic difference between z-index: 0 and z-index: auto (which
    > doesn't).


    Yes, the specs were actually pretty clear on the point of z-index:auto.

    I'm not gonna go dig thru my archives but I'm sure the ff "anamoly" of
    which I spoke was related to the shall-we-say out-of-position stacking
    of something or other. Will have to be more careful henceforth.

    >> Opera, on the other hand, does something different. (Explain that
    >> one to me... It seems to be worse.)

    >
    > Opera have got opacity all wrong. They ignore the whole "temporary
    > buffer" story and give each box a sort of "alpha value" which is the
    > product of the opacities of its ancestors.
    >
    > Then they just draw in the same stacking order as normally (opacity
    > doesn't affect it) blending each box according to the alpha value
    > they gave it on top of whatever's below it.
    >
    > Here is another test which demonstrates that their rendering is not
    > equivalent to using a temporary buffer:
    >
    > http://www.tidraso.co.uk/misc/opacityContexts.html
    >
    > You have to look closely so this diagram explains how Opera gets it
    > wrong:
    >
    > http://www.tidraso.co.uk/misc/opacityContexts.png


    Good thing you posted that last link because I wasn't sure what I was
    seeing besides a pretty picture. Btw, it would help to have a
    (page-determined) background.

    Btw btw, I uploaded of niftier example of the example:

    http://www.neredbojias.net/opa_z_tst.html

    A little passe, I know, but...

    --
    Neredbojias
    http://www.neredbojias.org/
    http://www.neredbojias.net/
    Neredbojias, Jun 18, 2009
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Todd

    Session Variable Madness

    Todd, Jan 21, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    421
  2. V. Jenks

    RadioButtonList madness!

    V. Jenks, Apr 19, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    460
    Ashish M Bhonkiya
    Apr 19, 2004
  3. =?Utf-8?B?QUNhdW50ZXI=?=

    Audio Madness @#!#@

    =?Utf-8?B?QUNhdW50ZXI=?=, Feb 26, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    383
    =?Utf-8?B?QUNhdW50ZXI=?=
    Feb 26, 2005
  4. Marius Horak

    Madness, I call it madness

    Marius Horak, Jun 4, 2004, in forum: ASP .Net Datagrid Control
    Replies:
    2
    Views:
    157
    Raterus
    Jun 4, 2004
  5. cecile

    ie8!=ie8

    cecile, May 24, 2010, in forum: Javascript
    Replies:
    2
    Views:
    184
    David Mark
    May 24, 2010
Loading...

Share This Page