Записки молодого верстальщика

Сделал разметку форм.

Нарезал макет и принял решение, как будет всё выглядеть. (вот как это всё пока выглядит)

1. Будет flexible markup с максимальной шириной макета 1800px.
2. Верхнее меню прицеплено к верху страницы, при прокрутке.
3. Поле поиска на форме в верхнем меню скрыто. Оно разворачивается/сворачивается при клике на лейбл с картинкой поиска (на самом деле эта картинка - символ Font Awesome).
4. При нажатии на комбобоксы в форме, дату можно выбрать в календаре. (задача максимум)
5. В лиде блок с соцсетями прижат к левому краю, и с фиксированной шириной. (задача максимум - на ширине устройства, аналогичного смартфону, блок при hover'е разворачивается шире, позволяя юзеру нажать пальцем на каждую соцсеть).
6. В лиде блок для формы с большой картинкой расширяется до 1800 px совокупной ширины макета. Форма посередине меняет свои габариты и относительную ширину в зависимости от ширины устройства (но если ширина > 1800px, остаётся как в макете).
7. В блоках news, our services и our rooms списки комнат выглядят как есть независимо от ширины устройства. Но если ширина становится меньше ширины списка, entries будут показываться по 2 в строчку, или как newsfeed.
8. Блок Explore your best room тянется как обычно, размеры контента относительны.
9. Если ширина устройства меньше, чем синий блок Find your Best Room here, картинка пропадает, отображается только синий блок.
10. Testimonials отображаются по центру страницы в виде newsfeed'а независимо от их количества. (хотя было бы хорошо, если бы можно было их прятать под кат...)
11. Блок видео можно реализовать как обычный блок с изображением паузы и текста как в макете (задача минимум), или прикрепить рандомное видео, создав для него стили как на макете (задача максимум).
12. Футер остаётся с теми же относительными габаритами, что и в оригинальном макете. Но при уменьшении ширины устройства меньше, чем весь этот блок, секции футера располагаются по центру страницы как newsfeed. Порядок Description - Menu - Socials - Copyright.

Всем привет, друзья!

Так уж сложилось, что целых 11 месяцев не отписывался :) Что ж, продолжим.

Пришлось заново вникнуть в тему, что же я там почти год назад писал... :) Обнаружил, что реально много говнокода в моей вёрстке TripFinder. А закоммитив последние изменения (оказывается, у меня всё ещё были эти изменения без push'а!), обнаружил... в общем, лучше откатиться на то время, пока я ещё не начал говнокодить с flextible design и сделать начисто :D

TripFinder, короче, надо доработать.

А пока что, чтобы вспомнить, что же я тут делал :D, сверстаю новый макет - Airbooking. Сегодня, сделал базовую разметку, кроме формы и некоторых полей. Сейчас всё выглядит вот так. Вообще, будет вот так. (а после, вспомнив уже всё что я тогда мог сделать, уже доделать многострадальный TripFinder).

Кто ставит в вёрстке абсолютную высоту блоков вместо задания отступов элементов - тот я :)))

Не делайте так, друзья. Для этого существуют отступы.

[просто почти доверстал TripFinder - и тут обнаружил, что моя вёрстка полна говнокода :) ]

Дело помаленьку двигается. Хочется, конечно, нарастить темп, но отдых тоже нужен :)

Сегодня сделал разметку по BEM и подумал над поведением блоков при масштабировании (про масштабирование я напишу вместе с началом стилизации в следующем посте, а то уже длиннопост вышел).

Я знаю, среди моих читателей есть люди, которые так же, как и я, изучают верстку и в частности BEM. Так вот, специально для вас я сделал и разобрал разметку <header'а с комментариями, как я обозначал блоки и элементы. Для наглядности, так сказать.

На всякий случай ссылочки по BEM (информация вполне может оказаться для кого-то из вас новой!).

• Общие положения методологии
• Основные концепции и понятия
• Соглашения по именованию

