то бишь, вместо нескольких аргументов один? ничего против не имею, но это дело вкуса.
но даже если аргумент всего один, то замыкания каждый раз все равно надо создавать — не удобно.
совсем ничерта?
допустим, у нас очень полезная фукнция f1, которую надо вызвать с некоторыми аргументами, например, при onclick'е на какую-нибудь кнопку. так и пишем: node.onclick = function() { f1(1,2,3); } — через какое-то время эту же функцию с такими же аргументами надо запускать, например, при инициализации страницы. у нас будет дважды повторяться f1(1,2,3);.
далее надо будет заменить 1,2,3 на 1,2,3,4: меняем аргументы в двух местах, что не приятно.
можно же просто записать myCallback = _clb(f1, [1,2,3]);, прописать и на onclick, и на инициализацию myCallback.fire — когда потребуется изменить список аргументов, сделать это можно будет в одном месте.
и чем больше в скрипте колбеков, тем больше толку от использования.
я, куда деваться, за стандарты (они явно лучше нестабильных багов проприоритарного ие)… но почему-то у меня выражение «стандарт-ориентированный разработчик» как-то само собой разворачивается в «человек, которому стандарт-ориентированностью проели мозги фанаты фокса» — может, по-этому выражение у меня «Почему мы не можем прессовать рыжих?» как-то само собой разворачивается в «Почему мы не можем бежать по рельсам навстречу паровозу?»
embed тут в качестве альтернативного контента.
вставляли когда-нибудь флешку руками (object/@data) и писали внутри object'а: «установите флеш-плеер»? тут тоже самое.
var svgDoc = document.implementation.createDocument("http://www.w3.org/2000/svg", "", null);
var svg = svgDoc.createElementNS("http://www.w3.org/2000/svg", "svg");
// и добавляем svg куда хотим (внутрь html-элемента)
Вы говорите про mousemove при схваченной точке (drag'n'drop), а я про «чистый» mousemove.
когда при mousemove точка начинает увеличиваться, надо перерисовывать и точку, и её фигуру (или все фигуры на холсте, т.к. не факт, что высчитывать пересечения фигур быстрее их перерисовки) — при том, что фигура осталась не измененной.
если бы точки находились в своем canvas'е, при mousemove (без изменения фигуры) надо было бы перерисовывать только саму увеличивающуюся точку (и соседей, до которых расстояние меньше суммы радиусов).
если бы точки находились в svg поверх canvas'а с фигурой, то высчитывать вообще ничего не надо.
больше решений хороших и разных! да и точки у Вас по-отзывчевей…
ps пожалуйста, объясните мне глупому, почему эти точки (и у Вас, и у автора) в том же теге canvas, что и получающееся изображение? если их вывести в отдельный элемент, при движении мышкой считать область перерисовки надо будет только для «слоя» с «контролами» — это положительно скажется на cpu. а точки через svg выводить, тогда и события работать начнут, и пересчитывать (при mousemove) вообще ничего не надо.
> и в понедельник с утра у всех сотрудников всё отвалилось
зачем в крайности впадать? у Вас если не BSOD, то все отвалилось, а если интернета нет, так и сразу всем сотрудникам делать нечего.
отваливается, как правило, какой-нибудь стиль, отбивающий менюшку от начала страницы на 10px, или сортировка в селекте, в котором нужный пункт и с помощью клавиатуры найти можно.
локига такая: «вылез автоапдейт у хрома и в понедельник с утра», 1/30 часть сотрдуников столкнулась с отсутствием сортировки в нужном им селекте, при этом 100% сотрудников получили 5% прирост производитьности при работе с браузером. «А клиент тратит свои деньги» чтобы 1/30 часть пользовалась привычной сортировкой.
сталкивался давно и не плотно: оно мрак, конечно, но мрак только потому, что стоит старье и в плане железа, и в плане софта. новый софт, как правило (ключевое слово: «как правило») лучше и быстрее старого в тысяче всяких мелочей, из которых работа с софтом и состоит. чем программа новее (еще раз напишу: «как правило») — тем с ней удобнее работать.
1) с того момента, как появился ff2+opera9 такой код писали только потому, что ие стоял в сторонке и говорил: «зато я знаю, что такое XML Data Island». теперь (я третий раз это говорю, Вы обозначьте, что понимаете) нам говорят-де будет браузер, совместимый с остальными. если этому верить, то «if(ieVersion != '9')» равносильно «if(true)» и/или «if(false)» — как больше нравится
2) так не пора ли петлю развязывать? кста, не уверен, что её до сих пор не развязали. пусть неудаляемым компонентом системы будет ие9, а браузер ие9 будет программой, устанавливаемой, изменяемой и удаляемой по желанию пользователя, тот же spoon.net/browsers/ — живое доказательство реальности такого подхода. если мы говорим о браузерах, то «компонент системы» — аргумент в пользу бедных.
3) сравните скорость работы старых браузеров и новых. если компании выгодно выгодно, чтобы сотрудники сидели и ждали, пока страничка нарисуется, лишь бы кодеру за переделку не платить — эта компания будет сидеть под ие6, покуда 128 битыне процы не появятся, на которые XP просто не встанет, да и тогда будет гонятся за б/у железом. я говорю о желании сотрудников работать быстрее.
4) а) если работать без компов, то и с браузерами проблем не будет — обновление софта должно быть штатной ситуацией, даже если админу лень жопку от стула отодрать б) периодически приходят клиенты и грят: вышел новый хром, и вот эта штука отвалилась — переделываем, ибо получаем за это деньги.
1) суть хорошего браузера в том, что кодеру (как и мудло-кодеру, как и супер-умному архитерктору) в голову не придет писать «if(ieVersion != '9')» — незачем; позвольте мне, пожалуйста, не толковать банальные истины вроде «определения возможностей браузера» и «веб-стандартов»
2) «уведёт компьютер в BSOD» — может следует написать браузер так, чтобы он ни в каком случае, даже в случае с видео-дровами, не уволил компьютер в BSOD? написать обычную инсталлируемую программу, а не компонент системы, а? кстати, BSOD'а я уже ооочень давно не видел
2.5) наврядли в интранете компании будет использоваться WebGL
3) компаниям, кстати, выгодно, чтобы их сотрудники пользовались нормальным, современным софтом, противовесу ввиде желаний админов и кодиров самое место в топке
4) выкинуть все «if(ieVersion != '9')» надо будет ровно один раз и переписывать какие-нибудь детальки в css, если опираться на практику выхода новых версий нормальных браузеров, надо нечасто, а занимает это времени не так много
каждый свой пук ие выдает за «chrome fail», а на практике оказывается совсем не то. тот же png+opacity достаточно вспомнить: png есть (начиная с 7), filter в opacity перебросили (стандарты! стандарты!), а вот вместе они что-то не очень… так и тут будет: рыбки прыгают, бордер-радиус есть, а рыбки с бордер-радиусом будут тихо себе дохнуть на дне экрана.
канвас на тот момент куда хуже поддерживался др. браузерами, скорость работы скрипта была в разы меньше — все это было не столь актуально. по-этому говорили не о канвасе, а о js-выборках с css-синтаксисом и поддержке css2.1 — суть таже самая
:) просто столько шума не было, но всякие превью кода в pdf на тему «как ие8 захватит мир», видео-ролики с супер-скоростью работы толи с гуглокартами, толи с бинг-картами я помню.
1) нас вот уверятют, что ие9 будет таким браузером, под который можно будет, наконец-то, писать не «глюкавый самописный софт», а софт по стандартам, изначально совсместимый с остальными браузерами и даже шарящий больше сегодняшних конкурентов
2) если, например, 9.1 будет тем же 9, но с поддержкой WebGL — с чего бы тут чему-то ломаться при насильственном обновлении?
но даже если аргумент всего один, то замыкания каждый раз все равно надо создавать — не удобно.
допустим, у нас очень полезная фукнция f1, которую надо вызвать с некоторыми аргументами, например, при onclick'е на какую-нибудь кнопку. так и пишем:
node.onclick = function() { f1(1,2,3); }— через какое-то время эту же функцию с такими же аргументами надо запускать, например, при инициализации страницы. у нас будет дважды повторятьсяf1(1,2,3);.далее надо будет заменить
1,2,3на1,2,3,4: меняем аргументы в двух местах, что не приятно.можно же просто записать
myCallback = _clb(f1, [1,2,3]);, прописать и на onclick, и на инициализациюmyCallback.fire— когда потребуется изменить список аргументов, сделать это можно будет в одном месте.и чем больше в скрипте колбеков, тем больше толку от использования.
вставляли когда-нибудь флешку руками (object/@data) и писали внутри object'а: «установите флеш-плеер»? тут тоже самое.
var svgDoc = document.implementation.createDocument("http://www.w3.org/2000/svg", "", null); var svg = svgDoc.createElementNS("http://www.w3.org/2000/svg", "svg"); // и добавляем svg куда хотим (внутрь html-элемента)лиху дал, очищать-то можно только прямоугольники, но не суть.
когда при mousemove точка начинает увеличиваться, надо перерисовывать и точку, и её фигуру (или все фигуры на холсте, т.к. не факт, что высчитывать пересечения фигур быстрее их перерисовки) — при том, что фигура осталась не измененной.
если бы точки находились в своем canvas'е, при mousemove (без изменения фигуры) надо было бы перерисовывать только саму увеличивающуюся точку (и соседей, до которых расстояние меньше суммы радиусов).
если бы точки находились в svg поверх canvas'а с фигурой, то высчитывать вообще ничего не надо.
ps пожалуйста, объясните мне глупому, почему эти точки (и у Вас, и у автора) в том же теге canvas, что и получающееся изображение? если их вывести в отдельный элемент, при движении мышкой считать область перерисовки надо будет только для «слоя» с «контролами» — это положительно скажется на cpu. а точки через svg выводить, тогда и события работать начнут, и пересчитывать (при mousemove) вообще ничего не надо.
зачем в крайности впадать? у Вас если не BSOD, то все отвалилось, а если интернета нет, так и сразу всем сотрудникам делать нечего.
отваливается, как правило, какой-нибудь стиль, отбивающий менюшку от начала страницы на 10px, или сортировка в селекте, в котором нужный пункт и с помощью клавиатуры найти можно.
локига такая: «вылез автоапдейт у хрома и в понедельник с утра», 1/30 часть сотрдуников столкнулась с отсутствием сортировки в нужном им селекте, при этом 100% сотрудников получили 5% прирост производитьности при работе с браузером. «А клиент тратит свои деньги» чтобы 1/30 часть пользовалась привычной сортировкой.
1) с того момента, как появился ff2+opera9 такой код писали только потому, что ие стоял в сторонке и говорил: «зато я знаю, что такое XML Data Island». теперь (я третий раз это говорю, Вы обозначьте, что понимаете) нам говорят-де будет браузер, совместимый с остальными. если этому верить, то «if(ieVersion != '9')» равносильно «if(true)» и/или «if(false)» — как больше нравится
2) так не пора ли петлю развязывать? кста, не уверен, что её до сих пор не развязали. пусть неудаляемым компонентом системы будет ие9, а браузер ие9 будет программой, устанавливаемой, изменяемой и удаляемой по желанию пользователя, тот же spoon.net/browsers/ — живое доказательство реальности такого подхода. если мы говорим о браузерах, то «компонент системы» — аргумент в пользу бедных.
3) сравните скорость работы старых браузеров и новых. если компании выгодно выгодно, чтобы сотрудники сидели и ждали, пока страничка нарисуется, лишь бы кодеру за переделку не платить — эта компания будет сидеть под ие6, покуда 128 битыне процы не появятся, на которые XP просто не встанет, да и тогда будет гонятся за б/у железом. я говорю о желании сотрудников работать быстрее.
4) а) если работать без компов, то и с браузерами проблем не будет — обновление софта должно быть штатной ситуацией, даже если админу лень жопку от стула отодрать б) периодически приходят клиенты и грят: вышел новый хром, и вот эта штука отвалилась — переделываем, ибо получаем за это деньги.
> Это просто баг
на этом и закончим
2) «уведёт компьютер в BSOD» — может следует написать браузер так, чтобы он ни в каком случае, даже в случае с видео-дровами, не уволил компьютер в BSOD? написать обычную инсталлируемую программу, а не компонент системы, а? кстати, BSOD'а я уже ооочень давно не видел
2.5) наврядли в интранете компании будет использоваться WebGL
3) компаниям, кстати, выгодно, чтобы их сотрудники пользовались нормальным, современным софтом, противовесу ввиде желаний админов и кодиров самое место в топке
4) выкинуть все «if(ieVersion != '9')» надо будет ровно один раз и переписывать какие-нибудь детальки в css, если опираться на практику выхода новых версий нормальных браузеров, надо нечасто, а занимает это времени не так много
2) если, например, 9.1 будет тем же 9, но с поддержкой WebGL — с чего бы тут чему-то ломаться при насильственном обновлении?