Pull to refresh

Comments 110

А почему сразу не писать на less/sass?
В данной статье была цель описать процесс верстки страницы максимально нативными средствами. В следующей части я опишу как сделать то же самое, но с помощью Twitter Bootstrap, который как раз использует LESS.
А потом можно сделать nightmare-вариант с bem-tools, grunt, автогенерацией спрайтов и т.д. и т.п.
Спасибо за очень подробное описание!
Ваш код получается очень специфичный. Такой код совершенно спокойно подходит для написания страниц, которые не нужно будет затем менять, но не для проектов, которые постоянно развиваются.

Использование стилей для id элементов не есть хорошо.
При последующей поддержке такого сайта Вы пойдете в inline стили элементов.
Необходимо принять, что стили для id — это плохо.
Для стилей лучше использовать class. id -использовать для js кода.

Главная задача хорошо сверстанной страницы — возможность перемещения блоков в любое место. Простой пример — у вас есть блок новости.
Теперь в блок новости нужно вставить не только сами новости, но и скажем, блок погоды. В данном случае, если у вас используется каскадная верстка (.class div div и иже с ними), то Вам придется переписывать верстку для погоды и новостей. В большом проекте — это большое время и затраты. (сменили в одном месте — вполне может упасть в другом. Опять придется «выплывать» за счет inline стилей. (либо !important) Проект станет менее понятным.

При верстке проектов лучше подходить с точки зрения какой-либо из методологий верстки — (Для российского сегмента интернета самой популярной методологией является БЭМ, разработанный в недрах яндекса)
id -использовать для js кода


Я бы сказал, что использование id для js тоже зло. Для js лучше пользовать роли или .js-* классы. По той же причине: не ровен час как придется то же поведение применить к нескольким блокам.
Это вопрос уже ближе к стилю кода. Те же классы могут повторяться и т.д.
Прелесть использования id для js — их уникальность, соответственно — поиск по DOM модели будет быстрее (при найденном элементе — поиск далее продолжать не нужно)
О чем, собственно, и речь. Редко когда нужно задать поведение некоего уникального элемента. Обычно это набор элементов с одинаковым поведением. Или одному элементу нужно задать несколько не уникальных действий. Соответственно, id становится неприменимым в данном случае. А биндить события на id для одних элементов, а для других — на классы, имхо, моветон, лучше уж выбрать один стиль. Искать бинды опять же проще, если знаешь, к какому селектору они привязаны.
Здесь с Вами согласен.
Для js я использую классы, написанные в camelcase, в то время как остальное пишу в системе БЭМ, тогда быстро можно разобраться, даже если проект давешний.
А почему не data-атрибуты для js?
Когда-то пришла к такому стилю написания, теперь использую всегда. Не знаю, насколько для вас будет весомым следующий аргумент, но когда я пишу на haml, мне очень удобно использовать именно camelcase.
Большое спасибо за внимательное прочтение статьи и ваш комментарий. Он будет очень полезен новичкам. Действительно, использовать идентификаторы в css — не самая лучшая идея, особенно когда идет речь о сложных проектах.
В данном случае я их использовал по двум причинам.
Первая — это конечно же потому, что описывал процесс верстки одной конкретной страницы, а не сайта, что отражено в заголовке.
А второе — это вопрос удобства чтения CSS. Если в коде я встречаю правило .heading {...}, то я не могу быть точно уверен к какой части страницы оно применится. Может быть это заголовок одного блока или другого. При верстке данной страницы я использовал идентификаторы только для глобальных или уникальных блоков. Поэтому, читая правило #heading {...}, я понимаю, что речь идет о самом главном заголовке на странице и он всегда один.
Во всём остальном — вы абсолютно правы.
За рекомендацию использовать БЭМ — отдельное спасибо. Вот ссылка на неё для всех остальных.
Если Вы в коде встречаете .heading без дополнительной информации — главное, что вы должны полагать — это шапка сайта.
Если же heading «тыкается» в каждый блок — это пример плохого сайта.

Главная проблема верстки, на мой скромный взгляд, когда разработчик говорит себе — тут сайт маленький, одна страница… сделаю-ка я его каскадом и id… А плохо это потому, что:
1) Может потребоваться изменить сайт (даже статический, да)
2) Эта болезнь может передаться новичкам
3) Разработчик может решить — «да я писал на id css, все работает, сделаю-ка я и в большом проекте так же.»
Для российского сегмента интернета самой популярной методологией является БЭМ, разработанный в недрах яндекса

