martuwka, во-первых, у вас не снимается класс preload, т.к. вы устанавливаете обработчик на load уже после того как это событие произошло, ведь jsfiddle по умолчанию весь код выполняет в onload.
Во-вторых, вы для элемента устанавливаете дефолтную анимацию, она и должна будет стартовать как только будет установлена. Думаю тут найдёте решение.
martuwka, а, ну да, и не должно работать. Я просто не дочитал до конца.
И почему же у вас с классом preload не работает? Фишка в том, что не работать оно не может. Вы просто что-то делаете неправильно. Можете сделать пример, а можете сами убедиться в правильности алгоритма: при загрузке у body должен быть класс preload, этот класс должен отключать анимацию у всех элементов; после загрузки этот класс должен сниматься. Если не работает, значит вы какой-то из этих пунктов не выполняется.
Аксель AxeLVaisper, "Какие сегодня все злые и недовольные)" - почему же сегодня, на тостере вроде бы всегда посылают парней, которые хотят код на халяву. Задачка-то вроде не особо интересная.
"совет перейти на gulp" - ух сколько конструктива, сразу захотелось перейти с grunt на gulp.
"помочь с багами я не могу так как занят в куче других проектах)" - а я и не тороплюсь.
Аксель AxeLVaisper, "всё идёт в открытый проект, тобишь плюс в Карму" - вы считаете что карма настолько неразборчива в связях, что растёт независимо от качества проекта? Тогда поисправляйте пожалуйста баги в моём шаблонизаторе, willkommen.
"не думаю что пара строк кода будет много стоить, скажем 100р" - согласен, но также эти пару строк можно легко нагуглить; это ещё дешевле выйдет.
Таратин как раз это и предложил, это проверено и вроде как не работает. Если вы утверждаете, что это рабочий вариант, то расскажите в каких условиях тестировали, лучше даже покажите пример.
Odisseya, "При каких условиях будете использовать гриды?" - в условиях требования поддержки платформ, которые поддерживают гриды. Если все целевые платформы поддерживают %feature_name% (в данном случае css grid layout), то использование преимуществ этой технологии сильно упрощает и ускоряет разработку. Если не все целевые платформы поддерживают, то некто компетентный (заказчик, отдел маркетинга, вы) решает, что выгоднее и быстрее: писать полифилы или вообще отказаться отказаться от %feature_name% в пользу более простой и шире поддерживаемой технологии.
"тут другие критерии и ориентир на глобальную статистику использования браузеров" - мне кажется это ничего не меняет: если отдела маркетинга у вас нет, то сами решаете насколько целесообразно использование той или иной технологии основываясь на глобальной статистике browser usage и вашей локальной маркетинговой статистике. Вам ниже написали, что стоит быть прагматиком; так вот представьте что вы смотрите на статистику использования браузеров, видите что популярные браузеры делят рынок почти на равные части, и таким образом считаете, что при разработке шаблонов целесообразно использовать последние фичи. А потом вдруг выясняете, что конкретно на вашем рынке большую часть прибыли приносит, к примеру, яблочная часть аудитории, причём не последних версий, а даже и старые версии. Если в таких условиях вы будете использовать самые современные технологии, то вы охватите большую часть используемых браузеров, но потеряете значительную часть потенциальной прибыли, т.к. не учли особенности рынка. Это всё как пример.
В каком смысле считаете приемлемым? Это решает не разработчик, а заказчик на основе своих требований к поддержке. Также часто подобными исследованиями занимается отдел маркетинга, который решает целесообразно ли выделять время на поддержку той или иной платформы. Разработчик только получает готовые инструкции - нужна поддержка IE6, 7 и т.д.
Роман Кузнецов, почему не по теме, я из этого наконец понял о чем речь. Только не смог на айфоне воспроизвести - взял ваш пример, попытался покрутить и подумал что клик будет срабатывать при прокрутке, но не сработал ни разу. Так что видимо у вас какой-то специфический случай, думаю вам стоит сделать пример в котором вы воспроизведёте проблему.
Роман Кузнецов, ну, вы же понимаете, что событие click это просто фича которую вам предоставляет браузер? Разработчики браузера могли бы вполне обойтись событиями mousedown и mouseup, а вам бы как пользователю пришлось бы самому реализовывать click как последовательные mousedown и mouseup на одном и том же элементе (такого не произошло вероятно из-за того что click есть в спецификации). С touch-событиями немного другая история: tap в спецификацию не вошёл, зато туда вошли touchstart, touchend, touchcancel и touchmove.
"TAP это событие, только другое, событие касания пальцев" - фишка в том, что других событий нет. Есть только те которые объявлены в спецификации, о них вы можете почитать по ссылке. А вы дали мне ссылку на событие tap из библиотеки jQuery mobile, там она реализована кастомно; с вероятностью в 99% что это (как я описал выше) просто touchstart и touchend на одном элементе. Кстати, tap в вашем бы примере тоже работал если бы вы подключили jQuery mobile.
А вы уверены, что вам нужен tap? Разве с кликом бывают проколы? Просто насколько я знаю все тачи по спецификации обязаны эмулировать click, таким образом вам вполне должно быть достаточно click.
ЗЫ: с предпоследнего айфона клик в вашем примере нормально работает, проверено только что.