А, да. Не претендую, что прав абсолютно во всех утверждениях и что мое решение идеально - вполне может быть, более опытные разработчики найдут ошибки или видят иной путь реализации, лучший, чем мой. Однако, все дальнейшие рассуждения по максимуму (по крайней мере, я старался :) ) аргументированы, и их логика может помочь вам правильно размечать блоки по BEM. Лучше всего одновременно читать и смотреть на разметку с макетом, чтобы было всё наглядно.

1. С header всё понятно - естественно, это блок. Название класса header само собой напрашивается (как самое простое, да и как вообще можно назвать класс хедера?)
2. В хедере две секции. Они могут перемещаться внутри хедера относительно друг друга, вполне самостоятельны с точки зрения контента и не влияют друг на друга с точки зрения позиционирования (мы можем разместить контакты под мэйном и смысл хедера от этого не изменится!) - поэтому их нужно именовать как два вложенных (относительно хедера) блока. Их собственные названия, вообще говоря, contacts & main-menu & socials & search-form. ВОПРОС: могут ли данные блоки встречаться сами по себе за пределами хедера где-то ещё? Ответ на него - да (кстати, в футере есть список контактов и соцсетей тоже!), и ещё - я даже могу вынести данные блоки за пределы хедера, если, например, хочу, чтобы они менялись на других страницах. Посему, их лучше назвать не как класс с привязкой к хедеру (header-contacts, например), а как блок с модификатором, указывающим, что они принадлежат хедеру: contacts_header & main-menu_header. Заметьте, здесь и далее я использую соглашение по именованию CamelCase.
3. Рассмотрим секцию contacts_header. В ней четыре вложенных компонента: заголовок (имеющий чисто функциональную роль, в соответствиями с правилами семантичной разметки), список, в котором размещены реквизиты компании-оунера, список групп компании в соцсетях и форма поиска. Так вот. Заголовок, с одной стороны, должен иметь функциональный класс, который будет его скрывать. В моей верстке для этого я использую класс visually-hidden (просто как удобный класс с запоминающимся названием). С другой стороны, данный заголовок является неотъемлемой частью секции (так как согласно текущему HTML 5.1 и готовящемуся к продакшену HTML 5.2 семантические блочные элементы сеток, такие как article и section, не валидны без заголовков), заголовок зависим от своей секции по контенту (и позиционированию - в самом хедере это не видно, но вообще по макету это так), и несмотря на то, что внутри секции h2 можно перемещать (флексом), это элемент. Поэтому, согласно BEM, нужно ему дать второй класс contacts__title_header (всё верно, сперва имя блока - потом __имя элемента - потом _имя модификатора (мой модификатор указывает на секцию, а не на своё имя, посему тут значение не нужно). Обратите внимание: я собираюсь скрывать данный заголовок с помощью visually-hidden, поэтому, по идее, мне не нужны для него какие-то другие стили кроме стилей visually-hidden (которые его скрывают). Однако, если предположить, что (при внесении неких правок) я данный заголовок всё же отображаю - у меня уже будет класс (block__title_modifier), с помощью стилей которого возможно быстро внести данные правки. Таким образом, у меня получился микс: с одной стороны, заголовок есть элемент своей секции, с другой стороны - это функциональный блок, который мы скрываем. По макету: видимые заголовки также отличаются видом в зависимости от секции - в них также, нужно будет указывать структуру block__title_modifier для стилизации. Причем block__title можно использовать только для задания формата текста и его дефолтного цвета, а с помощью _modifier мы легко переопределим какой-то из этих параметров (точно понадобится менять цвет). Если сделать разметку и стили таким способом, то фактически стили всех заголовков уже будут - нужно будет просто вешать или удалять класс visually-hidden для их скрытия или показа (тогда как при обычном подходе пришлось бы делать новые стили при каждой такой правке).
4. Что касается списка контактов оунера. Список - это блок, поскольку функционально независим, его можно тягать туда-сюда по секции, он встречается в макете ещё раз (в футере). У него есть собственное имя info, но его вид определяется тем, в какой секции он размещен (например, он флекс-контейнер в хидере - а в футере это список). В футере он выглядит по-другому, чем в хедере. Поэтому, необходимо дать ему модификатор, который будет указывать, в какой секции он размещен (например, info_header указывает, что это стиль для блока info в хедере, info_footer - для футера).
5. Разберемся с элементами списка и ссылками в info. Элементы списка не могут быть отдельными элементами от самого списка - это элементы с именованием info__item. Однако, они могут по-разному себя вести (с точки зрения позиционирования) в разных реализациях info для хедера и футера. Посему, необходимо дать им тот же модификатор _header (и _footer), что есть у нас для заголовков.
6. Внутри li находятся ссылки с текстом реквизитов. Это не те ссылки, по которым мы переходим на другие страницы. Задумка такова: я нажимаю на телефон - открывается некое средство (viber, допустим), с которого можно позвонить оунеру (или просто появляется запрос "хотите позвонить?"), жмём на мэйл - открывается почтовый ящик, с которого можно послать на тот адрес мэйл, и т.д. Реализация данных механизмов - прерогатива не верстальщика. Однако, ссылки в себе будут содержать стили, определяющие их вид на странице. Опять же, понятно, нам понадобится определять, где находится ссылка, поэтому опять понадобятся модификаторы _header и _footer. Поскольку список ссылок - семантичная обертка для блока info со ссылками внутри (если бы я "на дивАх" верстал, так бы и было!), ссылки эти нельзя использовать вне info - а значит, они - элементы info__link, вложенные в info__item (так делать можно и нужно, когда нет необходимости в создании служебных блоков).
7. Абсолютно аналогична ситуация и со списком соцсетей socials. Этот список - тоже по тем же причинам блок, его li - элементы с __item, его ссылки - тоже его элементы __link, вложенные в __item. И тоже там понадобятся модификаторы _header (сюда) и _footer (в футер), чтобы внести разницу в стилях для блока (заметьте, что для реализации данного блока в футере - секция Follow Us - различается в макете для хедера и футера гораздо сильнее, чем список контактов).
8. Форма поиска. Да, это именно форма, а не просто поле ввода. Сама форма с точки зрения BEM - блок с именем search-form. В отличие от списков, он уникален для страницы, поэтому его можно рассматривать как вложенный блок для хедера. Поэтому, его можно именовать как header-search-form (header указывает на то, что форма в хедере и только в нём, search придаёт форме смысл - так коллега из, допустим, Уганды легко догадается по коду, что это стиль именно для формы поиска!).
9. Label необходим в данной форме для того, чтобы сохранить структуру формы с точки зрения её доступности (для машин и для "читалок"), поэтому мы должны его скрыть (visually-hidden мне в помощь :) ). Также, label связан с полем поиска - следовательно, влияет на иные компоненты внутри блока и не используется отдельно от них - посему, это точно элемент с именем header-search-form__search-label. Здесь не нужны модификаторы. В итоге - получился микс, поскольку мы использовали лейбл и как функциональный блок (отображающий текст для машин и читалок), и как элемент формы поиска.
10. Инпут в ней актуален только для данной формы, и без него форма не имеет никакого смысла (поскольку некуда будет вводить запрос на поиск). Значит, этот input - элемент c именем header-search-form__search-input. Все стили для него вполне возможно написать прямо в нём, и не будут меняться в зависимости от того, в какой части макета он находится. Значит, модификаторы здесь не нужны.
11. Секция main-menu. Тут в целом всё просто и аналогично. h2 у нас тут выполняет ту же функцию, что и в пункте 3 - у него та же реализация. nav, точно так же, как было описано в пп. 4-7, является блоком, содержащим список ссылок (его вложенный блок!), у которого есть элементы списка и элементы-ссылки. А вот с logo (который, бесспорно, является блоком!) ситуация интереснее.
12. Давайте посмотрим, какова структура блока logo. В нём есть три составных компонента: картинка, главная надпись (TripFInder) и вспомогательная надпись. Причём картинка, учитывая то, что в макете это иконочный символ FontAwesome, (для джумлы! :) ), реализуется в качестве псевдоэлемента (вопрос для какого элемента - но это уже проблема стилизации). Учитывая то, что логотип является единым целым, все вложенные в logo компоненты влияют друг на друга и не используются нигде отдельно. Значит, это всё элементы. Учитывая то, что логотип единообразен (и, кстати, для данного макета вообще уникален на странице), нужно понимать, что модификаторы здесь не нужны - всю стилизацию можно выполнить с помощью стилей самих элементов. Кстати, есть вариант обернуть логотип в ссылку - но учитывая специфику макета, тут не на что переключаться, и логотип, который вообще по нажатию ведет на главную страницу, можно оставить так.

