я не знаю что думать, потому что у меня полифилл для mutationObserver, который поддерживал в том числе вендорные префиксы, появившиеся в хроме в 14-й версии. Так что подцеплялся нормально.
А в яндекс-браузере он тупо фейлил базовые тесты для mutationObserver. Если бы не видел своими глазами — не поверил. Три из пяти событий не отстреливались. Переключил форсированно на DOM Mutation Events, потому что настолько испохабленный мутейшнобсервер за api считать нельзя. Но и там куча всего ломалась.
Добавился Яндекс.Браузер, который внутре тот же Хромиум, хоть и обновляется реже.
Даааа. Конеечно.
Мне только одно интересно. А нахрена они выпилили mutationObserver из хромиума? Да еще и испоганили DOM mutation events. В итоге полифилл отрабатывал от силы раз из трех.
После перезагрузки страницы все залоггированые сетевые запросы сбрасываются.
Сложность была в отладке исходящих запросов и ответов на них в ситуации, когда колбэк на аяксовый запрос вызывает перезагрузку страницы.
Возможно, если да — замечательно, но почему во встроенном-то этого нет?
Меня всегда удивляла эта политика мозиллы — почему не сделать файербаг частью основного кода FF и выпилить свой отладчик, или сделать встроенный отладчик таким, чтобы люди не качали первым делом файербаг?
В хроме есть «log XMLHttpRequests», но он делает трассировку кода, что после перезагрузки страницы становится совершенно неактуально. В итоге пришлось перейти на IE11 в виртуалке, и это оказалось на удивление очень удобно.
посмотрите мою последнюю статью, там скриншоты профайлера. Я с ним долго заморачивался как раз чтобы убедиться, что утечек памяти нет.
В IE снэпшоты уже есть. И они реально удобнее и детальнее чем в хроме или лисе. Хотя за лису не могу ручаться — я ей не так много пользуюсь, возможно, в firebug и сделали что-то качественное, но во встроенном дебаггере лисы работа не так удобна.
В хроме удобна, но в IE данные предоставляются более структурированно.
инструменты разработчика в ie11 можно и нужно любить уже за то что это единственный набор инструментов, где полностью сохраняются запросы к серверу при переходах между страницами.
Последнюю неделю в нем только и живу — отлаживаю запросы, которые сразу после ответа в случае успешного результата должны перезагружать страницу.
У людей обычно наступает шок, когда на маке человек сознательно сидит в IE11, но за эту неделю я уже привык :)
Я откомментировал это сообщение еще в том посте, странно, что в итоге все свелось к «делайте костыли»,
реализация шлейфа — это очень частый вопрос в аркадах. Вещи вроде bit.trip runner как упоротый инди не трогаем (хотя подобных игр тьма). Но шлейф почти всегда присутствует в гонках(ускорение у машины + следы шин), очень часто в шутерах с видом сверху(трассирующие пули), да даже галлюцинирование часто делается на шлейфах.
Так что вопрос реально насущный, а не локальненький такой.
При этом шлейф должен
-гаснуть (по функции — где-то opacity, где-то width, где-то вообще дикое что-то)
-иметь отличную от объекта текстуру (у шин другая текстура, у трассирующих пуль тоже)
возможно, что-то еще.
Я хотел бы попробовать при поддержке Брэндона сделать универсальный O(n) для ie8- и Object.frozen элементов + O(1) для всех остальных алгоритм в ближайшие несколько месяцев. Он согласился помочь, к сожалению, у меня не так много свободного времени на абсолютно универсальное решение WeakMap — для моего случая достаточно того решения, что сделал Брэндон, и это скорее будет работа из чистого любопытства.
Да, только через час заметили, что в jpg тонкие линии пережимаются — на мониторе, на котором все это рисовалось, артефакты были незаметны. Заменили сначала на большой png, чуть позже увидели размер и пережали в png-8, теперь меньше сотни Кб весит картинка.
Я не заявил, что забросил, я заявил, что разработка завершена. Библиотека будет в дальнейшем оставаться в поддержке, но у нее не будет развития, я не вижу что в нее еще можно добавить, не покидая из концепцию микроархитектуры.
Возможно, на базе ее будет сделано что-либо еще, но сама она не будет расширяться, для нее не будут переименовываться опции, добавляться новые, удаляться устаревшие и так далее.
В любом случае, движок прямо базируется на MutationObserver(хотите — почитайте исходники, там все прозрачно до невозможности), который был утвержден в DOM4 working draft еще в 2012 году, и который полностью реализован — уже без префиксов — во всех браузерах: IE11, FF14+(боже, как давно это было) и chrome18 с префиксом, chrome27 без префикса(сами считайте, какой это webkit/blink). Для альтернативных реализаций вебкита(в сафари, опере, мобильных устройствах) — все тоже очень хорошо, его сейчас нет из последних версий браузеров только в родном браузере андроида.
О всех существующих смешных багах mutationObserver вроде работы с чекбоксами или не отрабатывающих колбэках в случае многократного изменения html прямо в его же колбэках я в курсе, успел наудивляться, пока разрабатывал.
Когда API находится в таком статусе — оно уже не может измениться, это вам не flexbox.
Конечно, я отслеживаю изменения, но это уже вопрос очистки совести.
Дело вкуса, я лично все собираюсь добавить cornerJS в bower — некогда.
Да и в моем случае билды всегда есть в репозитории, собранные через grunt, да и вся сборка — собрать вместе библиотеку и полифилл.
Хотя это все субьективно, потому что разработка cornerJS завершена. Забивать тут не на что, он работает, ничего с ним не произойдет. Все тесты зеленые, тесты учитывают все сценарии. Он уже не будет изменяться, максимум — будут изменяться подключенные полифиллы (я сейчас хочу сменить простой WeakMap на сложный и хорошо работающий с памятью), может, пара дополнительных валидаций для имени директивы, но api и поведение библиотеки не будут изменяться.
Последние две версии он полностью переписывался с сохранением формата для поддержки особенно сложных и необычных сценариев, и сейчас вроде бы они все учтены, вплоть до того что колбэки отрабатывают даже когда ты добавляешь класс к элементу — например замена class=«button directive-one» на class=«button directive-two» вызовет:
1.unload для directive-one
2.load для directive-two
Как человек, который запилил cornerJS — подтверждаю, думаете все правильно.
С другой стороны — lega запилил Angular light, так что его точка зрения тоже верна :)
Там самые сложные вещи в полстроки расписано, и тебе повезло если там не стоит todo вместо текста.
При этом такие прелестные детали WebGL, как то, что свойство repeat текстуры отрабатывает корректно только если длина текстуры степень двойки там опущены напрочь, и это ищешь почти день каждый раз.
кстати, наврал, 5n даже не поддерживаются. был базовый размер(2n), половинный(1n), полуторный(3n), потом попросили добавить тройной(6n).
да, у нас задача была сделать плитки по типу тех что в windows 8, только которые заполняют все сами, чтобы получался нон-стоп фид.
А у вас что-то вроде пинтерест-фида, как я понимаю?
Он еще и элементы располагает с пропусками, что часто бывает неприемлемо. Как, впрочем, и isotope.
В любом случае, он — не для grid layout, а для плиточного расположения элементов, что совсем другое.
Мы внутреннее решение пользуем, у которого есть ограничение — все элементы должны быть ширины-высоты n, 2n,3n,4n,5n,6n, кратность больше шести не поддерживается. Зато заполняет предоставленное пространство почти полностью, и задача не O(n^2) выходит, а проще.
А в яндекс-браузере он тупо фейлил базовые тесты для mutationObserver. Если бы не видел своими глазами — не поверил. Три из пяти событий не отстреливались. Переключил форсированно на DOM Mutation Events, потому что настолько испохабленный мутейшнобсервер за api считать нельзя. Но и там куча всего ломалась.
Даааа. Конеечно.
Мне только одно интересно. А нахрена они выпилили mutationObserver из хромиума? Да еще и испоганили DOM mutation events. В итоге полифилл отрабатывал от силы раз из трех.
Сложность была в отладке исходящих запросов и ответов на них в ситуации, когда колбэк на аяксовый запрос вызывает перезагрузку страницы.
Меня всегда удивляла эта политика мозиллы — почему не сделать файербаг частью основного кода FF и выпилить свой отладчик, или сделать встроенный отладчик таким, чтобы люди не качали первым делом файербаг?
В хроме есть «log XMLHttpRequests», но он делает трассировку кода, что после перезагрузки страницы становится совершенно неактуально. В итоге пришлось перейти на IE11 в виртуалке, и это оказалось на удивление очень удобно.
В IE снэпшоты уже есть. И они реально удобнее и детальнее чем в хроме или лисе. Хотя за лису не могу ручаться — я ей не так много пользуюсь, возможно, в firebug и сделали что-то качественное, но во встроенном дебаггере лисы работа не так удобна.
В хроме удобна, но в IE данные предоставляются более структурированно.
Последнюю неделю в нем только и живу — отлаживаю запросы, которые сразу после ответа в случае успешного результата должны перезагружать страницу.
У людей обычно наступает шок, когда на маке человек сознательно сидит в IE11, но за эту неделю я уже привык :)
Я откомментировал это сообщение еще в том посте, странно, что в итоге все свелось к «делайте костыли»,
реализация шлейфа — это очень частый вопрос в аркадах. Вещи вроде bit.trip runner как упоротый инди не трогаем (хотя подобных игр тьма). Но шлейф почти всегда присутствует в гонках(ускорение у машины + следы шин), очень часто в шутерах с видом сверху(трассирующие пули), да даже галлюцинирование часто делается на шлейфах.
Так что вопрос реально насущный, а не локальненький такой.
При этом шлейф должен
-гаснуть (по функции — где-то opacity, где-то width, где-то вообще дикое что-то)
-иметь отличную от объекта текстуру (у шин другая текстура, у трассирующих пуль тоже)
возможно, что-то еще.
Но статью плюсанул, как и все до этого, да :)
Хотя один черт круто.
Возможно, на базе ее будет сделано что-либо еще, но сама она не будет расширяться, для нее не будут переименовываться опции, добавляться новые, удаляться устаревшие и так далее.
В любом случае, движок прямо базируется на MutationObserver(хотите — почитайте исходники, там все прозрачно до невозможности), который был утвержден в DOM4 working draft еще в 2012 году, и который полностью реализован — уже без префиксов — во всех браузерах: IE11, FF14+(боже, как давно это было) и chrome18 с префиксом, chrome27 без префикса(сами считайте, какой это webkit/blink). Для альтернативных реализаций вебкита(в сафари, опере, мобильных устройствах) — все тоже очень хорошо, его сейчас нет из последних версий браузеров только в родном браузере андроида.
О всех существующих смешных багах mutationObserver вроде работы с чекбоксами или не отрабатывающих колбэках в случае многократного изменения html прямо в его же колбэках я в курсе, успел наудивляться, пока разрабатывал.
Когда API находится в таком статусе — оно уже не может измениться, это вам не flexbox.
Конечно, я отслеживаю изменения, но это уже вопрос очистки совести.
Да и в моем случае билды всегда есть в репозитории, собранные через grunt, да и вся сборка — собрать вместе библиотеку и полифилл.
Хотя это все субьективно, потому что разработка cornerJS завершена. Забивать тут не на что, он работает, ничего с ним не произойдет. Все тесты зеленые, тесты учитывают все сценарии. Он уже не будет изменяться, максимум — будут изменяться подключенные полифиллы (я сейчас хочу сменить простой WeakMap на сложный и хорошо работающий с памятью), может, пара дополнительных валидаций для имени директивы, но api и поведение библиотеки не будут изменяться.
Последние две версии он полностью переписывался с сохранением формата для поддержки особенно сложных и необычных сценариев, и сейчас вроде бы они все учтены, вплоть до того что колбэки отрабатывают даже когда ты добавляешь класс к элементу — например замена class=«button directive-one» на class=«button directive-two» вызовет:
1.unload для directive-one
2.load для directive-two
С другой стороны — lega запилил Angular light, так что его точка зрения тоже верна :)
Там самые сложные вещи в полстроки расписано, и тебе повезло если там не стоит todo вместо текста.
При этом такие прелестные детали WebGL, как то, что свойство repeat текстуры отрабатывает корректно только если длина текстуры степень двойки там опущены напрочь, и это ищешь почти день каждый раз.
да, у нас задача была сделать плитки по типу тех что в windows 8, только которые заполняют все сами, чтобы получался нон-стоп фид.
А у вас что-то вроде пинтерест-фида, как я понимаю?
В любом случае, он — не для grid layout, а для плиточного расположения элементов, что совсем другое.
Мы внутреннее решение пользуем, у которого есть ограничение — все элементы должны быть ширины-высоты n, 2n,3n,4n,5n,6n, кратность больше шести не поддерживается. Зато заполняет предоставленное пространство почти полностью, и задача не O(n^2) выходит, а проще.
Мне дико любопытно, а на что в американских судах уходят такие дикие суммы? Всегда было безумно интересно, не расскажете?(хотя бы примерно)
Как это рабоает — понятно. А вот что это дает — вообще осознаваемо.