Михаил Проскурин, не всегда так. Есть другой тип дизайна, — полноэкранный, без ограничения ширины зоны контента. Всё зависит от дизайна. Ну или же, к примеру, есть полноэкранный дизайн, но с ограничением максимальной ширины для сверхшироких экранов:
width: 100;
max-width: 2560px;
Всё зависит от дизайна. Вот возьмите, к примеру, divan.ru. Там местами область контента ограничена по ширине (текстовые блоки), но в целом, область контента занимает всю ширину окна (хоть 2560 пикселей).
Hary, обязательно учитывайте хотя бы скроллбар, поэтому не надо 1366-ти. Но всё зависит от дизайна. Если у вас контейнер с контентом, к примеру, 1200 пикселей, то это уже не важно, 1349 или 1366.
Кроме того, не согласен со словами первого комментатора. Ширина контейнера с контентом может быть во всю ширину макета. Всё зависит от дизайна.
Вот возьмите, к примеру, divan.ru. Там местами область контента ограничена по ширине (текстовые блоки), но в целом, область контента занимает всю ширину окна (хоть 2560 пикселей).
Стоит отметить, что orientation в CSS не зависит от реального положения устройства в пространстве, а является лишь соотношением высоты к ширине. Ещё проблема в том, что в альбомной ориентации высотой viewport'a является то значение, что было шириной в портретной ориентации. Этот может стать проблемой. Так, на IPhone X в альбомной ориентации срабатывают стили от портретной ориентации iPad 9.7" (768–1023px).
Коля Шоря, верить надо серверу, а точнее, его настройкам.
У вас сайт теперь весит 12 Мб. 124 запроса. Это пипец как много для подобного ресурса. Я не знаю, какие ещё у вас скрипты, как долго парсятся все эти фотографии на машине клиента, какой у вас сервер и т. д. У вас системные проблемы, которые нужно решать. Для начала советую продолжить поиск огромных фотографий и их уменьшение. Кроме того, нужно провести замену там, где нужно, PNG на JPG. Не все ресурсы нужно делать в PNG.
Ankhena, Сергей Горячев, да, точно, обязательно нужно выбрать Европу из списка, если сервер расположен в России. Тогда картина будет более реалистичной. Однако, стоит учитывать, что сервис грузит сайты по каналу с очень хорошей пропускной способностью, поэтому в реальности скорость загрузки на устройствах пользователей будет ниже.
Сергей Горячев, плохой сервер, плохая оптимизация в целом, много запросов, тяжелые скрипты, тяжелые для декодироания файлы в base64, неоптимизированный и тяжелый для рендеринга CSS, какие-нибудь неведомые JS-preloader'ы, лютые большие SVG, ещё что-нибудь -- причин миллион.
https://jsfiddle.net/w1pzu5rh/1/.
Зоны выделил разными цветами. Верстка на коленке, но алгоритм будет понятен. Под реальности проекта нужно, конечно, подстроить (ту же минимальную высоту поставить блоку, реальные размеры, верстку и т. п.).
relows, это никакой не кринж, это абсолютно стандартное действие для подобных ситуаций, если вы хотите автоматическое выравнивание контента по границам, исходя из общей высоты.
alex-1917, наверное, у нас разные понимание «работающих» сайтов. Интернет-магазины (2 российских, 6 немецких), пара десятков лендингов (для США и Германии) — чем не рабочие сайты? И да, опять же, проверяю на реальных устройствах, ни разу не было проблем с производительностью. Даже у IE11 нет особых проблем (разве что с viewBox и трансформациями посредством CSS).
Возможно, вам просто лень делать векторные графические материалы :))
DeniSidorenko, да не за что, но это целая система, её нужно изучать. Мои знакомые, которые могут делать сайты подобного уровня на GSAP, получают по 10+ тысяч долларов в месяц :))
alex-1917, зачем такие иконки, размер которых строго 16 пикселей, а иначе они пойдут пиксельной кашей? А если у вас есть потребность сделать их хотя бы по 50 пикселей? Будете делать ещё один файл разрешением выше? А если нужно их анимировать? Поменять цвет иконки в соответствии с цветом текста?
Не совсем понял про подтверждение ваших слов, потому что все три пункта, которые я привёл выше, выступают против ваших аргументов. Когда, к примеру, с командой делали интерактивный лендинг-презентацию для Procter& Gamble, я не представляю, что бы было, если бы мы делали все графические элементы в растровых форматах. Никакой анимации, размытость элементов на экранах с высокой плотностью вкупе с нулевой экономией килобайт и т. п.
Ну или вот тут, на Toster.ru, когда открывается лайтбокс с картинкой, в правом верхнем углу висит пиксельная мыльная иконка крестика — не знаю, как вам, но мне это не очень нравится. Тем более в конце 2018-го года.
1. В 98% случаев меньший размер типичных иконок без размытия (ну тут понятное дело, векторный же формат), чем те же PNG-файлы хотя бы 256 на 256 px и в indexed-цветах.
2. Спокойная inline-встройка кодом, что позволяет, к примеру, менять толщину начертания и цвет + убирает лишний запрос на каждую иконку и убирает возню со спрайтами (ну или же пользоваться use). Вы скажете, что можно в base64 сделать иконки, чтобы не было запроса, но декодирование base64 на стороне клиента — не такое быстрое занятие на слабых устройствах, как хотелось бы.
3. Можно анимировать.
P. S. Не знаю, как вы, я все проекты делаю в SVG (маски, декоративные элементы, иконки, шрифтовые иконки и т. п.). Разве что сложные иллюстрации перевожу в растровые форматы, если они изначально векторные и не оптимизированные. Проблем с SVG не имел, все проекты проверяю (если говорить о iOS) на реальных iPhone 5S, iPhone 7, iPhone X, iPad Air 2 и iPad Pro 12.9". Указанных выше проблем с производительностью не замечал.