wat? это по каким это данным/критериям? По-моему Яндекс != «Российский сегмент интернета»
Почему вы опираетесь на тэги, ID и каскадные селекторы в вашем css? Если хотите кого-то чему-то учить, то учите сразу хорошему, а именно независимым блокам. И используйте ресет или нормалайзер.
UFO just landed and posted this here
Хорошее разу учить использовать normalize.css или Reset CSS на худой конец и объяснить в двух словах, зачем это нужно.
Все написано достаточно плохо, чтобы можно было смело не рекомендовать данный материал к прочтению а тем более использованию как учебное пособие.
Простите. мне кажется человек который берется учить людей, должен сам являться экспертом в выбранной области и суметь обосновать свой подход.
Я же думаю что вы не сможете обосновать следующие строки
1) #wrapper { 2) #sitemap div { 3) form[name="search"] { 4) header {
Вот пожалуй 4 грубейшие ошибки вашего кода. Вы учите людей делать не правильно, мне кажется нужно для начало самому немного подучиться
можете посоветовать где смотреть как делать правильно? )
UFO just landed and posted this here
по ссылке выдает одни warning-и насчет ID и опасности изменения размеров, ничего толкового.
Рекомендации гугла читали, давно.
Человек выше написал, что там «все достаточно плохо», если имелось ввиду, что «все» это про кучу ID (и то что пара блоков не выделена в отдельные классы), то ок, проехали.
Нигде, нету учебника который научит вас делать хорошо. Нужно постоянно читать W3C документацию, читать тематические форумы, твиттеры, посты, блоги, иногда не плохо посмотреть какое-нибудь видео с конференций. Только самостоятельный, постоянный поиск информации.
Если вы считаете, что это пример хорошей верстки — не продолжайте писать статьи.
В начальной картинке разметки небольшой обман, футер не входит во врапер. А вообще для начала хорошо, для тех кто ни когда не верстал весьма полезно, только теперь прочтите комментарии и напишите статью по потенциальным проблемам которые вызывает ваша верстка, будет хорошая статья.
а зачем он должен входить? Что от этого изменится?

Дабы не быть пустословом, пара примеров:
rkz.ru/
www.pushe.ru/
Правый клик «просмотр кода страницы» и скажите, что Хабр верстали нубы. )
Причем на хабре даже как-то наоборот все сделали — вложили layout во wrapper, обычно наоборот всегда замечал.
Должен или не должен это дело вкуса, другое дело что на схеме входит, а в верстке не входит.
Жду следующую статью, так как люблю bootstrap!
Использование селекторов вида figure div крайне негативно отражается на производительности. Браузеры разбирают селекторы справа налево, а div на странице может быть тысячи
Конец 2013 года, а вы верстаете сайт и ограничиваете его статичными размерами, указывая размеры и отступы в пикселах.
Вы серьезно? Мне кажется, таких верстальщиков нужно перепрофилировать, и либо из них будет хороший «фронт-энд-разработчик», либо «вон из профессии».

Крайне часто приходится сталкиваться с верстальщиками, и давно я такого кода не видел.

UFO just landed and posted this here
Не учитывает различные размеры и разрешения экранов.
UFO just landed and posted this here
UFO just landed and posted this here
Градусы :) Reference pixel в терминологии CSS. Но в любом случае по-моему лучше использовать сантиметры или дюймы — вероятность того что браузер интерепритирует их с учетом dpi и обычного расстояния выше чем у пикселя. Субъективно. В худшем случае браузер будет считать дюйм равным 96 пикселям, то есть разницы с указанием в пекселах не будет, но может посчитать и с учетом конкретного евайса, в то время как пиксели отображать 1:1.
UFO just landed and posted this here
Кто сказал, что 10cm это 10 физических сантиметров? Это где-то 8,2 градуса. На мобильном устройстве линейный размер будет один, на экране проектора совсем другой, но угловой должен быть одинаковый.
UFO just landed and posted this here
Потому что по стандарту, на который вы ссылаетесь не дюйм равен 96 (физическим) пикселям, а (логический) пиксель равен 1/96 дюйма.
UFO just landed and posted this here
:(
In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.)

