про "CSS сбил вас с толку" - так и не понял, почему position: sticky (в случае, когда хочется вертикально заклеить элемент), зачем-то связано с overflow-x у родителей.
"без лишнего и накрученного" "Большой толковый" определяет как "немногословный", "простой" и "не перегруженный деталями". Извините, я думал, что глубина проработки подразумевает большее количество слов, усложнение и бОльшее количество деталей. Другими словами, лаконичность двух одинаковых материалов разной глубины проработки априори обратно различна. Блин, логика повредила карме! :)
Еще по "Золотому сайту" стало понятно, что конкурсы в российском ай-ти - такие-себе. Ну ребят, ну как вы умудрились, даже не начав судейство, из всего-то пяти обозначенных критериев оценки два - "Глубина проработки темы" и "Лаконичность" - сделать противоречащими друг другу??? :)
по поводу динамической адаптации контента: 1.1. разработка НЕСКОЛЬКИХ нединамических вариантов - более ресурсо-затратно, чем ОДНОГО динамического 1.2. поддержка/развитие нескольких вариантов - более сложный, затратный и, что не менее важно - сильно сложнее контролируемый процесс. добавили какую-нибудь фичу, посмотрели на сматрфоне в portrait и на мониторе, а бедные обладатели планшетов, глядя на нововведения в landscape, думают "опять у них вся верстка поехала" 2. большинство мобильных девайсов имеют две важные характеристики: а) вытянутый (неквадратный) экран, б) две ориентации - portrait и landscape. и в любой момент, удобный пользователю, он может повернуть свое устройство так, как ему удобно. и если думать про usability и user-friendly, то динамическая адаптация с учетом этого более оптимальна
классические медиа-запросы - отличный инструмент, особенно с использованием SASS/LESS. Но CSS-модули, имхо, сильно привлекательнее, хотя бы по следующим причинам:
в современном фронтенде рулит js (ну или ts). И во вью, и в прочих реактах с ангулярами именно script отвечает за формирование/изменение dom-контента. Поэтому разделение, которое существовало до CSS-модулей - стили отдельно, скрипты отдельно - это анахронизм.
классические медиа-запросы сложнее и муторнее поддерживать. Простой пример: есть три лейаута - mobile, tablet и desctop. на веб-странице есть три параграфа <p>. Допустим, что в desktop у первого <p> нужно сделать левый border, в tablet - у второго, в mobile - у третьего. в классике надо border-left прописать три раза в трех media queries. И зачем делать три раза то, что можно сделать один раз?
ну и модульность с локальной областью видимости - отличная штука. и уже не нужны всякие БЭМы с длинными .blockname_elementname__modificatorname
а джунов сейчас разве не адаптивному веб-дизайну учат, а, как в прошлом веке - мобильная версия отдельно, версия для настольных ПК - отдельно? :)
«Реализация переусложнена» — согласен с одним дополнением: это не готовый кейс, а туториал, цель которого — даже не показать, а понять (для себя самого), будет ли эта концепция работать, если таблица будет усложнена как только возможно — с объединением ячеек как в столбцах, так и в рядах, с очень большим количеством ячеек и в шапке, и в заголовках строк, и в блоке, где сравниваются данные.
Плюс в кейсе очень много кода, относящегося к стилям — чтобы и в классическом виде, и в адаптации вид таблицы был близок к идеальному — этим можно было бы пренебречь, навскидку было бы раза в два «меньше букв», но я, наверное, просто перфекционист :)
Про «не будут влезать в экран» — как раз в рамках этой концепции такого просто не может быть (если только в любой из ячеек нет слова (т.е. текста без пробелов), длина которого превышает ширину экрана))). И поэтому тоже кода так много. Гляньте на пример из ссылки в конце статьи, с активированными «Many Columns» и «+Manufacturers» на мобильном устройстве — там намеренно испорченная таблица, с просто чудовищно большой шапкой и большим количеством столбцов — данные по прежнему удобны для сравнения.
Спасибо за комментарий, во многом с вами согласен. " Если же сразу бросать в читателя и про дизайн, и про удобство интерфейса, и про машины, ну и ко всему этому ещё vue, css, js и прочие вспомогательные инструменты" - фронтенд сейчас не только про html и css, современные скиллы - html + js (или typescript) + Sass/Less,и всё это скомпилировано на каком-нибудь фреймворке типа реакта или ангуляра. Добавление к этому условно техническому набору инструментов "удобство интерфейса" (осмысление результата с т.зр юзер-фриндли) - считаю это не то что не лишним, а наоборот, необходимым этапом вообще любой работы фронтендера. а про машинки - ну надо же было какой-нибудь реальный кейс использовать, вот я и выбрал то, что мне нравится.
Про перескакивающую шапку - если таблица большая, особенно если она не влазит полностью на экран мобильного, то без шапки (ключевое - которая рядом с ячейками) теряется связь со столбцами, названиями этих столбцов.
И да, действительно статья получилась чрезмерно большая. Просто я мало где видел описание тех инструментов / методов, которые использовал - те же CSS-модули и КОП, и поэтому решил написать и о них тоже, с целью переориентации с SCSS и ООП. Наверное, этого делать не стоило, было бы сильно короче.
Не забывайте, что чем больше по физ. размерам монитор при том же разрешении, что тем обычно дальше от глаз пользователя он стоит.
вот как раз именно поэтому дюймы и сантиметры рулят. Т.е. при одинаковом соотношении сторон сайт на 15" и на 27" выглядит пропорционально одинаково. И это — нормально. Также нормально, как смотреть видео/кино на весь экран, и также нормально, как играть в игры тоже на весь экран. Причем не важно какое кино и какие игры — экшн или где что-нибудь хочется/нужно поразгдялывать детально.
Я не знаю ни одного человека, который кино или игры на 15" делает full screen, а на 27" использует для этого 60% ширины.
Сейчас у меня основной монитор — ultrawide 29", 2560x1080. И он юзается в двух режимах: 1) во время работы 2 окна, причем либо 50x50, либо 75x25, в зависимости от задач, 2) не во время работы, как правило, 1 окно во всю ширину.
Причина — под пользователей с такими мониторами никто особенно ничего не адаптируют
Насчет никто нечего — это вы очень неправы. Игровая индустрия, Ubisoft, например — уже в 2014-м полностью адаптировал AC Unity под такие мониторы.
Идея использовать при выводе на экран дюймы и сантиметры — довольно сомнительная.
Можно фиксировать блоки при прокрутке, как это делает тот же ВК и много кто ещё
Ну это такой костыль получается. Если человек пошел скроллить страницу вниз — значит ему интересен контент этой страницы, а не навигационные элементы, которые в этих фиксированных блоках. Т.е. их фиксация — «нам просто нужно место занять». Захочет человек куда-то перейти — Home нажал и пусть переходит
вот я даже за рулеткой сходил, чтобы ширину 15" экрана замерить :) Сделайте ширину браузера 34,5 см — и увидите, как сайт будет на 15" ноуте отображаться, там не мелко (ну только межстрочный дурацкий, это я согласен с критиками)
ой, я забыл, что у вас необычное разрешение для 24".
Тогда читайте так:
обычный текст 13px на 15 дюймах с разрешением 1366x768 и 21px на 24 дюймах при разрешении 1920x1080. При любых других разрешениях размер текста в пикселях будет другим, но физический размер останется таким же. Т.е. менять разрешения, DPI — пофиг, элементы (в т.ч. текст) крупнее/меньше не станут.
Я бы посмотрел в сторону использования нескольких колонок, как в журналах и газетах.
Колоночная верстка — интересная идея, она на ultra wide даже кладется. Ну то есть условно, например до 21" — одна колонка, то что выше — две, и 21:9 — три. Но тут возникает другая проблема: в журналах/газетах видно страницу целиком, и в сверстанном блоке, где одна статья, сразу видно всю высоту колонок. А если на веб-странице баннер, например, верхний подразумевается, то он сразу отъедает большую часть видимого экрана. И как под ним контент располагать в колонках, и какой они должны быть высоты — непонятно. Баннер скроллится вверх вертикально, а потом скролл горизонтальный что ли тогда? А как быть с одноколоночным отображением для 15"?
Провокация на конструктивную дискуссию — мне кажется, это не есть плохо. Цель — как раз узнать мнение специалистов, разбирающихся в своем деле. Ну если вам это слово не нравится, прошу прощения, пусть будет мотивация тогда.
Опять же, мне очень нравится и я очень ценю конструктивную, обоснованную критику, считаю, что это очень полезно (еще раз позвольте выразить вам за нее благодарность, кстати).
Про минус в карму — опять же мне кажется, что вежливость и конструктив про… ой, мотивируют людей оценить сказанное/написанное положительно, а самоутверждение за счет других и переход на личности — мотивируют сделать обратное.
И не обижайтесь, пожалуйста, у меня и в мыслях не было вас как-либо обидеть. Если вдруг это получилось не нарочно — прошу меня извинить.
Я посчитал, что если меру знать — то норм. Т.е., например, font-size обычного текста для 24" 21px и для 15" 13px — это не гигантомания (тот же райффайзен на 24" обычный текст аж в 24px зарядил, и всем нравится)
я не знаю, как браузеры это отрабатывают, но на каких-только устройствах я это не проверял — как-то это работает :) к примеру, у меня:
1) portrait and (max-width:10cm) — телефон, портрет
2) landscape and (max-height:10cm) — телефон, альбом
3) portrait and (min-width: 10.01cm) and (max-width: 30cm) — планшет, портрет
4) landscape and (min-height: 10.01cm) and (max-width:30cm) — планшет, альбом
5) max-width:30.01cm — десктоп
попробуйте на своем мониторе изменить ширину/высоту окна браузера по этим значениям — должны поменяться отображения
Да, сайт не зумится вообще, это минус (наверное). Хотя можно поиграться с размером окна браузера.
Про размер кегля — отправной точкой стал опять же 15"-монитор, на нем я высчитал vw так, чтобы размер этого шрифта соответсвовал стандартам бренда (не помню уже, то ли 13px, то ли 15, то ли еще сколько-то). И на всех остальных мониторах и кегль, и вообще все элементы — просто пропорционально увеличиваются/масштабируются. Т.е., к примеру, при равном соотношении сторон 24"-монитор больше 15" в 1,6 раз — вот все будет в эти 1,6 раз просто увеличено.
И пикселями тоже, но не только ими. Т.е., например, @media screen and (min-width: 30cm) and (min-aspect-ratio: 16/9) { ... }
работает. В дюймах и миллиметрах, полагаю, тоже, а вот насчет pt и pc не знаю
про "CSS сбил вас с толку" - так и не понял, почему position: sticky (в случае, когда хочется вертикально заклеить элемент), зачем-то связано с overflow-x у родителей.
"без лишнего и накрученного" "Большой толковый" определяет как "немногословный", "простой" и "не перегруженный деталями". Извините, я думал, что глубина проработки подразумевает большее количество слов, усложнение и бОльшее количество деталей.
Другими словами, лаконичность двух одинаковых материалов разной глубины проработки априори обратно различна. Блин, логика повредила карме! :)
Еще по "Золотому сайту" стало понятно, что конкурсы в российском ай-ти - такие-себе. Ну ребят, ну как вы умудрились, даже не начав судейство, из всего-то пяти обозначенных критериев оценки два - "Глубина проработки темы" и "Лаконичность" - сделать противоречащими друг другу??? :)
по поводу динамической адаптации контента:
1.1. разработка НЕСКОЛЬКИХ нединамических вариантов - более ресурсо-затратно, чем ОДНОГО динамического
1.2. поддержка/развитие нескольких вариантов - более сложный, затратный и, что не менее важно - сильно сложнее контролируемый процесс. добавили какую-нибудь фичу, посмотрели на сматрфоне в portrait и на мониторе, а бедные обладатели планшетов, глядя на нововведения в landscape, думают "опять у них вся верстка поехала"
2. большинство мобильных девайсов имеют две важные характеристики: а) вытянутый (неквадратный) экран, б) две ориентации - portrait и landscape. и в любой момент, удобный пользователю, он может повернуть свое устройство так, как ему удобно. и если думать про usability и user-friendly, то динамическая адаптация с учетом этого более оптимальна
классические медиа-запросы - отличный инструмент, особенно с использованием SASS/LESS. Но CSS-модули, имхо, сильно привлекательнее, хотя бы по следующим причинам:
в современном фронтенде рулит js (ну или ts). И во вью, и в прочих реактах с ангулярами именно script отвечает за формирование/изменение dom-контента. Поэтому разделение, которое существовало до CSS-модулей - стили отдельно, скрипты отдельно - это анахронизм.
классические медиа-запросы сложнее и муторнее поддерживать. Простой пример: есть три лейаута - mobile, tablet и desctop. на веб-странице есть три параграфа <p>. Допустим, что в desktop у первого <p> нужно сделать левый border, в tablet - у второго, в mobile - у третьего. в классике надо border-left прописать три раза в трех media queries. И зачем делать три раза то, что можно сделать один раз?
ну и модульность с локальной областью видимости - отличная штука. и уже не нужны всякие БЭМы с длинными .blockname_elementname__modificatorname
а джунов сейчас разве не адаптивному веб-дизайну учат, а, как в прошлом веке - мобильная версия отдельно, версия для настольных ПК - отдельно? :)
«Реализация переусложнена» — согласен с одним дополнением: это не готовый кейс, а туториал, цель которого — даже не показать, а понять (для себя самого), будет ли эта концепция работать, если таблица будет усложнена как только возможно — с объединением ячеек как в столбцах, так и в рядах, с очень большим количеством ячеек и в шапке, и в заголовках строк, и в блоке, где сравниваются данные.
Плюс в кейсе очень много кода, относящегося к стилям — чтобы и в классическом виде, и в адаптации вид таблицы был близок к идеальному — этим можно было бы пренебречь, навскидку было бы раза в два «меньше букв», но я, наверное, просто перфекционист :)
Про «не будут влезать в экран» — как раз в рамках этой концепции такого просто не может быть (если только в любой из ячеек нет слова (т.е. текста без пробелов), длина которого превышает ширину экрана))). И поэтому тоже кода так много. Гляньте на пример из ссылки в конце статьи, с активированными «Many Columns» и «+Manufacturers» на мобильном устройстве — там намеренно испорченная таблица, с просто чудовищно большой шапкой и большим количеством столбцов — данные по прежнему удобны для сравнения.
Спасибо за комментарий, во многом с вами согласен.
" Если же сразу бросать в читателя и про дизайн, и про удобство интерфейса, и про машины, ну и ко всему этому ещё vue, css, js и прочие вспомогательные инструменты" - фронтенд сейчас не только про html и css, современные скиллы - html + js (или typescript) + Sass/Less,и всё это скомпилировано на каком-нибудь фреймворке типа реакта или ангуляра. Добавление к этому условно техническому набору инструментов "удобство интерфейса" (осмысление результата с т.зр юзер-фриндли) - считаю это не то что не лишним, а наоборот, необходимым этапом вообще любой работы фронтендера. а про машинки - ну надо же было какой-нибудь реальный кейс использовать, вот я и выбрал то, что мне нравится.
Про перескакивающую шапку - если таблица большая, особенно если она не влазит полностью на экран мобильного, то без шапки (ключевое - которая рядом с ячейками) теряется связь со столбцами, названиями этих столбцов.
И да, действительно статья получилась чрезмерно большая. Просто я мало где видел описание тех инструментов / методов, которые использовал - те же CSS-модули и КОП, и поэтому решил написать и о них тоже, с целью переориентации с SCSS и ООП. Наверное, этого делать не стоило, было бы сильно короче.
Я не знаю ни одного человека, который кино или игры на 15" делает full screen, а на 27" использует для этого 60% ширины.
Насчет никто нечего — это вы очень неправы. Игровая индустрия, Ubisoft, например — уже в 2014-м полностью адаптировал AC Unity под такие мониторы.
Очень интересно, почему
Тогда читайте так:
обычный текст 13px на 15 дюймах с разрешением 1366x768 и 21px на 24 дюймах при разрешении 1920x1080. При любых других разрешениях размер текста в пикселях будет другим, но физический размер останется таким же. Т.е. менять разрешения, DPI — пофиг, элементы (в т.ч. текст) крупнее/меньше не станут.
Опять же, мне очень нравится и я очень ценю конструктивную, обоснованную критику, считаю, что это очень полезно (еще раз позвольте выразить вам за нее благодарность, кстати).
Про минус в карму — опять же мне кажется, что вежливость и конструктив про… ой, мотивируют людей оценить сказанное/написанное положительно, а самоутверждение за счет других и переход на личности — мотивируют сделать обратное.
И не обижайтесь, пожалуйста, у меня и в мыслях не было вас как-либо обидеть. Если вдруг это получилось не нарочно — прошу меня извинить.
1) portrait and (max-width:10cm) — телефон, портрет
2) landscape and (max-height:10cm) — телефон, альбом
3) portrait and (min-width: 10.01cm) and (max-width: 30cm) — планшет, портрет
4) landscape and (min-height: 10.01cm) and (max-width:30cm) — планшет, альбом
5) max-width:30.01cm — десктоп
попробуйте на своем мониторе изменить ширину/высоту окна браузера по этим значениям — должны поменяться отображения
Про размер кегля — отправной точкой стал опять же 15"-монитор, на нем я высчитал vw так, чтобы размер этого шрифта соответсвовал стандартам бренда (не помню уже, то ли 13px, то ли 15, то ли еще сколько-то). И на всех остальных мониторах и кегль, и вообще все элементы — просто пропорционально увеличиваются/масштабируются. Т.е., к примеру, при равном соотношении сторон 24"-монитор больше 15" в 1,6 раз — вот все будет в эти 1,6 раз просто увеличено.
@media screen and (min-width: 30cm) and (min-aspect-ratio: 16/9) { ... }работает. В дюймах и миллиметрах, полагаю, тоже, а вот насчет pt и pc не знаю