Поделитесь своим мнением по данной серии уроков и напишите, что нового или просто полезного вы из нее извлекли? Так я смогу сделать еще больше интересного материала.
Временно приостанавливаю данную серию уроков из-за низкой активности на этом последнем видео. Если вам интересно продолжение, то дайте знать в комментариях, а я пока переключусь на другие интересные темы. Надеюсь на ваше понимание и поддержку =)
Like! Вопрос по уроку, 7:50 зачем нужно было оборачивать img в другой блок чтобы добавить псевдоэлементы? что если самому тегу img их прописать? сделав блочным (или строчно-блочным), и почему именно table? опционально? или так лучше?
Псевдоэлементы находятся внутри элемента, как дочерние узлы. У одиночных тегов их нет. А насчет table, это частая практика для псевдоэлементов. Потому что он веет себя как блочный, но не растягивается на всю ширину, а остается по размеру содержимого. Можно указать и другой тип, все по ситуации =)
появился ещё один вопрос, думаю, многим будет интересно. Заметил 2 противоположных подхода у верстальщиков. Один - максимальное использование семантики (всё-таки html5), минимум классов, на препроцессорах, например максимально используя вложенность, переменные и пр.. Плюс такого подхода - ускорение вёрстки, минус - программисту потом не просто будет обращаться к этим элементам. Второй подход - использование БЭМ и написание классов к КАЖДОМУ тегу (даже к header и т.д.). Что скажешь?
Разделение не совсем такое =) Разный подход скорее может быть в методологии и уровне верстальщика: 1) Семантика - это применение правильных тегов и ее должны использовать все. Кто отрицает важность семантики, просто оправдывает свою лень и не знания. 2) Ни одна методология не мешает использовать препроцессор и переменные, БЭМ в этом плане очень удобен. Для каждого блока создается отдельный файл и проект становится хорошо организован. 3) Тег не является уникальным, поэтому вполне заслуживает отдельный класс для обращения. Большинство методологий CSS стараются избавиться от вложенности селекторов, и уникальный класс каждому элементу полностью решает эту проблему. Вложенность селекторов это всегда не удобно и создает кучу проблем в переиспользовании компонентов. Тебе всегда приходится думать о приоритетах селекторов и городить костыли, когда тебе нужно переопределить какое-нибудь свойство. Очень часто бывают такие проблемы, когда подключаешь к проекту какой-нибудь сторонний компонент, написанные через вложенные селекторы. В попытках его кастомизировать, тебе почти везде придется использовать !important, что является плохой практикой, либо городить еще большую вложенность. Использование классов полностью решает эту проблему. Лично я при верстке использую семантику + БЭМ + Sass. И когда к этому привыкаешь, тебе становится проще анализировать макет, сразу разбивая все на блоки и в ходе работ не возникает никаких проблем с каскадностью и специфичностью селекторов. Как-то так =)
Спасибо за поддержку! Хорошо, я постараюсь. Но сперва мне нужно дописать последнюю серию уроков, где мы будем использовать очень много возможностей Sass =)
Эта традиция для псевдоэлементов пошла еще с древних времен. Основная разница в том, что вертикальные отступы у блочных блоков выпадают и схлопываются, а у табличных нет. Ну и табличные блоки не растягиваются на всю ширину. На практике все это не всегда важно, но привычка осталась =)
@@turembekov Я всю жизнь работаю на PHP, сейчас там Laravel фреймворк номер один, пользуюсь им. С джанго я сталкивался, но большого опыта не было. Мне тут сложно оценить, к сожалению. В итоге все зависит от задачи =)
@@CodeQuestRu Приветствую, очень жаль, что с активностью этого курса так получилось. Когда увидел его, решил не подсматривая, сначала сделать самостоятельно, потом посмотреть )) В итоге уже, оставил, как есть )).Вот - vyuz.github.io/SkiSchool/ Добавил адаптива, как смог, немного анимации.
Есть несколько моментов. - намучился с верхним баннером и его слоями. Делал из фотошопа, а там не видно этих заморочливых градиентов. - конечно, не pixelperfect, уж очень это заморочливо и, честно говоря, не очень понятно, зачем нужно.
Осталось пару небольших вопросов: - пропадает мап поинтер в футере при экране < 990px (пропадает при перемещении карты вниз и вообще не понятно, куда девается) И вообще, при ресайзе экрана, он ползёт относительно карты. Как это сделать правильно, если исходить из того, что поинтер и карта - не одна картинка? Понимаю, что в прикладной вёрстке это совсем не нужно, но так, в качестве ликбеза. - есть ли вариант без js (на чистом css) отслеживать клик на строке бургер-меню при мобильном экране, чтобы закрывать плашку меню при этом событии? а то приходится делать меню боковым и закрывать вручную крестиком. - И, наконец, самый важный вопрос - какие ещё косяки бросаются в глаза? Если есть, конечно, время.
Ну и больше риторический вопрос ) Сколько у профи, как ты, уходит часов (ну или минут))) на вёрстку такого небольшого лендинга (без анимации, форм обр.связи и пр.) на 7-8 секций, но с адаптивом? Я делал, наверное, месяц, где-то по 0,5-часу в день. Т.е часов 20-30 - капец, как долго, но интересно ))
Молодец, что сам постарался, только практика делает нас лучше! Не все идеально, но в целом это выглядит не плохо. Видно, что старался использовать семантику, что мне тоже нравится =) На мобилке первый блок, о школе и отзывы немного кривоваты, фон съезжает и некоторые элементы перекрываются. Мап-поинтер отделять от карты не особо нужно, ведь у нас она все равно статическая, а если вставить динамическую, то там он также закреплен на координатах и не съедет. В качестве эксперимента можно поиграться с разным позиционированием. Всплывающее меню можно попробовать сделать через ссылку с якорем и псевдоклассом target, поищи про это информацию. По времени я не засекал, но в обычном не спешном темпе под музычку такую страницу можно сделать за 1-2 рабочих дня с перерывами и отвлечением, можно даже с адаптивом. Когда появится больше свободного времени, я постараюсь вернуться к этому макету и показать адаптив, несмотря на просмотры. Но пока что очень хочется видеть отклик и рост канала, потому что на каждое видео, подготовку, запись и монтаж у меня может уходить до 3 дней. Но сейчас уже привыкаю и становится попроще =)
Поделитесь своим мнением по данной серии уроков и напишите, что нового или просто полезного вы из нее извлекли?
Так я смогу сделать еще больше интересного материала.
Все просто супер,молодец. Узнал для себя много нового и полезного. Спасибо за годный контент парень.
@@turembekov Спасибо за отзыв! Был рад помочь =)
Временно приостанавливаю данную серию уроков из-за низкой активности на этом последнем видео.
Если вам интересно продолжение, то дайте знать в комментариях, а я пока переключусь на другие интересные темы.
Надеюсь на ваше понимание и поддержку =)
Даёшь адаптив!!!😁
Круто. Жду новых видосов )
На 2021 много планов, постараюсь не подвести, спасибо =)
Спасибо за урок. Ждём адаптив
Ещё интересна тема, вёрстка макета по сетке 12 колоночной
Спасибо!
Есть видео по работе с 12-колоночный сеткой на Bootstrap, посмотрите =)
Like! Вопрос по уроку, 7:50 зачем нужно было оборачивать img в другой блок чтобы добавить псевдоэлементы? что если самому тегу img их прописать? сделав блочным (или строчно-блочным), и почему именно table? опционально? или так лучше?
Псевдоэлементы находятся внутри элемента, как дочерние узлы. У одиночных тегов их нет.
А насчет table, это частая практика для псевдоэлементов. Потому что он веет себя как блочный, но не растягивается на всю ширину, а остается по размеру содержимого. Можно указать и другой тип, все по ситуации =)
появился ещё один вопрос, думаю, многим будет интересно. Заметил 2 противоположных подхода у верстальщиков. Один - максимальное использование семантики (всё-таки html5), минимум классов, на препроцессорах, например максимально используя вложенность, переменные и пр.. Плюс такого подхода - ускорение вёрстки, минус - программисту потом не просто будет обращаться к этим элементам. Второй подход - использование БЭМ и написание классов к КАЖДОМУ тегу (даже к header и т.д.). Что скажешь?
Разделение не совсем такое =)
Разный подход скорее может быть в методологии и уровне верстальщика:
1) Семантика - это применение правильных тегов и ее должны использовать все. Кто отрицает важность семантики, просто оправдывает свою лень и не знания.
2) Ни одна методология не мешает использовать препроцессор и переменные, БЭМ в этом плане очень удобен. Для каждого блока создается отдельный файл и проект становится хорошо организован.
3) Тег не является уникальным, поэтому вполне заслуживает отдельный класс для обращения.
Большинство методологий CSS стараются избавиться от вложенности селекторов, и уникальный класс каждому элементу полностью решает эту проблему. Вложенность селекторов это всегда не удобно и создает кучу проблем в переиспользовании компонентов. Тебе всегда приходится думать о приоритетах селекторов и городить костыли, когда тебе нужно переопределить какое-нибудь свойство.
Очень часто бывают такие проблемы, когда подключаешь к проекту какой-нибудь сторонний компонент, написанные через вложенные селекторы. В попытках его кастомизировать, тебе почти везде придется использовать !important, что является плохой практикой, либо городить еще большую вложенность. Использование классов полностью решает эту проблему.
Лично я при верстке использую семантику + БЭМ + Sass. И когда к этому привыкаешь, тебе становится проще анализировать макет, сразу разбивая все на блоки и в ходе работ не возникает никаких проблем с каскадностью и специфичностью селекторов.
Как-то так =)
@@CodeQuestRu Большое спасибо за развёрнутый ответ, это важно
Хочу продолжение =) Адаптив
Хорошо, но чуть позже, сперва нужно снять несколько уже запланированных видео. Подождем еще желающих =)
Благодарю за видео! Мне интересно применение Pixel perfect в рамках данного макета и адаптив.
По этому макету уже вряд ли буду снимать продолжение, хотя макет сверстан =)
Спасибо огромное за уроки! Не могли бы записать уроки по верстке адаптивного сайта с использованием Sass?
Спасибо за поддержку!
Хорошо, я постараюсь. Но сперва мне нужно дописать последнюю серию уроков, где мы будем использовать очень много возможностей Sass =)
А почему для псевдоэлементов используется display: table? В чем преимущества?
Эта традиция для псевдоэлементов пошла еще с древних времен. Основная разница в том, что вертикальные отступы у блочных блоков выпадают и схлопываются, а у табличных нет. Ну и табличные блоки не растягиваются на всю ширину. На практике все это не всегда важно, но привычка осталась =)
Жду видео по пиксель перфект,с меня подписка и лайк.
Спасибо! Да, нужно будет вернуться к этой серии, доделать Pixel Perfect и адаптив =)
@@CodeQuestRu Что бы вы предпочли на backend? PHP или Django?
@@turembekov Я всю жизнь работаю на PHP, сейчас там Laravel фреймворк номер один, пользуюсь им.
С джанго я сталкивался, но большого опыта не было. Мне тут сложно оценить, к сожалению. В итоге все зависит от задачи =)
Можешь прислать все вырезанные картинки этого макета,хочу попрактиковаться. За ранее спасибо!
@@turembekov Да без проблем, напиши сообщение в группе ВК или в личку =)
А адаптив будет?
По этому макету уже не уверен, хотя он у меня готов. Странно будет возвращаться к этой серии через год, посмотрят пара человек, к сожалению
Responsive?
Не очень понял ваш вопрос, разверните его подробнее, если не сложно =)
@@CodeQuestRu Is the site ready for tablets and mobile phones?
Lessons on adapting the site for mobile devices will be later, now only the desktop version is ready
@@CodeQuestRu I look forward to it. Thanks
странно, коммент удалился...
Приветствую, что был за коммент?
Я стараюсь ничего не удалять и всем отвечать =/
@@CodeQuestRu Приветствую, очень жаль, что с активностью этого курса так получилось.
Когда увидел его, решил не подсматривая, сначала сделать самостоятельно, потом посмотреть )) В итоге уже, оставил, как есть )).Вот - vyuz.github.io/SkiSchool/ Добавил адаптива, как смог, немного анимации.
Есть несколько моментов.
- намучился с верхним баннером и его слоями. Делал из фотошопа, а там не видно этих заморочливых градиентов.
- конечно, не pixelperfect, уж очень это заморочливо и, честно говоря, не очень понятно, зачем нужно.
Осталось пару небольших вопросов:
- пропадает мап поинтер в футере при экране < 990px (пропадает при перемещении карты вниз и вообще не понятно, куда девается) И вообще, при ресайзе экрана, он ползёт относительно карты. Как это сделать правильно, если исходить из того, что поинтер и карта - не одна картинка? Понимаю, что в прикладной вёрстке это совсем не нужно, но так, в качестве ликбеза.
- есть ли вариант без js (на чистом css) отслеживать клик на строке бургер-меню при мобильном экране, чтобы закрывать плашку меню при этом событии? а то приходится делать меню боковым и закрывать вручную крестиком.
- И, наконец, самый важный вопрос - какие ещё косяки бросаются в глаза? Если есть, конечно, время.
Ну и больше риторический вопрос )
Сколько у профи, как ты, уходит часов (ну или минут))) на вёрстку такого небольшого лендинга (без анимации, форм обр.связи и пр.) на 7-8 секций, но с адаптивом? Я делал, наверное, месяц, где-то по 0,5-часу в день. Т.е часов 20-30 - капец, как долго, но интересно ))
вот, восстанвил )
Молодец, что сам постарался, только практика делает нас лучше!
Не все идеально, но в целом это выглядит не плохо. Видно, что старался использовать семантику, что мне тоже нравится =)
На мобилке первый блок, о школе и отзывы немного кривоваты, фон съезжает и некоторые элементы перекрываются. Мап-поинтер отделять от карты не особо нужно, ведь у нас она все равно статическая, а если вставить динамическую, то там он также закреплен на координатах и не съедет. В качестве эксперимента можно поиграться с разным позиционированием. Всплывающее меню можно попробовать сделать через ссылку с якорем и псевдоклассом target, поищи про это информацию.
По времени я не засекал, но в обычном не спешном темпе под музычку такую страницу можно сделать за 1-2 рабочих дня с перерывами и отвлечением, можно даже с адаптивом.
Когда появится больше свободного времени, я постараюсь вернуться к этому макету и показать адаптив, несмотря на просмотры. Но пока что очень хочется видеть отклик и рост канала, потому что на каждое видео, подготовку, запись и монтаж у меня может уходить до 3 дней. Но сейчас уже привыкаю и становится попроще =)
@@CodeQuestRu Спасибо большое! Буду пробовать!