Опять из-за BC всё зарубили :(
UFO just landed and posted this here
Но вместо того, чтобы исправлять браузеры, стали исправлять стандарт.
UFO just landed and posted this here
The following Win32 API functions are useful for retrieving information about the current display setting:
GetDeviceCaps Retrieves device-specific information for the specified device.
GetSystemMetrics Retrieves the specified metric or system configuration setting.
SystemParametersInfo Retrieves or sets the value of one of the system-wide parameters.
UFO just landed and posted this here
Тем не менее возможности есть, но ею практически никто не пользуется.
UFO just landed and posted this here
Огромное СПАССИБО! Как раз хочу научить жену такому типу работы… Ждем продолжения, и подобных статей.
Т.с. поделитесь, пожалуйста, русской гарнитурой oswald.
Я всегда считал, что критиковать всегда проще, чем что то делать.
Есть замечания по верстке… но я сам отнюдь не специалист… подожду развернутых комментариев от профессионалов.
Автору спасибо.
Кстати, я всегда считал, что DOCTYPE принято писать капсом, а в последнее время чаще вижу написание «doctype». Это такой тренд?
Браузеру совершенно наплевать на то, какими буквами вы напишете доктайп — заглавными или строчными, можете хоть <!DocTyPe hTmL> написать — никто не обидится.

Главное, чтобы доктайп в принципе был указан, и перед ним в коде не было никаких непробельных символов.
У меня даже Geany по-разному подсвечивает:

image
В качестве пустых картинок из макета будем использовать однопиксельное серое изображение, которое будем растягивать по необходимости

Серьезно?
А как нужно? Я просто не в курсе. Только начинаю изучать верстку.
Масштабирование изображений в html через стили или атрибуты считается плохим тоном. Правильно загружать изображение в масштабе 1 к 1 и прописывать правильные размеры через атрибуты width и height для тега img. Данная техника была применена тут только в качестве «заглушки», т.к. в макете не нарисованы настоящие картинки.
Ну то есть, в качестве заглушки лучше использовать нечто вроде pic.png и css вроде

#pic {
       height:96px;
       width:96px;
       background-image: url (..images/pic.png);
       background-repeat:no-repeat;
}


?
Нет, в данном случае, например вместо заглушки для карты
<img src="images/sample.png" width="230" height="180" alt="Our offices">
нужно было вставить ссылку на отдельную картинку соответствующего размера
<img src="images/map.png" width="230" height="180" alt="Our offices">
Пусть даже эта картинка была бы просто серая.
Использование CSS здесь не нужно.
Я обязательно постараюсь избегать заглушек в следующих статьях.
Согласна полностью — быстрее, удобнее. Кроме того, есть отличный сервис lorempixel.com — там есть разделы по тематикам.

И для любителей «ня» — placekitten.com :)
UFO just landed and posted this here
UFO just landed and posted this here
Спасибо за статью.
Тема и формат интересные! во-первых, вполне разжевано, во-вторых — понятно для начинающих, в-третьих — есть замечания по сути. Будем ждать ответов на замечания — раз, продолжения статей — два, новых хороших комментариев — три!
Мне статья понравилась. У меня знания по верстке остались на уровне 2000 года. А теперь я понял, как вообще люди это делают последние лет 10. Ну и узнал про новые теги HTML5.
Небольшое замечание, «LOREM IPSUM» написание текстов в верхнем регистре, имеет смысл подкреплять CSS правилом text-transform:uppercase;. Не нужно будет помнить, что по дизайну должен быть «uppercase» в конкретных местах и следить за этим. Рано или поздно, программист, или контент менеджер, кастомер наберет текст не «uppercase». и дизайнеры с тестерами будут сеять панику ))
А мне статья понравилась, хотя я и полный профан в области верстки:) Так как много критики — не могли бы эти самые «критиканты» подкинуть годных статей о том, как правильно верстать?
Статья не плохая, но есть несколько неясностей.
Пожалуйста описывайте для чего и почему используете, например, figure.
Почему карточки сотрудников это figure, а не article, или просто div? Я не понимаю.