По абсолютно тем же принципам сделана и вся остальная разметка. Мне нравится то, что получилось. В целом, могу сказать, что методология неплоха как минимум потому, что делает именования единообразными, а код - более читабельным. Хотя, недостаток - необходимо время на то, чтобы создать в своей разметке классы по BEM (уменьшается с опытом и у разработчиков есть инструмент автоматизации - я только в первый раз для понимания всё ручками делал). Плюс, классы получились "развесистыми" по количеству символов - конечно, это компенсируется отсутствием сложных селекторов в стилях, но тем не менее. Может, это именно у меня так получилось, или всё зависит от структуры макета :) В общем, первый опыт использования BEM явно был полезен и интересен.

P.S. В BEM существует своя файловая структура и сборщики, которые пока для меня тёмный лес. Сейчас я не стану их трогать и ограничусь только разметкой и стилями по BEM. Я начинал делать раньше ещё один макет - называется Agnecy (не опечатка, видимо его так назвали чтобы отличать от других) - возможно, там как раз и применю BEM полностью, как его рекомендуется применять.

P.P.S https://echo.htmlacademy.ru - указывая его в форме в атрибуте method, можно тестить, какие данные и в каком виде отправляются с вашей формы на сервер. То есть, это самый простейший и бесплатный эмулятор сервера, который покажет, если вы хотите затестить форму, те данные, которые пересылаются с неё, без необходимости работы с самим сервером и его настройки. С его помощью хорошо ловить баги обработки данных в форме, особенно если вы где-то что-то меняли в логике обработки, вычисляете отправляемые значения или пользуетесь скрытыми полями. Вполне удобно :)

