s0rr0w

Нет, это ты значение переменной берешь. Вызов был бы obj.stat2(); Потому что на момент присвоения в приведенном коде, переменная stat1 существует у объекта. А при создании { stat1: "some" } этой переменной у объекта нет ровно до тех пор, пока не будет присвоен готовый объект переменной. Это долго пояснять. Поищи в инете.

Доктайп где?

Крохоборством занимаетесь? Ну снизится скорость на доли секунды, и что? Вы не за тем гоняетесь. Нужно делать мощный механизм по поддержке вашего кода, чтобы любой смог быстро создавать свои собственные файлы, легко их править при помощи простых и понятных инструментов. А если вы боретесь за скорость исполнения, то кеширование спасет отца русской демократии, например, тот же APC. Скорость работы XML в PHP достаточная для того, чтобы незаморачиваться.

Потому что ее никто не определял. Вызова one не было. Вынесите данные переменные в obj, т.е. вместо var a пишите this.a

Ну ты же метод вызываешь после создания объекта, а не во время создания. Не понял вопроса

Относится. Просто вызов метода идет на тот момент, когда объект уже создан и все свойства присвоены. Последовательное исполнение инструкций потому что.

Нет.

На момент создания stat2 нет еще у объекта свойства stat1. Сначала парсер готовит все переменные, вычисляет их значения, а потом уже присваивает объекту свойства и их значения. Это все равно что приготовить яйца, сковородку, соль, плиту, а потом уже жарить яичницу.

XML, как по мне, самое удачное решение. <elements> <ru:cred_link>Ссылка</ru:cred_link> <en:cred_link>Link</en:cred_link> </elements> А потом по неймспейсам найти нужный элемент не будет представлять сложности.

Потому что зона видимости переменных внутри функции заканчивается на этой функции. Но, решение есть this вернет ссылку на obj. dynamic_prop = this.stat1 + this.stat2; будет работать как надо. stat2 : obj.stat1 + ' will be here' не будет работать, так как свойство объекта ничего не знает про переменную obj, да и this.stat1 тоже не будет еще существовать на момент вызова.

Потому что ты не верстал под Netscape 4.xx

Разочарую тебя, я подсовывал. Очень даже неплохо получалось даже в каструбатом ИЕ6

<div style="width: 200px; height: 200px;"><img src="z10_h10_v13" width="200" height="200" alt=""></div> Увеличивайте у div и img высоту и ширину на 1% до 10%, вот вам и эффект зумирования. Как только достигнет увеличение 10% - запускаете процесс перерендеривания картинок на следующий уровень увеличения.

Не нравится coder, используйте html-coder. Не нравится и это - используйте colbaser

Если дать объявление в ресурсах, посвященных поиску работы, то эффективность поиска соискателей возрастет в разы по сравнению с данным форумом.

Это не фигня, это особенности хранения дробных чисел. Комп хранит их в виде двух целых чисел. http://en.wikipedia.org/wiki/Floating_point

Потому что никто не знает, что они хотят в конце-концов получить.

Народ, напишите в своей жизни хоть одну спеку. Я думаю, что как только вы закончите ее, так сразу и поймете, почему нет стандарта.

Банальное растягивание/сжатие картинок.

Понятное дело. У вас не определена переменная on, а строка не выполняет никаких действий по определению

Я не фанат своего дела, я уже решал эту задачу на флеше. На самом деле не нужно генерировать огромное количество квадратов. Нужно просто заменять фон для уже существующих нод, а двигать виртуальную карту с квадратами относительно реальной сетки.

Мы делали в свое время так. Берется карта в самом гигантском масштабе. Разрезается на квадраты, например, по 200x200px. Получившиеся картинки складываем в папку zoom0. При этом каждой картинке присваиваем индекс h15v45 (15й квадрат по горизонтали, 45й по вертикали). Не забываем сохранить ширину и высоту нашей гигантской картинки. Потом карта уменьшается, например, на 10%, записываем ширину и высоту исходной картинки, и снова разрезаем на квадраты по 200x200px. Ставятся свои индексы картинкам и ложится все в папку zoom1. И так далее. При начальной загрузке выбираем самый большой уровень зума, например zoom10, и центрируем содержимое карты в неком окошке. Берем высоту и ширину результирующей картинки, делим их пополам. Например, при максимальном зуме картинка у нас была 1000 на 1000 пикселей. Половинка - 500 пикселей. Потом берем ширину и высоту viewport'a (окошка для просмотра карты), к примеру, было у нас 500 на 500 пикселей, и делим эти числа пополам (250) Wz10 / 2 = 1000 / 2 = 500; Hz10 / 2 = 1000 / 2 = 500; Wv / 2 = 500 / 2 = 250; Hv / 2 = 500 / 2 = 250; Вычитаем из половинки ширины картинки половинку ширины вьюпорта, и получаем координату X, на которую нужно сместить картинку влево, чтобы она стала по центру области просмотра X = - ( ( Wz10 / 2 ) - (Wv / 2 ) ) = - ( 500 - 250 ) = -250 px; Аналогично делаем с вертикальной координатой. После таких нехитрых манипуляций в окошке 500х500 карта шириной и высотой 1000px будет отцентрирована. Допустим, пользователь сдвинул карту влево на 100 px, а вниз на 200px. Координаты большой карты будут X = -250 -100 = -350 Y = -250 + 200 = -50; Если мы сделаем зум(для начала возьмем просто зум по центру карты), то нам нужно для начала узнать, в какой точке карты находится середина вьюпорта. Прибавляем к |X| и |Y| половину ширины и высоты вьюпорта. Xc = |-350| + 250 = 600; Yc = |-50| + 250 = 300; Получаем процент смещения относительно центра каждой координаты Xk = 600/1000 = 0.6 Yk = 300/1000 = 0.3 После этого берем высоту и ширину карты в zoom9, и умножаем на наши коэффициенты. Пусть это были 1100 и 1100. Xc = Wz9 * Xk = 1100 * 0.6 = 660px Yc = Hz9 * Yk = 1100 * 0.3 = 330px Теперь производим магические вычисления с отниманием половины ширины и высоты вьюпорта и получаем новые координаты большой картинки X = 250 - Xc = 250 - 660 = -410px Y = 250 - Yc = 250 - 330 = -80px Смещаем координаты сюда и получаем нужный результат. Чтобы узнать, какие именно квадраты нужно подгружать, нужно найти координаты верхнего левого угла вьюпорта на карте, разделить их на 200 (ширина картинки), округлить в меньшую сторону, и получить индекс квадрата, который нужно загружать. А потом найти координаты нижнего правого угла, снова разделить на 200, и округлить в большую сторону. Потом загрузить картинки, которые лежат между получившимися индексами. Хех, опыт не пропьешь...

Да ладно, не описано. А это что? http://msdn.microsoft.com/en-us/library/ms...v=vs.85%29.aspx Для других браузеров это не описывается в доках, так как они вроде как со стандартами работают, а если указать свой dtd, то браузер обязан провалидировать этот документ в полном соответствии с новым типом. Так как это дорого в разработке, решили не париться, и считать, что HTML - всего лишь подмножество SGML.

Борьба с ветряными мельницами. А вас не беспокоит тот факт, что картинки не сразу показываются, а подгружаются постепенно? А тот факт, что пока грузится другая страница, видна предыдущая? А то, что пользователь может увеличить шрифт на странице и некоторые картинки потеряют качество? А то, что на маленьких экранах скроллер появляется?

Ничего не вылезает, все показывается как надо.