Проект TheGreatKeksby

Прошел уже довольно много интерактивных курсов и решил попробовать сверстать магазинчик Кекса из этих самых курсов. Но только уже не на флоатах, а на флексах. Ну и без подглядывания в код, чисто по макету. Надо же с чего-то начинать.) Вобщем по шапке возник вопрос. Я ее сверстал вот так: https://codepen.io/Klavinder/pen/pozXZLy
Примерно представляю и другие варианты верстки. Но как было бы лучше? В частности интересует позиционирование кнопки “Заказать”. Зарнее спасибо за ответы!

P.S. Возможно вопрос банальный, но все же я еще новичок)

Вместо “как лучше”, стоит себе задать следующие вопросы:

  1. Визуально нужный результат был получен?
  2. Код будет понятен стороннему человеку? Имена классов логичны? Код читабелен, нормально отформатирован? В разметку или стили легко внести какие-то точечные изменения, не перелопачивая всё и вся?
  3. Валидаторы не ругаются на разметку и стили?

Если пока в работе только desktop-версия, то вроде все ок. Мало, но особо-то и критиковать нечего. Если доверстаешь до конца - напиши, можно будет детальней разобрать.

Спасибо за ответ! Да, я планирую довести дело до конца.) Потом обязательно выложу сюда для критики

Выставляю на ваш суд.) Если будет время, гляньте. Надеюсь, что разберетесь.)

Славно, вечером обязательно посмотрю.

  1. Структура проекта. Less-файлы со стилями лучше держать отдельно, каталог для наглядности можно так и назвать - less.
  2. Обычно на гитхабе хранят исходные файлы проекта, которые можно собрать в работоспособную версию, развернув у себя на устройстве. Например, скомпилированные css-стили можно не коммитить если в этом нет непосредственной необходимости.

Продолжение следует…

  1. Исправил пункт, см. сообщение выше.
  2. LESS как собирается в CSS? Отсутствие package.json намекает на отсутствие сборщика и/или какой-то плагин для редактора. Тут лучше либо не коммитить LESS вообще, либо указать в readme чем собирались стили.
  3. Посмотри, удобная штука, “твой первый хостинг” так сказать: https://pages.github.com/
  4. Используй валидатор разметки для поиска ошибок в именовании тегов, атрибутов, вложенности, правил моделей содержимого: https://validator.w3.org/nu/#textarea (подсказка - ошибок две).
  5. Иногда стоит провалидировать и стили: https://jigsaw.w3.org/css-validator/validator
  6. Некоторые изображения можно еще немного ужать в размере - попробуй поиграться на https://squoosh.app/
  7. Стоит подключить favicon - даже если его в оригинальном курсе нет.
  8. Кнопка с ховером и без - обрати внимание на border: http://joxi.ru/Drl3Q8YCVgXNqA
  9. “Родной” браузерный outline можно убрать (т.к. у нас есть состояние для фокуса) или заменить на что-то близкое по дизайну: http://joxi.ru/l2ZoN5JFzv14oA
  10. Кнопка не до конца застилизированна: http://joxi.ru/RmzMq0PCYekoxr
  11. Для разметки кнопок использован тег input:
<input type="submit" class="btn" value="Отправить">

Лучше заменить на button.
13. В разных браузерах (Хром, Лиса, Ишак) могут быть свои кастомные стили для состояния фокуса и др., внешний вид контролов (например, для select) - желательно такие моменты делать однообразными.

2 лайка

Спасибо за замечания. По некоторым пунктам могу прямо сейчас ответить, другие посмотрю, когда дома буду.
1, 2 - приму к сведению.)
3 - все писалось в Атоме. Я ставил для лесса по-моему два плагина. Дома посмотрю, какие именно. До конца еще не разобрался, какие именно нужны, возможно что-то еще не доставил.
4 - да, я знаю про pages.github. Вроде ж у меня эта страничка и сделана в таком виде: https://klavinder.github.io/TheGreatKeksby/. Или я что-то не так понимаю?
5, 6 - тоже приму к сведению. Насчет ошибок, поищу обязательно.
7 - ужать можно, а стоит ли? До какого уровня картинки вообще нужно ужимать? Чисто на глаз?
8 - ок. Это вообще как-то упустил из виду
9 - тут скорее всего просто из-за невнимательности. Буду дома смотреть.
10 - ок
11 - эх, видимо тоже невнимательность
12, 13 - ок, исправимся

З.Ы. Хочу попробовать адаптивность прикрутить, поэтому вопрос: если нет отдельных макетов для конкретных разрешений экрана устройства, то какие граничные разрешения брать и сколько? Где-то видел, что берут 990px, 770px и 320px.

4 - а, все ок, я что-то не обратил внимание на ссылку в подзаголовке репо.
6 - в стилях все ок, упомянул для полноты картины.
7 - да, сравнение “до-после”. Смысл имеет - трафик пользователя, нагрузка на батарейку во время рендеринга, хорошие показатели в Google Page Speed, который может повлиять на рейтинг ранжирования в Гугле - в общем, не стоит пренебрегать оптимизация. Но без фанатизма.
По адаптиву - посмотри какие медиазапросы указаны в документации Bootstrap, эдакое среднее по больнице.