Итак, друзья, сегодня я приступил к макету TripFinder.

Почему только сегодня? На меня повесился debuff, известный в русских землях как "грипп", и теперь сижу на больничном (ура! Наконец-то я отдохну от работы! :) ). На самом деле не "ура", предыдущие три дня я вообще только лежал да таблетки пил - не намного лучше, чем работать на нелюбимой работе. А теперь, как полегчало, естественно, "ура"!

Ну да ладно. За сегодня я сделал разметку (она здесь) и нарезал картинки. В итоге получится примерно вот это (почему примерно - потому что вёрстка будет резиновой, и размеры, естественно, будут совпадать только на одной ширине экрана).

Итак, в данном макете я, во-первых, удержу нынешнюю планку своих навыков, достигнутую на ux energy, а во-вторых, дополнительно сделаю:

• Именование классов по BEM (потренирую методологию);
• Полностью резиновая верстка (в предыдущем макете я сделал сперва pixel perfect, а потом уже появился "гибрид"). Цель-максимум - сделать абсолютно все (в разумных пределах!) блоки резиновыми, предусмотрев их поведение при масштабировании.
• (посильно) Сделать скрипты, предусмотренные макетом для интерактивности (да-да, с js пока всё не очень хорошо, естественно, его надо тоже тренировать :) )

Ну, и несколько слов по самому макету.