Не люблю я избыточные обертки, списки внутри навигации, когда достаточно просто ссылок внутри nav, #footer внутри footer (почему не body > header? Никакого излишества + сразу понятно, где элемент и для чего он), и прочих олдскульных техник.
Сейчас браузеры вполне позволяют делать макеты с несколькими колонками без лишних оберток.
Скажешь это заказчику, когда он попросит кроссбраузерность от IE7. Причем выполнить верстку будет значительно быстрее как просят, нежели объяснять заказчику, что даже мамонты давно перешли на IE8+.
Не везет вам с заказчиками :(
Мои даже об IE 9 вспоминают очень редко. Не вижу смысла потакать выпендрежам старой версии браузера, когда все браузеры ведут себя более или менее по стандартам, а он, видите ли, имеет свои стандарты.
Мое мнение — HTML должен быть для контента, как он и задуман. То есть в идеале в HTML не должно быть ничего того, что не является контентом — излишних оберток, <div class="clearfix"></div>, и прочего подобного. И в абсолютном большинстве мне удается этого добиться с помощью CSS, для визуальных фишечек обычно достаточно псевдо-элементов (стрелочки, фон шапки на всю ширину страницы при фиксированной ширине содержимого, и т.д.).
Я понимаю, что у вас свои особенности — но в вебе такая консервативность вредна, и если учить людей верстке — то современной.
" и если учить людей верстке — то современной."
В каком смысле?
Предлагаете забить на армию пользователей с IE8-9 и сразу хреначить разбивку блоков с помощью flexible layout и прочими прелестями? ) Мне пока даже во сне такое не снилось.

Есть заказчик, есть его бабки и есть конкретные требования, личные предпочтения в любви к особым инструментам тут не имеют смысла. ИМХО. (исключением являются случаи когда заказчик ничерта не понимает в браузерах и ТЗ составил по образцу которое нашел в сети).
Предлагаете забить на армию пользователей с IE8-9 и сразу хреначить разбивку блоков с помощью flexible layout и прочими прелестями? )

Да! Да! Да!
Я такое уже практикую на рабочих сайтах понемногу (о display: flex), а псевдоэлементы уже давно стали частью обычной верстки.
Многие говорят об MVC, и в это же время используют HTML для формирования интерфейса. HTML — просто семантические данные, как они отображаются должен решать CSS. Если это не осуществимо на 100% сейчас — это не значит, что не стоит к этому стремиться.

Есть заказчик, есть его бабки и есть конкретные требования

Если вы фрилансер — я вас не понимаю, совсем, а если вы работаете в компании — то я бы на вашем месте искал другое место, где народ понимает скорость развития веба и стоимость поддержки монстров каменного века.
где народ понимает… стоимость поддержки монстров каменного века.

А если народ также понимает, что эта стоимость многократно окупается?
Такое может быть, но:
а) далеко не всегда
б) со временем поддержка стает всё сложнее, а выгоды всё меньше
в) вы заставляете пользователей грузить лишний трафик и выполнять код с обходами и трюками для старых версий, что сложно назвать выгодой
г) вы сдерживаете развитие интернета (если бы, как Google, все поддерживали только последние две версии, читали бы ли мы с вами об поддержке IE + в этом треде?)

Обновление до новой версии доступно всегда, и оно требует минимальных усилий со стороны пользователя.

Понятно, что есть разные крайности, и окупаемость старых версий имеет место быть, но это слишком далеко от мейнстрима.
Обновление до новой версии доступно всегда, и оно требует минимальных усилий со стороны пользователя.

Увы, нет. Некоторые пользователи и слова-то такого «обновление» применительно к компьютерам, а то и телефонам не знают
Не вижу смысла потакать выпендрежам старой версии браузера, когда все браузеры ведут себя более или менее по стандартам, а он, видите ли, имеет свои стандарты.

