In the ECMAScript grammar, function declarations are only allowed to occur inside ‘SourceElement’. Thus, Chrome, Firefox, IE, Opera and Safari all diverge from the ECMAScript standard with specific regard to section 12.4 (’ExpressionStatement’). Strictly speaking, the function definition in your ‘with’ statement is invalid syntax and should cause a thrown exception.

The spec doesn’t allow functions to be defined in this way for good reason: the function’s scope could not possibly be known at the time the function object is created. This leads to all sorts of inconsistencies in how browsers implement this bug.

As you said, Firefox will do the best it can given the circumstances: define function ‘foo’ in the variable/activation object of the enclosing function (or the global object), and add ‘obj’ to the static scope chain used by ‘foo’. However, unlike proper function definitions, you will not be able to forward-reference ‘foo’. Again, forward references would be problematic because the scope used by ‘foo’ hasn’t been defined yet.

The other browsers you mentioned will simply create the ‘foo’ function as if it were not contained in the ‘with’ statement. This technique allows forward-referencing ‘foo’, but as you’ve noticed this completely ignores the use of ‘with’ when invoking ‘foo’.

Finally, for something really strange you should see what IE does when including a function definition inside of a ‘catch’ block:

function x() {

	var ox = {
		vx: 2
	};

	var oxx = {
		vx: 3
	};

	try {

		throw oxx;

	} catch (ox) {

		function y () {
			ox.vx = -1;
		}
	};

	y();

	alert(ox.vx);
	alert(oxx.vx);
}

x();

Chrome, Firefox, Opera and Safari use the same approach as for ‘with’. However, upon invoking ‘y’, IE will modify both ‘ox.vx’ and ‘oxx.vx’ (changing them each to -1).

I’m not sure what is happening in this case, but it goes to show this is one instance where the standard writers got it right and browser implementations didn’t take the advice.

I had actually come across this function definition/expression identity of Firefox that you pointed out, under a different context. You can add a window.onload handler by simply defining a global function called “onload” on Firefox:

function onload() {
    alert(42);
}

Design for Browser Size, Not Screen Size.

I think your site is great. It prompted some ideas & questions for me:

- Is your browser detection reporting the gross size of the browser window or the net size of the browser content area? (I’m assuming the former since that’s how you describe it, but I wanted to be sure).

- If the former, do you know of a way to detect the browser content area size? That’s the dimension that the web designer should *really* be interested in.

- I see you’re recording the browser stats for the people who visit your site. Getting these metrics is a very good thing as it helps inform designers. Is it possible to get this information from some sort of unintrusive web-bug/google analytics -style object or script? What I’d like to see is the ability to get a wider sampling of browsers from multiple sites. If it’s possible to have a simple drop-in detector, site owners could add it to their site and get size stats on their own visitors. (Obviously, cross-site-scripting concerns would have to be addressed, but Google seems to have found a way).

http://www.ifixurpics.com

Neateye

with(obj) {
    var foo = function() {
        return typeof a;
    }
}
alert(foo())

I suspect you’ll find that they all produce number in that case

neyse bu güne kadar kim yaptı diye hiç meraketmedim kimse kim diyordum fakat cidden bir teşekkürü sana borc bilirim ellerine sağlık hocam.

iyi çalışmalar.

I would like to know if there is a way to control the output’s ColorSpace.

Thanks,
Ariel