• Существующая разметка сделана только кое-где с классами. Это нормально, поскольку теперь продумываю, как именовать блоки по BEM - нет смысла сперва именовать своими классами, а потом переписывать. Сам этап именования должен стоять, таким образом, между созданием разметки и началом стилизации (или между нарезкой и стилизацией, если кто режет макет после разметки).
• Этап "проектирования масштабирования" при резиновой верстке (как он "профессионально" называется, кстати? Напишите в комментах, пожалуйста! :) ) надо будет выполнить после BEM. Сейчас, судя по размерам картинок в макете и разметке, частично уже можно спрогнозировать, как блоки будут себя вести, но я думаю (основываясь на том, что такая тактика не сработала в UX ENERGY), что лучше подойти к данной задаче с системным подходом и уделить время и силы.
• Нарезая картинки, обнаружил, что многие из них разного размера. Это заставило меня вспомнить одно из требований к переполнению контентом. Несмотря на то, что я собираюсь верстать с вариантом картинок, уже мной пофикшенным (хотя я как верстальщик вроде не обязан исправлять ошибки дизайнера, не правда ли? :) ), можно заодно и потренировать устойчивость к переполнению.
• Помните, я в UX ENERGY реализовывал градиенты и картинки в одном фоне? Так вот тут во многих картинках есть похожая задача: картинка полупрозрачна на черном фоне, а кое-где (в разделе Trips) она и при ховере меняет свою прозрачность.
• Нашёл в макете прикол: в разделе Find a tour by tour type есть непрозрачные картинки в обычной цветовой гамме - и есть такие же, но на чёрном фоне с 60% прозрачностью (№1 и №3)! Мне кажется, это было сделано как костыль для дизайнера (потому что белый текст на светлых картинках очень плохо смотрится, вот и пришлось затемнять).
• Ещё одна недавно решавшаяся задача - наложение фона и картинки (блок Deals and Discounts), но так как это фон и картинка, это тоже любопытно сделать.
• Позиционирование хедера и формы в промо-блоке. Видите, хедер полупрозрачен и налазит на фон промо? Форма тоже размещена интересно. Напрашивающееся решение для их позиционирование - абсолют, но я попытаюсь этого избежать и сделать нормально.
• "развертка" содержимого в trips при наведении, показ кнопки know more - мне кажется, можно изящно тут transition применить.

В целом, макет не так уж и прост, как кажется (и показалось мне) на первый взгляд. Тут есть новые задачи, решения которых пойдут в копилку знаний между ушей :)

Итак, друзья, я освободился (относительно, ещё не защитил, но основная масса работ завершена). Теперь опять вёрстка! Я доволен тем, что в итоге получилось :)

За это время, чтобы отдохнуть от диссертации, периодически смотрел learn.javascript.ru. Я пока вижу, тут мне ещё повторять и повторять. В общем, используя те знания, по мере их получения доделаю слайдеры в UX Energy (о которых я писал аж месяц назад :) ). Что касается остальных макетов - нужен Trip Finder: сделаю его (пока в существующем его "гибридном" варианте). После этих двух в плане поискать абсолютно резиновые макеты, чтобы тренироваться на них.

К сожалению, в связи с практикой в магистратуре и ОГРОМНОЙ задницей работой, которую мне необходимо по ней сделать, работы по данной цели придётся отложить. Возможно, в свободное время я смогу и нормальным делам (этой цели!) уделить внимание, но неадекватные 18 дней до итоговой (sic!) аттестации (сделать 40% записки за 18 дней, как вам?) придётся работать очень напряжённо.

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

Причина - в том, что знаний, как сделать резиновую вёрстку, изначально было мало, и, в отличие от HTML/CSS, они ничем не были закреплены. Пожалел, что не пошёл на продвинутый интенсив (не с тем, чтобы сдать или серт получить, а с тем, чтобы увидеть, как это всё делать, и применить у себя).

К сожалению, аж целая неделя ушла на то, чтобы вникать в резину, но не делать реальный результат.

Тем не менее, пользуясь курсами и вопросами к гуглу, таки сделал UX Energy. Осталось сделать интерактивность.

• Слайдеры в секциях мобайл апп и промо (js). Самая обычная прокрутка, в мобайл - прокрутка фонового изображения.
• Слайдер в отзывах (js). Я планирую это сделать так: при нажатии на крайний отзыв он переплывает влево/вправо (в зависимости от того, левый крайний он или правый крайний), а его прежнее место занимает отзыв, который был крайним с противоположной стороны. То есть, это будет нечто вроде бесконечной прокрутки списка отзывов.
• Видео. Пока не работает, надо доделать.

