Даниил Колесниченко: ясно. Я уже посмотрел на ютубе как это выглядит. Все замечательно, но лично мне эта скорость редактирования не нужна) Основное время тратится на проектирование и продумывание архитектуры, а скорость набора у меня не поспевает за мыслью так и так, да и к тому же учить все эти шорткаты с нуля меня напрягает - снова распыляться надо((
Даниил Колесниченко: интересно. А как там это авто-дополнение реализовано? Я однажды редактировал в нем какие то файлы и не заметил там ничего из этого. Как оно все активируется?
Serj-One: в normalize нету никаких свойств, которые выставляют размер шрифта к сожалению (или счастью). Размер будет тот, что определен браузером или настройками пользователя или тем, что мы зададим сами в абсолютных значениях (лучше всего подойдет px)
Serj-One: разный размер шрифта в браузерах происходит из за разных браузерных стилей по умолчанию. Пока мы не укажем свой размер в абсолютных единицах (переопределив браузерный) мы не решим проблему.
Михаил Макарычев: это проповеди евангелистов-любителей менять размер шрифта в браузере.
Я лично считаю что есть более правильный способ менять размер шрифта через изменение масштаба. Менять отдельно шрифт можно и запретить, указав фонт-сайз в пикселях
Роман Д.: ну их нафиг. Все это можно реализовать на js и подключать плагин ради одной не критичной фичи по моему не правильно. Всетаки быстродействие важнее всяких украшалок как по мне.
Ясно
В общем ничего так и не придумали универсального
Я читал статью 2014 года где это описывалось, и понадеялся что решение уже найдено спустя пару лет.
А по поводу запрета на зуммирование оно по моему не влияет. Там именно device-width решает проблему, и то в более новых версиях хрома добавили вроде аналогично с майкрософтом touch-action
Денис Букреев: ясно, у тебя jquery я так понял используется. Я его просто незнаю. Но возможно поможет функция обработчика нажатия из jQuery Mobile. Либо подключить ее (проще, но менее правильно), либо вытащить оттуда код который нужен (может оказаться сложно, но это более оптимально)
там кстати есть косячок с меню выезжающим
помимо того что оно плохо адаптируется к разрешениям экрана, там надпись Производство съезжает влево.
Исправь вот этот у себя стиль на то значение что я поставил:
#wrap header.main.float nav.desktop ul li {
display: inline-block;
margin: 0 0 0 60px;
}
Поможет избежать сдвига на десктопах, но вообще лучше эти менюшки сделать через флекс
Дмитрий Беляев: у нас диалог идет как будто о разных вещах)
Я спрашиваю про то, что понимается под словами "загружен документ полностью", а Вы мне рассказываете про базовые правила загрузки внешних ресурсов браузером)
Уже не суть, я протестировал поведение через хром девелопер и посмотрел последовательность загрузки скриптов. Все происходит как Вы говорили, но с маленьким нюансом. Onload вызывается когда все теги в файле полностью прочитаны браузером. Если внизу будет лежать скрипт, который например меняет цвет фона страницы, то далее следует пересчет стилей и генерируется событие domcontentloaded, потом идет построение layout и после этого генерируется событие paint.
Дмитрий Беляев: насчет правил загрузки скриптов это понятно все. Дело в том что рекомендация засовывать скрипт перед закрывающим тегом боди подразумевает что это делается для того, чтобы скрипт был прочитан до того момента как произойдет событие onload. Если это событие возникает только после обработки всего файла, то не имеет значения где лежит скрипт - внутри боди или снаружи в самом конце. Как document.write кстати модифицирует сам html? Я читал давно про этот метод, но мне он показался бесполезным и непонятным и я его благополучно забыл)
Чтобы этот кусок плавно появлялся и исчезал при нажатии какой нибудь кнопки?