HackOwnB: не знал))
Как вариант, поставить медиа-запрос на max-width: 300px и убрать/изменить все блоки с картинками и уменьшить размер шрифта. Но для тестирования надо часы иметь и смотреть что там их браузер вообще поддерживает.
Тут самого svg нет ваще)
Экспортировали как то неправильно. Чтобы менять fill надо чтобы были какие то фигуры внутри векторные или тег path. У вас же внутри лежит какая то картинка в base64.
PS. Никаким скриптом обрабатывать svg не обязательно. Скопируй сюда код из редактора, я его поправлю тебе в ручную
Теоретически можно засунуть каждое слово в span, поставить ему одинаковый бэкграунд и колор, а потом когда все прочие требуемые ресурсы будут скачаны либо удалить эти спаны, либо если документ не очень большой и лень заморачиваться, отменить им стили бэкграунда и колора.
MaxKorz: тот пример оптимизации, это обычная практика. Тут нет ничего, что требует знания особенностей браузера. Во всех языках будет актуально написание грамотного кода, который работает хорошо, не зависимо от окружения. Во фронтенде, по моему скромному мнению, все эти оптимизации отходят на второй план, ибо читабельность важнее. Сейчас вспомнил фразу от Apple из их учебника по Swift - "всегда отдавайте предпочтение читабельности кода против скорости". Даже с точки зрения бизнеса, они хотят получить максимально дешевый продукт адекватного качества в адекватные сроки. Все алгоритмы с факториальным темпом прироста сложности имеют быстрые аналоги на жадных алгоритмах. Элементарная экономическая целесообразность. Пусть будет нестабильней на 5 процентов, зато дешевле в 10 раз.
Ну и по поводу антинаучного подхода к "de omnibus dubitandun est", у меня есть иное мнение, правда боюсь тогда эта беседа никогда не закончится)
MaxKorz: я таких мест к сожалению или к счастью не встречал)
PS: предлагаю закончить этот бессмысленный спор. Он ни к чему не приведет сейчас. Пока я лично не столкнусь на практике с такими ситуациями, я не изменю своего мнения. А ситуации эти, как я понял, лежат в области игр и анимации - то, что меня не интересует)
Сергей: был такой древний учебник по ассемблеру, где я встретил эту фразу. Суть в общем и так понятна: если программа работает медленно, то надо смотреть на архитектуру, а не заниматься спичечной оптимизацией типа битовых операций для быстрых математических вычислений. Иногда достаточно поменять используемую структуру данных, например заменить массив на lookup table и ускорить алгоритм в разы.
MaxKorz: я сторонник мнения: преждевременная оптимизация - зло)
И вспомнил древнюю поговорку заодно: экономьте не биты, а байты. Если код работает медленно, то скорее всего это ошибка в архитектуре. В целом я не одинок в таком подходе. Во всех значимых книгах по разработке этот подход приветствуетя: Кнут, Макконнелл и прочие.
Roman Kitaev: Есть какие то сервисы в интернете, где эти сложные вычисления происходят, которые можно в пример привести? Я реально не могу себе представить что это может быть)
АртемЪ: никогда таких не видел)
Да и не практично это, по моему, делать сложные вычисления на фронте, а не на сервере. Любой желающий через консоль достанет код и получит алгоритм этих вычислений.
MaxKorz: немного не так меня поняли. Новичков я упомянул из за того, что топикстартер, как мне показалось, хотел оценить длину и сложность пути, по которому ему предстоит продвигаться, а глубокие знания, скорее всего из требований к соискателю взял. Мне так показалось...
Я его понимаю, ибо постоянно вижу вакансии, где в требованиях пишут кучу всяких вещей типа паттерны наизусть, знание React на уровне "бог", коммиты в известные опенсорс проекты, а на деле в этой конторе jQuery и бутстрап используют)
Все это создает видимость, что кругом одни крутые разработчики, которые в день по новому фреймворку изучают и у новичка опускаются руки. Ему кажется что он никогда не поднимется до такого уровня и бросает свое увлечение, ошибочно полагая, что ему просто не дано.
Те знания, что описали Вы, они понадобятся одному из ста программистов, ибо работы такого уровня не так уж и много. Всем остальным достанется кровавый энтерпрайз и разработка лендингов в веб-студиях. А там свои критерии оценки "глубинности" знаний - можешь сделать все что требуется в короткий срок и за небольшие деньги)
PS:
Если заменить термин "глубокие" на "экспертные", то соглашусь, что к ним можно добавить все что вы написали о браузерах и еще плюс спецификация ECMA.
Все разногласие возникло из-за толкования слова "глубокие"))
EpicUsaMan: я понял. Мне кажется что на фокусе стиль должен отличаться от валидных стилей. Ну и еще я ща посмотрел, у тебя там color меняется на focus и invalid, а на картинке текст пассворда синий - как это получается не знаю. Попробуй загрузить код на codepen или аналогичные сервисы и дай ссылку и тогда можно будет смотреть и искать причины. По идее все должно быть нормально в хроме.
Иван: книги издательства Packt - обходить стороной. 90 процентов материала там это бесполезные туториалы от хипстеров.
Лучшие книги по JS - все от авторов: Дуглас Крокфорд, Николас Закас, Кайл Симпсон.
Лучшие сайты: javascript.ru
Самое сложное в изучении это паттерны и архитектура кода, и то лишь потому, что по ним очень мало адекватного материала с разборами и примерами. По реакту и ноде тоже мало книг нормальных. Приготовься искать по кусочкам на всяких блогах неизвестных (не хайповых) чуваков.
MaxKorz: у него было 20-50 одинаковых объектов?
Запустил тест - создание объекта с внутреними свойствами на 12 процентов медленней (iPad mini 2)
А что будет при чтении этих свойств? Доступ к прототипу происходит ведь медленней чем к внутреннему свойству.
Да и тесты слишком абстрактные: создание 300 миллионов объектов. Такого на практике не бывает. Незнаю точно что там было в коде, но может причина была в чем то еще а не в подходе к созданию объектов?
PS: в функциональном подходе вообще прототипы не рекомендуется использовать из за неявной зависимости через this)
Как вариант, поставить медиа-запрос на max-width: 300px и убрать/изменить все блоки с картинками и уменьшить размер шрифта. Но для тестирования надо часы иметь и смотреть что там их браузер вообще поддерживает.