Список курсов и статей, которые я использовал для резинового макета:

1. Пример резинового списка с картинками
2. Responsive nav menu using only CSS
3. Просто справочная информация по video
4. Высота блока относительно его ширины (как по мне, способ не очень, ибо лишние псевдоэлементы, но может кому пригодится)
5. Кнопка play/pause для видео (именно то, что пока у меня не получилось)
6. Основной курс респонзива, который я смотрел на udemy
7. Резиновая вёрстка 1 (несмотря на то, что на флоатах она, новичку вроде меня может быть полезно)
8. Резиновая вёрстка 2, или Что делать с колонками в сетке
9. Курс адаптива, как я понял, краткая "выжимка" по частям - части раз, два, три

Отчасти - получилось хорошо, мне нравится. Отчасти - от недостатка опыта - получилось не очень. Например, взять главную навигацию и меню в футере: у меня никак не получалось сделать их в процентах - благодаря ul, которые никак не хотят растягиваться во флексе на всё свободное место, несмотря на flex-grow. Некоторые секции и места - например, в фичах и отзывах - оставил как есть, во-первых от отсутствия представления, что должно с ними происходить при изменении масштаба, а во-вторых, "от греха подальше" (тем более что эти секции и так неплохо смотрятся). В итоге - получился некий "гибрид" вёрстки. Мне кажется, много на это повлиял изначальный фиксированный вариант, так как задача была "переделать" фиксированный вариант под резину. Несмотря на отчаянный гуглёж, я пока что не смог сделать лучше, если это возможно - ВОЗМОЖНО ЛИ?

Кстати, во время гугления о процентах, em'aх и медиазапросах пришёл к выводу, что уж лучше сразу переходить к респонзиву и адаптиву, но не ограничиваться полумерами в виде гибридной (как у меня) верстки просто с "растягиванием" блоков.

В связи с этим есть вопрос и просьба.

ВОПРОС: ЕСЛИ ВАМ ПОПАДАЕТСЯ МАКЕТ, СДЕЛАННЫЙ ПОД ФИКСИРОВАННУЮ ШИРИНУ, А ВАС ПРОСЯТ СДЕЛАТЬ ПО НЕМУ РЕЗИНОВУЮ ВЕРСТКУ ИЛИ АДАПТИВ - КАКОВЫ ВАШИ ДЕЙСТВИЯ? КАК ИМЕННО ИСПРАВЛЯЕТЕ? КАК ПЛАНИРУЕТЕ ШИРИНЫ, ВЫСОТЫ, ПОВЕДЕНИЕ БЛОКОВ И ЭЛЕМЕНТОВ? ИЛИ НЕ СВЯЗЫВАЕТЕСЬ ВООБЩЕ (ОЖИДАЯ ВАРИАНТОВ МАКЕТА ДЛЯ ВСЕХ УСТРОЙСТВ И ШИРИН ИЛИ ДЕЛАЕТЕ ДЛЯ ОДНОГО ТИПА УСТРОЙСТВА, ЕСЛИ ЕСТЬ МАКЕТ ТОЛЬКО ДЛЯ НЕГО)?

ПРОСЬБА: ЕСЛИ КТО СЛЕДИТ И РЕВЬЮИТ МОИ ПРОЕКТЫ - МОЖЕТЕ ПОГЛЯДЕТЬ, УКАЗАТЬ НА ОШИБКИ, ПОДЕЛИТЬСЯ BEST PRACTICES ПО ПРИМЕНЕННЫМ МНОЙ РЕШЕНИЯМ?

Кстати. Это был первый макет, свёрстанный мной резиново. Век живи - век учись! :)

Нашёл сегодня интересную презентацию о Progressive Enhancement. Познавательно :)

Что касается кроссбраузерности - добил вчерашие баги. (хотя, очень может быть, парочка осталась :) )

Теперь верстка (частично) устойчива ещё и к переполнению контентом, что гуд. Осталось только доделать устойчивость (сегодня вечером, сегодня сильно много работы было), сделать тянущуюся вёрстку (фиксированный вариант уже готов) и интерактивность (планирую "оживить" макет путём интерактивных слайдеров, анимаций (где это возможно), всплывающего окна логина ( :) ) и реальных ссылок на материалы UX Energy вместо заглушек).