Во времена ие6 стандартов то и не было
Но сейчас другие времена, есть большой выбор браузеров — простых, сложных, функциональных, надежных, открытых, красивых — выбирайте любой.
Все из них стараются соответствовать стандартам, которые принимаются общими усилиями, и вдруг появляется новая версия «браузера», у которого пачка своих новых и интересных «стандартов».
Даже IE 11 не понимает стандартизированный display: flex;, у него свой гибридный display : -ms-flexbox;, и судя по всему так будет всегда.
CSS flexbox layout пока находится на стадии рекомендации, на W3C есть черновик. У chrome до этого лета тоже был префикс (display: -webkit-flex). Так что не придумывайте про стандарты.
Последняя версия рекомендации от 18 сентября прошлого года, то есть более чем за год до релиза Windows 8.1, а в браузере не реализовано. Всё это создает ненужную энтропию. Если за год выйдет десяток версий Chrome и пяток Firefox/Opera, то IE, который устарел ещё до релиза мы будем (или нет:)) поддерживать ещё долго, ибо они не включат поддержку правильного синтаксиса обновлением. В этом вся проблема — скорость и кривизна его развития никак не вписывается в современный веб.
18 сентября написана рекомендация. Сам черновик датирован 30 октября этого года.
Но было бы неплохо выпускать новые версии IE почаще. Раза в 2 эдак.
UFO just landed and posted this here
Приводите в пример Google — стабильная + предыдущая версия браузера. Всё, что раньше работать может, но совсем не обязательно. Не хотите обновляться — сами виноваты.
в данном случае это очень долгая и холиварная тема. Иногда даже кажется, что если бы браузеры стоили пусть и 1$, а каждое обновление .99с, то народ бы охотнее обновлялся. Что-то вроде споров про Мак и ПК demotivation.me/0g5r9lo7c73fpic.html
В рамках данной статьи было бы очень интересно почитать про такую тему, с аватарками сотрудников.
А именно – у сотрудников могут быть длинные имена-фамилилии, которые будут занимать несколько строк и которые (Череззаборонагозадерищенский) точно не влезут по ширине. То же самое с должностью (главный помощник старшего менеджера по закупкам нового перспективного оборудования).
Как вариант — просто обрезать:
text-overflow: ellipsis;
В английском языке имена/фамилии и должности короче.
Спасибо! Как раз актуальный вопрос для меня.
Да ладно вам, вы на автора накинулись за селлекторы айдишниками и тегами, а между тем цель статьи в том, чтобы показать новичкам что вообще из себя представляет реальная верстка. Понятное дело, что потом авторе скажет, мол, «помните как мы делали в первой статье — так вот, так делать не нужно, потому-то потому-то». А в целом, вполне себе годная статья, вот только сразу все охватить сложно, и по-хорошему такие статьи сначала надо показывать коллегам, а затем публиковать.

Я бы правда добавил в статью еще пару строк про составные селлекторы, а то в свое время для меня было просто открытием, что можно делать так:

.link.bold + img.thumbnail{  }
В CSS3 можно даже так:
/*
The following selector represents an HTML anchor a with an href attribute whose value ends with ".html".
Обработает все теги a с атрибутом href при условии, что значение href заканчивается подстрокой .html
*/
a[href$=".html"]


W3C Recommendation 29 September 2011
Спецификации и документация браузеров (и не только браузеров, а также языков и инструментов) — наше всё. Был бы ещё такой хитрый метод насильного обновления updateForce(); в JS со своей реализацией под каждый браузер — всем бы легче жилось. Но нет, занимаются WebGL и прочими красивостями.
HOME
ABOUT US
Кэпс в html конкретно выдает уровень писанины, ну и с ID перебор какой-то.
Сам верстальщик, правда с мелким опытом.

Забавные комментарии у критиков, которые даже толком не «тыкнули» в ошибки.
Люди, эти статьи читает очень много новичков, если не хотите чтобы завтра в вашей фирме кто-то так верстал, то будьте добры, давайте ссылки на материалы/книги которые вы считаете эталоном по фронт-энду.
Не критика, а просто комментарии и мои предпочтения в верстке.

