Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > OT: IE8 Madness

Reply
Thread Tools

OT: IE8 Madness

 
 
Adrienne
Guest
Posts: n/a
 
      06-14-2009
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


 
Reply With Quote
 
 
 
 
Neredbojias
Guest
Posts: n/a
 
      06-14-2009
On 13 Jun 2009, Adrienne <(E-Mail Removed)> 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/
 
Reply With Quote
 
 
 
 
C A Upsdell
Guest
Posts: n/a
 
      06-14-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!


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.

 
Reply With Quote
 
dorayme
Guest
Posts: n/a
 
      06-14-2009
In article <h139f4$4ch$(E-Mail Removed)-september.org>,
C A Upsdell <(E-Mail Removed)> 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
 
Reply With Quote
 
Jonathan N. Little
Guest
Posts: n/a
 
      06-15-2009
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
 
Reply With Quote
 
Neredbojias
Guest
Posts: n/a
 
      06-15-2009
On 15 Jun 2009, "Jonathan N. Little" <(E-Mail Removed)> 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/
 
Reply With Quote
 
Jan C. Faerber
Guest
Posts: n/a
 
      06-16-2009
On 14 Jun., 04:39, Adrienne <(E-Mail Removed)> 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!


They take back -
http://www.osnews.com/story/21657/Wi...orer_in_Europe
 
Reply With Quote
 
Neredbojias
Guest
Posts: n/a
 
      06-16-2009
On 16 Jun 2009, Ben C <(E-Mail Removed)> wrote:

> On 2009-06-15, Neredbojias <(E-Mail Removed)> wrote:
>> On 15 Jun 2009, "Jonathan N. Little" <(E-Mail Removed)> 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/
 
Reply With Quote
 
Neredbojias
Guest
Posts: n/a
 
      06-17-2009
On 16 Jun 2009, Ben C <(E-Mail Removed)> wrote:

> On 2009-06-16, Neredbojias <(E-Mail Removed)> wrote:
>> On 16 Jun 2009, Ben C <(E-Mail Removed)> 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/
 
Reply With Quote
 
Neredbojias
Guest
Posts: n/a
 
      06-17-2009
On 17 Jun 2009, Ben C <(E-Mail Removed)> wrote:

> On 2009-06-17, Neredbojias <(E-Mail Removed)> wrote:
>> On 16 Jun 2009, Ben C <(E-Mail Removed)> wrote:
>>
>>> On 2009-06-16, Neredbojias <(E-Mail Removed)> wrote:
>>>> On 16 Jun 2009, Ben C <(E-Mail Removed)> 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/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ie8!=ie8 cecile Javascript 2 05-24-2010 09:04 AM
Re: Advantages of IE8/64 over IE8/32 PA Bear [MS MVP] Windows 64bit 0 08-17-2009 09:43 PM
OT: Monday Madness =?iso-8859-1?Q?Frisbee=AE?= MCSE 15 03-22-2005 06:47 PM
Madness, I call it madness Marius Horak ASP .Net Datagrid Control 2 06-04-2004 02:28 PM
Cisco PIX 501 madness ... help stevo321 Cisco 5 04-11-2004 10:02 AM



Advertisments