Результат

Я вот ещё о чём подумал. Если размещать вёрстку в портфолио, можно там поместить не только сам результат, но и размышления, решения задач в нём. Допустим, некие "комментарии разработчика" вроде "сложное фоновое изображение в блоке promo обычно делается с помощью вспомогательных элементов и псевдоэлементов, поскольку в случае множественного фона градиент может перекрывать картинки, а сами картинки - неправильно позиционируются в тянущейся вёрстке. Но я нашёл решение, где достаточно регулировать порядок слоёв в background-image, и в нём можно обойтись одним элементом". ВОПРОС: НАСКОЛЬКО ТАКАЯ ПРАКТИКА ЧАСТА И, ГЛАВНОЕ, ЭФФЕКТИВНА, ЧТОБЫ ПРЕДСТАВИТЬ СВОИ ЗНАНИЯ?

Я много чужих резюме смотрел, там работы и about-информация в основном - и мне кажется, могут возникнуть сомнения в том, что эти работы реально сделаны владельцем портфолио. Любой дурак может копипастнуть код, поместить его у себя на гитхабе (даже не форк, а чистый копипаст! :) ) и просмотреть его, чтобы его понимать, а на собеседовании скажет, что это всё он сам сделал (и фиг проверишь, ибо человек в чужом коде разобрался и всё может объяснить и даже воспроизвести, если хорошо разобрался). Для такой работы достаточно "уметь в теги" и уметь читать чужой код, но совсем не обязательно реально делать свои работы и, как итог, иметь реальный опыт. А если подлинность работ "подтверждается" отзывом - отзыв можно тупо купить или попросить друга зарегиться как "заказчик" и написать (ну, так бы я делал, если бы хотел кого-то обмануть :) ). Таким образом, если портфолио содержит чисто работы (или вообще их скрины, без "живой" работы) - смысл в нём только как в "анкете" для hr-a, который, сами понимаете, часто ни бум-бум в реальной работе, и такое портфолио нельзя считать реальным отражением моего навыка как верстальщика. Значит, надо как-то по-другому действовать.

Реализовать комментарии можно, я вижу, четырьмя способами:

1. Сделать некий "debug mode" вроде чекбокса на странице с работой, чтобы по его переключению показывались попапами комментарии. Если чекбокс не отмечен, данные попапы не отображаются. (тот же недостаток, что и в пункте 2, плюс вопрос удобства размещения чекбокса: как всплывающее окно, как модальное окно, как менюшка сверху? + дополнительная работа над макетами).
2. Сделать то же самое, но без чекбокса (то есть, при наведении или тесте работы для блоков просто показывается комментарий, как я сделал данный блок и почему именно так сделал, если техника исполнения была для меня новой или интересной) (не айс, когда в макете в принципе есть попапы. Два попапа для одного блока? :) )
3. Сделать "лист эволюции" в резюме как отдельную страницу - список реализованных "мини-задач" со ссылками на их решения в работах. Допустим, я сделал блок интересным способом - и делаю дополнительную запись в листе эволюции с якорной ссылкой на данный блок! (хотя лист эволюции тоже немного лень смотреть, особенно если он длинный :) )
4. Давать ссылки на личный блог "пути верстальщика", вроде данной цели. Всё равно я тут веду дневник, как, когда и что сделал! :) (хотя недостаток - много листать и, в частности смарта, листать с конца. И проблематично найти раздел, в котором я занимаюсь именно макетом А, а не всеми остальными, если, как на смарте, не предусмотрен поиск и/или сортировка постов. А если постов на странице много и браузер от этого "подвисает" (пробовали когда-нибудь долистать до 800-х позиций в "списке достигаторов"? :) ), то вообще :) ).

Какой из способов, на ваш взгляд, самый выгодный? Есть ли у вас иные хорошие способы демонстрировать ваши рабочие качества в резюме? :)