— DOCTYPE пишу в верхнем регистре. Для html5 не принципиально, но xml-парсер, например, выдаст ошибку.
— Если используете html5, то пишите meta, link короче. Также, лучше закрывать одиночные теги.

<link rel="stylesheet" href="default.css" />
<meta charset="utf-8" />

— ИЕ6 конечно умер, но я стараюсь минимально его поддерживать, поэтому вместо селекторов атрибута типа [type="text"] и других подобных вещей лучше добавлю лишний класс. Вообще, часто приходится отказываться от удобных решений в угоду совместимости.
— Логично было бы поместить nav и #heading в header. Также footer по схеме на картинке, должен быть внутри #wrapper:

<body>
  <div id="wrapper">
    <header>
      <nav></nav>
      <div id="heading"></div>
    </header>
    <aside></aside>
    <section></section>
    <footer></footer>
  </div>
</body>

— Нужно установить :visited-цвет ссылок меню, иначе их цвет может измениться, после перехода пользователя.

.top-menu a,
.top-menu a:visited {
  color: #b2b2b2;
}

— Используя свойство background, обратите внимание, что если вы устанавливаете только, например цвет (background: red;), то сбросятся все другие фоновые установки у данного элемента (image, position и т.п.). Поэтому, если нужно установить только одно свойство, пишите лучше не background: red;, а конкретное свойство:

background-color: red;

— То же, кстати, касается font — используя его, но не перечисляя всё, вы рискуете, что часть свойств вернется к значениям по-умолчанию, независимо от того, что ранее вы установили их для этого элемента. Здесь можно увидеть, что я имею ввиду. У background то же поведение, поэтому лучше взять за правило использовать по-необходимости частные свойства, а не только общие.
— Нигде не увидел борьбы с floating-багом. Нужно либо добавлять clear-элемент после группы плавающих элементов, либо присваивать их контейнеру overflow: hidden;, либо использовать какой-то еще способ. Я бы еще и для старого IE пофиксил с помощью установки hasLayout (например zoom: 1;).

Ну и общие замечания — по излишнему использованию id, отсутствию независимости блоков и соответственно излишнее увлечение селекторами тегов. Не бойтесь использовать классы в любом количестве. Кстати тоже посоветую прочитать про БЭМ. Можно извлечь полезные мысли, хотя полностью концепция слишком громоздкая имхо.

P.S. Комментария моего комментария приветствуются :)
UFO just landed and posted this here
Воу, уровень занудства over 9000, я даже запутался :)

В HTML(5) действительно нельзя реально «закрыть» одиночный (void) тег. Закрывающей слеш поставить можно, но это ни на что не влияет и не делает одиночный тег самозакрытым. Но совет был дан исходя из логики xml (чтобы получить валидный документ), где постановка закрывающего слеша в открывающем теге закрывает его, а одиночных тегов нет вообще. Поэтому и написал «закрывать (логика xml) одиночные (логика html) теги».

P.S. Написал текст выше и понял, что это выглядит как бред (:
UFO just landed and posted this here
UFO just landed and posted this here
Собственно что и имелось ввиду.
Везде где подразумевается использовать только заглавные буквы, лучше это делать средствами CSS
Я довольно далек от верстки, и возможно сейчас спрошу глупость, но все же. Вот есть у вас элементы, которые будут на каждой странице (шапка, меню, логотип и т.д.). Вы их вставили прямо в страницу. Я так понимаю в остальные страницы все это будет копипаститься? И если что-то захочется поменять среди этих элементов, придется обойти все страницы? Нельзя ли вынести все это в одно место, откуда будет подтягиваться для других страниц? Или я чего-то не понимаю?
В рамках верстки подобные проблемы очень редко решаются. Для этого обычно используют серверный софт, на который такую верстку «натягивают».
Попробуйте почитать про шаблонизаторы. Я думаю, что вы откроете для себя новый удивительный мир :)
UFO just landed and posted this here
Вашему комментарию не хватает только объяснения почему центрирование блока через left, right лучше, чем через margin: auto.
Sign up to leave a comment.

Articles