OT: IE8 Madness

[Adrienne]

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!

 

[Neredbojias]

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.

 

[C A Upsdell]

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.

 

[dorayme]

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.

 

[Jonathan N. Little]

Neredbojias wrote:

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.

 

[Neredbojias]

Neredbojias wrote:



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.)

 

[Jan C. Faerber]

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!

They take back -
http://www.osnews.com/story/21657/Windows_7_Will_Ship_Sans_Internet_Explorer_in_Europe

 

[Neredbojias]

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.


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]

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]

[...]
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?

That's what I said in reverse for the case where opacity _does_ start
a stacking context.


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]

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.

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.

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 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...