Ну, реализацию сначала надо придумать, а для этого надо знать исходные данные и условия, в том числе требования к игре, например какие будут камни и все такое.
Я предполагал что в основе метода будет лежать анализ SVG, осталось только придумать, как это делать.
Делать анализ на сервере? Тогда на странице можно и лучше для SVG использовать img, но придется где-то хранить инфу об анализе.
Делать анализ на клиенте? Тогда существует два варианта: а) создавать img, а потом AJAX-ом запрашивать .svg и анализировать его, б) создавать object и анализировать его. В первом случае минусом является двойная загрузка одного и того же файла, хоть и из кеша (если он включен на клиенте), во втором - object представляет из себя вложенный документ, при большом количестве подобных объектов производительность страницы может упасть.
Ну, я имел ввиду не такой выход, я имел ввиду в каком формате вы хотите координаты: просто массив точек или может быть массив функций, описывающих кривые из которых состоит объект, и соответствующие им диапазоны координат? Это важно.
Это ж не формат, то что у вас в коде, это был бы формат если бы мы искали координаты для вертикальных прямоугольников нулевой ширины. То что у вас написано, это, насколько я понял, левый и верхний отступы объекта rock от начала координат родительского элемента. Вы же хотите полноценные камни, не прямоугольные, правильно? Тогда какие камни вы хотите? Будут ли грани камней только отрезками или еще и кривыми? В первом случае вам придется собирать координаты вершин в массив, во втором придется делать то же самое, только для кривых придется брать точки из аппроксимации функций, описывающих эти кривые. Или как-то впиливать массив функций, описывающих все кривые в объекте, но тогда придется еще учитывать диапазоны, в которых эи функции будут актуальны.
Для того чтобы что-то анимировать, нужны различные начальное и конечное значения анимируемых свойств, т.к. если анимировать какое-нибудь свойство до того значения, которое оно уже имеет, никакой анимации пользователь не увидит. Для этого и нужно проверять, имеет ли элемент класс 'lowPosition'. Собственно, название класса об этом и говорит: если элемент находится в нижнем положении (то есть имеет класс 'lowPosition', а значит имеет свойство 'bottom' равное '4%'), то его надо убрать из нижнего положения (то есть снять класс 'lowPosition' и присвоить 'bottom' значение '10%').
"Не совсем понимаю логику почему здесь мы проверяем наличие класса, а например в случаи с меню $('nav ul').slideToggle(500); мы же не проверяем есть ли класс nav ul . Как понять эти закономерности?"
Зачем проверять класс в первом случае, я уже объяснил. А в случае с методом .slideToggle() наличие класса проверять не надо потому что он сам проверяет все нужные ему свойства: метод .slideToggle() сделает анимацию "въезжания" элемента если элемент невидим, и сделает анимацию "выезжания" элемента, если элемент видим.
"И если например у меня в коде с меню будет та же переменная что и в коде ниже, что будет? Как понять как мне писать программу (код). "
Вкратце: все зависит от того, как объявлены переменные. Читайте книжку, которую я советовал в этом вопросе, она очень крутая, все что нужно найдете.
"Мне главное понять логику что к чему и зачем."
Логика такая: web-страницы являются документами, а документы состоят из элементов. Чтобы добавить web-странице функционал, программист может используя JS обращаться к элементам и производить над ними какие-нибудь операции.
gassmonkey: слова "пространственный" и "речь" по отдельности несут смысл, но вы выбрали не самую удачную их комбинацию: получившегося словосочетания просто не существует в разговорном русском, о статусе устоявшегося выражения и говорить нечего. Я думаю, словосочетание "пространственная речь" по-разному поймут люди из разных кругов: математик подумает о каких-нибудь пространствах, богослов подумает о библии. Недаром на вопрос "Что такое пространственная речь?" отвечает только mail.ru
Таки отвечая на ваш вопрос: а что вы здесь делаете, если даже язык используете неправильно, и предлагаете погуглить фразу, несущую смысл единственно в богословии?)
К тому же, выражение "пространная речь" несет совсем не тот смысл, с которым вы его связываете: пространная речь - это такая речь, которая занимает много времени, охватывает очень много понятий, открывает целый простор для размышлений. И уж подавно странно, что вы считаете, будто пространная речь 1) не несет ответа на вопрос и 2) призвана поведать окружающим о мудрости отвечающего, это все не имеет отношения к реалиям: пространная речь как раз чаще всего включает в себя ответ на вопрос (и даже не на один), просто подобная речь являет собой не какое-нибудь балабольство начинающееся с "короче типа вот", а скорее целый смысловой пласт, который слушающему приходится разбирать, и вычленять оттуда ответ; о мудрости отвечающего тут можно судить только по звездам. В ответе Hyubert не так уж и много слов, с чего бы ему быть пространным?
Очень странно видеть, что человек, который даже в интернетах соблюдает почти все существующие правила письменного русского, имеет такое неправильное понимание (вполне, думается мне, простого) слова "пространный".
Если принимать во внимание ваше мнение о смысле словосочетания "пространственная речь", то ваш же ответ на мое маленькое замечание как раз больше всего соответствует этому смыслу, т.к. скорее всего мое замечание "пространный?)" было воспринято вами как вопрос "может быть вы имели ввиду "пространный" ?", и на этот вопрос вы вообще никак не ответили, послав меня гуглить какую-то чушь. Ах да, еще вы выдумали нелепое описание к несуществующему выражению, чем однозначно продемонстрировали свою мудрость.
И да - мой ответ можете с чистой совестью считать пространным)
БлагоѨръ Тишина̀: разница такая же, как между 32-х битной версией и 64-х битной версией любого софта)
Не знаю в чем может быть проблема, у меня все работает без проблем. И у тех людей, кто лайкнул мой ответ, видимо тоже все работает) Может у вас Винда какая корявая, а?
Иван Соломенников: а чо мне смотреть на jslint, на такие вещи он говорит "ошибка" или "не надо так делать", и все, никакой информации.
По части инкремента Стоян Стефанов, описывая причины по которым стоит избегать ++, пишет "причина заключается в том, что операторы ++ и -- проявляют «излишнюю хитрость»", а в следующем же абзаце показывает примеры высокопроизводительного итерирования массивов как раз с использованием этих унарных операторов. Так что он не очень последовательный товарищ) Ничего не объяснил
И да, говоря "Стоян Стефанов - Шаблоны программирования и проектирования высококачественных приложений" вы имели ввиду книгу "JavaScript. Шаблоны" ?
Наша с вами переписка занимает ~9300 символов без кода и цитат. Добавьте же еще каких-нибудь 100-150, расскажите мне что не так со скобками и почему унарный инкремент это плохо.
"У вас во втором примере по последней ссылке, переменная location объявляется в глобальной области видимости, а она там не нужна до возникновения события." - как и в остальных. Не очень понял, ну и что? Я-то другие вещи тестировал.
"Также по части фигурных скобок, ай-ай-ай, jslint будет очень сильно и долго ругаться." - а что с ними не так? Все как доктор, то бишь Илья Кантор, прописал
"Переменная i++, тоже лучше так не делать, а использовать i += 1" - ну это уже вообще какая-то соционика) Это-то почему не правильно? (upd: и результаты тестов вторят вам, правда разница в производительности маленькая, но все таки. Кааак? Кааак, Карл?)
Иван Соломенников: "Интересное утверждение что методы класса Array будут работать медленнее чем обычные циклы, но спорить не буду так как реализацию их на С++ не смотрел." - ну так они потому и обычные, что больше ничем не заняты, кроме перебора индексов, и потому же они быстрей. Методы класса Array имеют чуть более сложную логику, учитывающую структурные особенности массивов. О том и велась речь с самого начала: создавая в массиве дырки вы обрекаете себя на использование этих самых методов, ибо если вы все же хотите использовать простые циклы, вам придется вводить соответствующие проверки, что значительно уменьшит их преимущество в производительности. К слову, ES5 методы тоже намного (в ~30 раз) быстрее выполн...; таким образом они тоже не очень любят разреженные массивы, независимо от того вызывается колбэк или нет.
Вообще смотря на ваш код, я вижу почему мы с вами не сходимся во мнениях. Вы абсолютно для каждого действия выбираете более лаконичный код, чем более производительный: если нужно вызвать Array.prototype.slice, вы создаете для этого новый массив; для того чтоб выбрать нужные элементы, вы пользуетесь querySelectorAll, вместо того чтоб сначала выбрать контекст, а потом запустить поиск ...
Если переписать ваш пример, прирост производительности будет ~0-20%. А если переделать его, чтобы массив был разреженным, тогда ваш вариант будет работать в ~30% медленнее. В целом, это все конечно мелочи и большого внимания они не заслуживают, особенно при учете что эта ваша функция выполняется onhashchange и onload, и особенно производительной ее можно не делать. Но все же - если мы имеем возможность упростить код, сделав его менее лаконичным, но более производительным, разве это не стоило бы сделать?
В любом случае, я подумал что верстка статичной рамки с хардкодным разрывом ценности не имеет, и решил что легче сделать оверлэп, что к тому же красивее
1. Если простейшие циклы выполняются быстрее методов ES5, то именно первые и являются разумным выбором,
2. Понять не могу, при чем тут это и какое это отношение имеет к делу? Я на это уже отвечал. Я знаю, что колбэк не будет вызываться для этих элементов. В моем тесте так и происходит. Да даже если б вызывался, я бы сильно не расстроился потому что в вашем варианте производительность и так не составляет 10-и процентов той, от которой вы отказываетесь,
3. Раз вы читаете спецификацию, я вас бесконечно уважаю. Вы правы, я сам их не читал, тут ничего не могу сказать. Но jsperf - это реальная информация о производительности. Не вижу ничего постыдного в том, чтобы замерить реальное время выполнения кода, реализовывающего какой-то гипотетический случай, имеющий спорные моменты. Все же гляньте, демонстрация того что производительность ES5 методов в случае с разреженными и полными массивами ничтожна, по сравнению с производительностью простых циклов,
Хорошо, я согласен с тем, что ваш вариант намного проще, и дальнейшие операции с вашим массивом будет намного проще, читабельнее и лаконичней производить именно посредством методов ES5. Но кажется этот вариант абсолютно непроизводительный, разве нет? Просто приведите пример, в котором применение ваших методов было бы оправдано вещами чуть более важными, чем лаконичность кода, особенно в ситуации когда за нее мы пожертвовали производительностью.
Иван Соломенников: Почему это правильно не значит быстро? Если б мы говорили о музыке или о еще каком искусстве, то да. А тут, мне кажется, другое дело. И уж точно не тот правильный вариант, который делает использование простейших циклов до смешного медленным.
Ну так и напишите другой вариант тоже, хотя бы для энциклопедичности.
Я предполагал что в основе метода будет лежать анализ SVG, осталось только придумать, как это делать.
Делать анализ на сервере? Тогда на странице можно и лучше для SVG использовать img, но придется где-то хранить инфу об анализе.
Делать анализ на клиенте? Тогда существует два варианта: а) создавать img, а потом AJAX-ом запрашивать .svg и анализировать его, б) создавать object и анализировать его. В первом случае минусом является двойная загрузка одного и того же файла, хоть и из кеша (если он включен на клиенте), во втором - object представляет из себя вложенный документ, при большом количестве подобных объектов производительность страницы может упасть.