primeSix at the New School
about

Here is where you can find discussion of issues and questions that come up in Antonio's, Avi's or Bob's courses at the CIC/Parsons. Look for information that goes beyond what we can cover in class to appear here.

archive

my links

link #1
link #2
etc

 

RSS feed

This page is powered by Blogger. Isn't yours?

Subscribe to nsu_primesix
Powered by groups.yahoo.com

2003/02/04

 
Web Standards Wiggle Room Revisted, More or Less (mostly less)
You can't believe everything you read, particularly when you don't read carefully enough. There is wiggle room in the standards, but not on the topic of my previous post!

Related page for this posting: http://bugzilla.mozilla.org/show_bug.cgi?id=184522

Well, you can't always believe what you read. I mean that a couple of ways. In my last post, I talked about how Web Standards, such as the W3C standards for CSS, necessarily leave some wiggle room for how browsers implement the standards. For example, what border-styles of outset or inset are suppose to look like is up to the interpretation of the browser designers.

When it comes to the z-index property, however, I was wrong. If you check out the Bugzilla report in the link above, you can catch how this bug played out just a bit -- from my initial posting to one of Mozilla's people specifying in the standard where it said Gecko is wrong, to Eric Meyer's mea culpa. What he said in his reference book was wrong. I was a bit too careless in my reading of the standard and, so, was wrong. And Gecko's implementation of the standard is wrong, while IE's is correct.

... but I still like Gecko/Mozilla's solution better.


finelineBob 2/4/2003 01:29:39 PM

2003/02/03

 
Wiggle Room in Web Standards
Web standards are not commandments etched in stone. They do their best to specify the most important issues on which agreement is needed, but there is almost always some wiggle room....

Demo page for this posting: http://newschool.thefineline.org/demos/dhtml/basics/pos-el-z.html

In my Advanced Web Design class last term, we looked at an example of some basic DHTML -- clicking on a positioned element to bring it to the top of a stack of overlapping "boxes". I noted at the time that the behavior of the page in Internet Explorer versus that in Mozilla was different. Same HTML, same CSS, same JS: slightly different results. I also mentioned at the time that IE, for a change, was correct in how it was rendering the page, and Mozilla (very big surprise here) was wrong.

[BZZZZZZZZZZT!] "Wrong answer, Mr. Boyle, and thank you for playing Browser Family Feud."

Both of the browsers are correct. Well, not necessarily correct, but certainly within the bounds of the CSS2 standards published by the W3C. How can that be: that the same HTML, same CSS, and same JS (which actually is not a W3C standard, by the way) can produce different results in different browsers and both of them be correct?

Well, first thing you need to know is just how "standard" a standard is.

The W3C, and most standards bodies of this sort, has no means of obligating browser makers to comply to its published standards. The browser makers are independent, private companies and the W3C is not some sort of governmental regulatory agency. In fact, the W3C doesn't publish "Standards", it publishes "Recommendations". So, software developers are under no constraint—other than their own sense of responsiblity to the community and/or their users screaming at them to get back to the "straight and narrow" when they decide to take some proprietary path—to follow these standards at all.

Even then, the standards are not 100% complete or exhaustive. There is some wiggle room built into the standards, and in that space browser makers can test out ideas that may put them out in front of the crowd as the best of the breed. This is the case for our class example of the move-to-top-when-clicked DHTML function ... wiggle room.

What do the standards say about the z-index property?

That the default value is "auto". That elements belong to groups or stacking contexts; for example, the three boxes on our demo page are all child tags of the and so are within the tag's context. That "auto", within a context, means essentially zero. Positive z-indexes appear "above" that zero point, negative values below it (remember: default background color for an element is transparent!).

And that's about all it says.

In particular, it does not say what a browser should do if, in particular, two or more elements in the same context have the same z-index. That decision was one left up to the browser makers.

A common teaching ... one I formerly, including last Saturday, espoused ... is that "the standards say" that the first elements drawn should be on the bottom of the stack, the last ones drawn on top. Order of appearance determines stacking order. The standards say nothing of the kind.

Internet Explorer follows the view above at all times. Go to our example page and take a look. All the boxes start with a z-index set to 1. Box1 is under Box2, Box2, is under Box3, and that reflects the order in which their tags appear in the code. Click on Box2, then Box3, then Box1, then Box2. Box2 has a z-index of 100, the others have a value of 0. And on that last click IE moves Box1 all the way to the bottom of the stack, even though it was above Box3 just a moment ago.

Now, look at that demo page in Mozilla. When it loads, it looks identical to IE's rendering ... it follows the "first on the bottom, last on the top" rendering rule. Click Box2, click Box3, click Box1, click Box2. Look. Compare. The stacking order is not Box2 > Box3 > Box1, as with IE: Mozilla's stacking order is Box2 > Box1 > Box3.

Which is "correct", according to The Standards? They both are. Which is more "standards-compliant"? Neither is more standards-compliant on this topic than the other, because the standards say nothing about it.

Which version do I prefer?

Mozilla. No, not just because it's not IE ... MacIE5.x, my before-Gecko-went-Gold favorite-browser-of-them-all, behaves the same as WinIE5+. It gets back to that idea of the "stacking context". Our JS function, in a sense, creates a new, mini/momentary context of two divs: the old top Box and the just-clicked soon-to-be top Box. The third box is not in the picture. If the clicked box is put on top, the old top box should, logically, be immediately underneath the top. It shouldn't get shuffled around with the third box ... or, if we had more divs in play, the fourth, fifth, sixth, etc. boxes either. The idea of the function is to grab a box from anywhere in the stack and put it on top. There is nothing in our code that says "reorder all the divs while you're at it". So, I'm happier with Mozilla's interpretation of how to make this work than I am with IE's interpretation.

... not to say that IE is [BZZZZZZZZZZT!] WRONG or anything like that....


finelineBob 2/3/2003 04:00:00 PM