Добрый вечер!
Тут немного приболел, поэтому пока не все исправил. Осталось картинки чуть ужать и иконку к сайту прикрутить. Остальное вроде как поправил. Единственное - селект без JS до конца не стилизовать, как я понимаю.
Насчет третьего пункта: в Атоме у меня используется плагин less-autocompile

Единственное - селект без JS до конца не стилизовать, как я понимаю

Да, верно, без JS только частично поддается стилизации.

Баги:

1

image

Подсказка

flex-basis

2

image
textarea - стоит убрать возможность изменять размеры.
На кнопке стандартный курсор при ховере, стоит сделать как у всех остальных.

3

image
“Родное” отображение в Internet Explorer - select, textarea, “крестики” для очистки input'ов. Убирается вендорными свойствами, гугл все знает.

Чекбокс стилизирован хорошо, но можно еще немного улучшить код и сделать чекбокс доступным.
Советую не пожалеть времени и посмотреть видео от Вадима Макеева на тему стилизации чекбоксов: https://youtu.be/E6kLaaQFctU

Да, спасибо за видео. Вроде исправил все. Сейчас пытаюсь разобраться с адаптивностью. И пока что-то слабо получается. Вроде и понятно, как все должно быть, но как-то не совсем понимаю, с какой стороны взяться…

Выбираем подход.

mobile-first - лучшая практика, но требует наличия либо адаптированных макетов, либо умение\чувство прекрасного\верного товарища-дизайнера рядом для самостоятельного составления адаптированных макетов у себя в голове. Разметка\стили пишутся сначала под мобильные устройства, с постепенным развитием до desktop.

desktop-first - когда у нас есть только desktop-макет или уже готовая верстка, и мы постепенно уменьшаем\упрощаем стили под мобильные устройства. Наш случай, его мы и выбираем.

Ключевые брейкпоинты.

Сразу определяем набор ключевых, граничных брейкпоинтов для разных устройств. Не будем сходу усложнять себе жизнь и потренируемся на следующих ширинах:
от минимальной - это мобильные стили;
от 768 - это стили для планшетов (таблеток, tablet);
от 1200 - для desktop.

Для mobile-first медиазапросы выглядят следующим образом:

.foo { color: black } // основные стили - для мобилок
@media (min-width: 768px) { .foo { color: tomato } } // для таблеток
@media (min-width: 1200px) { .foo { color: crimson } } // для десктоп

Грубо говоря, мы говорим браузеру “Начиная с 768 включительно у нас будут применяться следующие стили”.

Для desktop-first медиазапросы пишут немного по другому:

.foo { color: crimson } // основные стили - для десктоп
@media (max-width: 1199px) { .foo { color: tomato } } // для таблеток
@media (max-width: 767px) { .foo { color: black } } // для мобилок

Грубо говоря, мы говорим браузеру “До 1199 включительно у нас будут применяться следующие стили”.

Обратите внимание на значение 1199 и слово “включительно”, это важно.

Контейнер-центровщик. Резина или фиксированный адаптив.

Класс container центрует контент внутри секции. Он играет важную роль при построении адаптивных стилей. Важно сразу определится, какое поведение контента нам нужно - он должен заполнять всю ширину экрана, иметь фиксированные размеры для определенных экранов, или комбинировать оба подхода.

Резина - это когда и размеры центровщика, и контента внутри отпущены в вольное плавание и занимают все доступное внутри родительского блока-секции (кроме случаев, когда мы явно указываем ограничения через max-width, например.). Довольно сложный для поддержки подход, особенно там, где у нас много типографики и текста.

Фикисированный адаптив - собственно, исходя из названия, мы задаем центровщику фиксированные размеры (width или max-width) для каждого брейкпоинта. Благодаря этому получаем весьма прогнозируемое поведение контента в границах брейкпоинтов, что упрощает разработку.

Оба варианта можно комбинировать, но остановимся на фиксированном адаптиве. Исходя из выбранных нами ключевых брейкпоинтов, распишем правила для контейнера-центровщика:

// основные правила - десктоп
.container {
  max-width: 1040px; // max-width вместо width - чтобы не получить горизонтальный скроллбар если что-то пойдет не так
  margin: 0 auto;
  padding: 0 10px; // чтобы контент не прилипал к экрану; учитывая дополнительные отступы, увеличиваем и максимальную ширину контейнера чтобы соответствовать макету
}

// правила для таблеток
@media (max-width: 1199px) {
  .container {
    max-width: 720px;
  }
}
// правила для мобилок
@media (max-width: 767px) {
  .container {
    max-width: 320px; // обычно, за минимальную ширину экрана для мобилок берут 320px; т.к. на мобильных устройствах современные браузеры не "отбирают" место под скроллбар, то можно задать размеры "впритык". В инспекторе тоже можно выбрать тип отображения (десктоп\мобайл\тач\не тач), вместе с этим и эмулируется поведение скроллбара/его позиционирование.
  }
}
Глаза боятся, а руки делают.

Открываем инспектор, заходим в режим адаптивной верстки, пишем правила и проверяем как выглядит.