Динамическая верстка – 500 Internal Server Error

Адаптивная вёрстка / HTML Academy corporate blog / Habr

В чём разница между резиновой, адаптивной и отзывчивой вёрсткой? Как правильно их применять?

Давайте разберёмся в отличиях подходов и попробуем сформулировать один общий вместо трёх.

Когда мобильного веба не было даже в самых смелых фантазиях, весь интернет был на десктопных компьютерах с небольшими экранами. Оптимизирован для разрешения 1024 на 768 и браузера Internet Explorer 5! — гордо писали тогда на сайтах. Но прошло время, экраны подросли и пришлось к этому как-то подстраиваться. Сначала это были просто резиновые таблицы: колонки по 25%, содержимое 50%, а в отдельной строке colspan=3 и распорка для минимальной ширины. Надеюсь, вы не поняли о чём я сечас говорил.

Резиновая вёрстка — это когда вы задаёте всему макету и отдельным его частям не фиксированную ширину, а эластичную — в процентах. За исключением минимальной и максимальной ширины. Высоту в вебе в принципе не принято задавать — обычно она подстраивается под содержимое. Фикс или резина? — спрашивали верстальщики 2000-х про макет и втайне надеялись на второе, поинтереснее. Сейчас сложно представить, но когда-то это было прорывной идеей, которая усложнила вёрстку, но сделала первый шаг в правильном пути.

Таблицы для раскладки ушли, а резиновая вёрстка осталась. Если у вас эластичные флоаты, флексы… да хоть гриды! — это всё равно резиновая вёрстка. Но если ширина внешнего контейнера зафиксирована — это уже фикс, сколько бы ни было резины внутри. Чуть более универсальный фикс, но всё равно. В общем, главное чтобы сайт двигался так или иначе вместе с окном, а не торчал кирпичом где-то в центре или с краю.

Когда расширился круг устройств с интернетом и появились первые мобильные браузеры — встала задача как-то подстраиваться под них. Простая резина здесь уже не справлялась — нужно было переписывать стили. Одной из первых, в 2006 году появилась техника адаптивной раскладки Марка ван ден Доббельстина. В статье на A List Apart Марк предложил добавлять классы при загрузке или ресайзе окна и на каждый диапазон вешать стили. До первой реализации медиавыражений в Safari оставалось два года.

Когда в начале десятых годов появилось для чего адаптировать и чем адаптировать — мобильные браузеры и медиавыражения — вышли книги, давшие названия подходам: «Адаптивный веб-дизайн» Аарона Густавсона и «Отзывчивый веб-дизайн» Итана Маркота. Подходы Аарона и Итана продолжали идеи Марка, но с более современными технологиями и несколько отличались направлением мысли.

«Адаптивный веб-дизайн» Аарона предлагал гибко адаптировать сайты к возможностям устройств и браузеров. Важной частью этой философии был ненавязчивый JavaScript с прогрессивным улучшением — и всё это поверх семантической разметки. Хотя Аарон писал не совсем об этом, сегодня принято считать, что главное в адаптивной вёрстке — привязка к конкретным разрешениям и устройствам. Стили переключаются от одного брейкпоинта к другому, то есть у вас есть фиксированные макеты для iPad и iPhone, а то, что между ними вас не волнует.

«Отзывчивый веб-дизайн» Итана ставил во главу три вещи: резиновый макет, гибкие картинки и медиавыражения. Все размеры и отступы Итан предлагал указывать в процентах с сумасшедшими дробями для точности. Отличительной чертой подхода стало плавное изменение сайта, с ориентацией не на конкретные устройства, а на содержимое. То есть ваш резиновый макет хорошо выглядит не только на iPhone и iPad, но и в любой точке между ними.

Чуть позже Итан сформулировал ещё один важный принцип в книге «Сначала мобильные». Если до тех пор отправной точкой для адаптации вёрстки служила десктопная версия, то он предложил перевернуть схему и начинать с мобильной версии, а потом её улучшать. Почему так? Потому, что усложнять простое проще, чем упрощать сложное. Вдуматесь! А ещё потому, что нет соблазна просто спрятать сложно адаптируемое и обделить мобильных пользователей.

Ну как, стало понятно? Вот адаптивная, вот отзывчивая… М-м, нет, не очень. Из-за путаницы между техникой адаптивной раскладки и философией адаптивного веб-дизайна, из-за того, что все эти подходы прекрасно сочетаются и уже не проследить чёткую границу между ними — из-за всего этого, я плюнул на терминологическую чистоту и стал называть всё это адаптивным дизайном или адаптивной вёрсткой. Это понятие всегда было достаточно широким, чтобы вместить все остальные способы.

Да и принцип дискретной адаптации от размеров устройств и без резины имел смысл лет 10 назад. При сегодняшнем разнообразии устройств полагаться на конкретные размеры и жёстко переключаться между ними — значит однажды очень больно промахнуться. Притом, никто вам не мешает при полностью резиновой вёрстке дописывать адаптацию под нужные разрешения.

Ну и как теперь верстать? Просто! Сначала делаете мобильный резиновый макет, который хорошо вписывается в небольшие устройства. А когда размеры экрана или окна начинают расти — начинаете использовать появившееся пространство для улучшения интерфейса. Появляется боковая колонка, вторая, растут размеры картинок и подгружаются новые разрешения и так далее. То есть медиавыражения меняют стили не когда вы дошли до экрана самого модного телефона, а когда это нужно для содержимого сайта и удобства пользователя. Мы именно так и учим делать на интенсиве по продвинутой вёрстке.

Чтобы сделать хороший адаптивный сайт, нужно понимать много нюансов: вьюпорт, медиавыражения, адаптивные картинки и другое. Сегодня мы сделали первый шаг и разобрались с подходами: он оказывается всего один. Про остальное ещё поговорим.

Видеоверсия

Вопросы можно задавать здесь.

habr.com

Верстка повторяющихся блоков / Habr

Довольно часто при верстке сайта возникает необходимость размещать блоки одинаковой ширины, но разной высоты в контейнере с переменной шириной (читай резиновом). Плюс на этот список может применяться фильтр, который JS-ом скрывает или показывает элементы списка, при этом он не должен разрушать «строки», верстку, или образовывать дыры, поэтому решения на таблицах не катят сразу. Простейший пример — каталог товаров:

Решили вместе с morfi сделать более-менее универсальное решение, которое бы позволило без лишних проблем публиковать такого рода контент. Важный момент — что высота блоков может зависить, к примеру, от высоты заголовка, или от описания, если бы оно было в макете.

Тут есть два подводных камня. Первый — зазоры между блоками. Если просто поставить float:left; margin-right|bottom:50px (я упростил синтаксис), то у последнего элемента в «строке» всегда будет отступ, поэтому он никогда не будет четко на границе контейнера.

Решение с 

float, лежащее на поверхности:

1. Элементам задаем float:left; margin-top|left:50px
2. Заворачиваем элементы в ещё один контейнер и ему задаем margin-top|left:-50px — отрицательный отступ, и пусть теперь внешний контейнер (изначальный) будет называться wrapper, а внутренний — container.
3. Контейнеру и врапперу для дружбы с IE нужно присвоить zoom:1 и чтоб они не схлопнулись от float-элементов — overflow:hidden
4. Чисто для IE нужно указать display:inline для блоков, иначе мы получим удвоенный margin

Все бы ничего, но в такой ситуации, если высота блоков может сильно отличаться, может возникнуть вот такой косяк:

Обратите внимание на блоки three, four и five. Зеленый блок — это враппер, синий — контейнер.

Логически ситуация понятна — блок должен тянуть линию (или «строку»), в которой он находится. Это поведение — типичное для display:inline-block.

Для того, чтобы применить это решение на практике нужно:

1. Снова задаем margin как и в примере выше
2. Блокам раздаем универсальную кроссбраузерную конструкцию display:-moz-inline-box; display:inline-block; *zoom:1; *display:inline
3. Замечаем, что горизонтальные расстояния оказались чуть больше нужных 50px — это из-за пробелов, затесавшихся между inline-block
4. Для борьбы с пробелами измеряем его ширину — получается 4px, а это 25% от 1em, который по-умолчанию равен 16px. Таким образом контейнеру ставим word-spacing:-0.25em, а блокам word-spacing:normal
5. Для IE нужно также прописать блокам text-align:top, иначе элементы будут выровнены по базовой линии.

Багов пока не замечено, решение кроссбраузерное. Inline-метод спокойно выдерживает простановку text-align:center у контейнера (см. скриншот). Надо только не забыть у блоков выставить обратно text-align:left

(см style.css — я их закоментировал там).

Работающий пример доступен по адресу: http://test.dis.dj/blocks/.

P. S. Решение не ново, но оно будет полезно в любом случае.

P. P. S. На скриншоте — будущий интернет-магазин-портал для мамочек.

habr.com

Организация отступов в верстке (margin/padding) / Habr

Цель этой статьи не усложнить простые вещи, а акцентировать внимание на известных стандартах, о которых почему-то забывают. Важно соблюдать осмысленную структуру во всех аспектах верстки, и не менее важно придерживаться ее в отступах. И одним из основных принципов верстки является гибкость. А именно, возможность легко вносить какие-либо изменения и ничего при этом не сломать. Правильное обращение с margin и padding играет очень большую роль в этом деле.

Ниже перечисленные принципы выполняются в среде позиционирования элементов на странице. В элементах декора тоже выполняются. Но не так категорично.

Основные принципы:

1. Отступы идут от предыдущего элемента к следующему.
2. Отступ задается последнему возможному элементу в доме.
3. Отступы нельзя задавать для независимых элементов ( БЭМ блок ).
4. У последнего элемента группы, отступ обнуляется (всегда).

Отступы идут от предыдущего элемента к следующему.

margin(ы) задаются от предыдущего элемента к следующему, от первого ко второму, сверху вниз, слева направо.

Это значит.что такие свойства как margin-left и margin-top не используются (не без исключений). С padding все немного наоборот (кроме того, что он используется для, декоративных целей, увеличения области ссылки и т.д.). Когда блоку нужен отступ сверху или слева, он его получает за счет padding-top и padding-left родителя.

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

Отступ задается последнему возможному элементу в доме

margin(ы) задаюся только между соседними элементами дом дерева.

В примере 3 списка, в следующей структуре:

<section>
  <div>
    <div>
      <ul>
        <li><a href="">Далеко-далеко, за словесными.</a></li>
        <li>...</li>
        <li>...</li>
        <li>...</li>
        <li>...</li>
      </ul>
    </div>
  </div>

  <div>...</div>

  <div>...</div>
</section>
 

Не за счет дочерних элементов, а за счет соседних делается отступ.

В этой ситуации .main-section__item и является последним возможным, кому можно задать отступ, чтоб разделить списки. Такого же эффекта можно добиться, если задать отступ диву, списку, лишке, ссылке, но это будет не правильно.

Этот пример довольно простой. Но если представить на много большую вложенность, где кто-то намусорил отступами, когда какие-то маргины схлопываются. а какие-то суммируются с падингами.

<section>
  <h2>headline in a section of seven words</h2>
</section>

Если взять пример с заголовком, и нужно сделать отступ для заголовка сверху. то последний элементом будет section и для него задается padding-top, margin(ы) которые стоят по дефолту всегда нужно обнулять.

Самая простая причина, по которой стоит придерживаться данного принципа, это чтоб было проще найти отступ в будущем, либо вам, либо тому, кто будет в дальнейшем работать с вашей версткой. Это если говорить про удобство.

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

Отступы нельзя задавать для независимых элементов ( БЭМ блок )

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

Если нужно сделать блоку отступ. Без ущерба это делается с помощью:

• Наследование через элемент (если вытащить этот блок с элемента, отступа не будет, и его можно будет просто разместить в другом месте).
• Добавление класса (можно сделать блок элементом).
• Обертка (как блок, у которого роль, только в позиционировании).

.block__item > .block { margin-right: 10px; }

.block.block__item { margin-right: 10px; }

.block-wrap > .block { margin-right: 10px; }

У последнего элемента группы, отступ обнуляется (всегда)

Возьмем для примера список и изображение.

<ul>
  <li><a href=""></a></li>
  <li><a href=""></a></li>
  <li><a href=""></a></li>
  <li><a href=""></a></li>
</ul>

<img src="" alt="">

Это горизонтальное меню и логотип (который почему-то справа).

Между ссылками и логотипом одинаковое расстояние. Но если есть расстояние между последней лишкой и новым блоком, то этот отступ делается не за счет лишки. А список отступает.

Для последней li отступ обнуляется. И отступ делается между соседними элементами ul и img. О чем говорилось во втором принципе.

Возьмем другой пример:

<aside>
  <div>
    <article>
      <h4>...</h4>
      
      <p>...</p>
      
      <aside>
        <time>10.10.10</time>
      </aside>
    </article>
  </div>

  <div>...</div>
  
  <div>...</div>
</aside>

Интересует нас отступ между новостями, которые задается .blog-preview__item { margin-bottom: 20px; }

. Последний margin обнуляется, а нижний отступ делается за счет padding blog-preview. О чем говорилось во втором принципе.

Чаще чем другие псевдоклассы, надо использовать :last-child.

.item:not(:last-child) { 
  margin-bottom: 20px; 
}

// или //

.item {
  // другие стили //
  margin-bottom: 20px; 

  &:last-child {
    margin-bottom: 0;
  }
}

// или margin-top, основная идея здесь, не в направлении маргина, а в отсутствии лишнего //

.item + .item {
  margin-top: 20px;
}

// или //

.item {
  // другие стили //

  & + & {
    margin-top: 20px;
  }
}

Исключения

• В первую очередь это добавление текстового контента через админку . Здесь отлично справляется подход к отступам заданный браузером. Но этот подход нельзя считать подходящим в обычной верстке как и несколько <br> в коде подряд.
  
  
• «Динамические элементы». Когда элемент появляется после какого-то блока, то он появится со своим отступом.
  
• Иногда вертикальные падинги лучше задавать дочерним блокам, нежели всей секции. Если в перспективе, на других страницах в том же месте, это относится ко второму принципу, задавать отступ для последнего возможного, вот иногда секция последний, но не возможный.
• Отрицательные маргины, auto, padding для контейнера.
  

---

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

P. S. Советую ознакомиться с публикацией Кастомный подход для нормализации и сброса стилей (custom-reset.css). И советую использовать css линтеры. И кому интересно, может решить css задачку.

habr.com

Требования к html-верстке / Habr

1. Верстка, аутсорсинг и технические задания

Верстка — относительно независимый этап веб-разработки и, к примеру, в маленьких веб-студиях часто — это первый кандидат на аутсорсинг в условиях ограниченных трудовых ресурсов.
Так сложилось, что мне часто приходилось отдавать эту работу субподрядчикам и, несмотря на предполагаемую однозначность результата, иногда верстальщики меня очень удивляли. Причем чаще — в негативном смысле.

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

И этот момент игнорируется. Часто это происходит из-за предположения, что трудозатраты на написание детального ТЗ в сумме со стоимостью аутсорсинга не окупаются сэкономленным временем штатного верстальщика. В конце концов, верстка — это ведь не так уж сложно — думает рядовой project менеджер. И, как правило, это действительно прокатывает, *хвала человеческому интеллекту*, профессиональные верстальщики в большинстве своем ограничивают буйство экспериментаторского духа и заранее знают, какие технические решения в верстке могут вызвать у заказчика геморрой не столь адский, чтобы забанить верстальщика, но все же исключающий радость и восхищение прекрасным html-макетом.

Тем не менее, вероятность факапов, как показывает практика, не столь мала, чтобы этим можно было пренебречь.

А основное заблуждение здесь в том, что детальное ТЗ — это сложно и трудоемко. Какие-то специфические требования к макету в любом случае приходится описывать, а вот на общие требования и рекомендации, как правило, забивают.

2. О, велика моя скорбь!

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

Табличная верстка и стили, не вынесенные в CSS файл и стандартный дримвиверовский скрипт для подсветки кнопок даже не воспринимаются как недостатки после того ада, который я увидел. Все поля ввода были вставлены внутрь тегов label, засунутых в отдельные формы, причем при попытках как-то привести это в человеческий вид, вся верстка разваливалась. CSS классы имели кириллические названия, причем не осмысленные, а вида «.стиль1,.стиль2». Большинство элементов форм стилизировались каким-то мало известным и до ужаса кривым скриптом на jQuery, некоторые элементы имели одинаковые ID и между ними был JS код, оперирующий как раз этими элементами и получающий их по ID, и верх маразма — это применение в конце документа метода jQuery.сss чтобы задать стили, которые ну совсем ничто не мешало просто прописать в CSS файл. А еще хедер сайта вместе с кучей ссылок (шрифтом Tahoma и без сглаживания) был сделан одной картинкой, на которую наложены элементы MAP и AREA. Не буду больше травмировать вашу психику описанием фейлов в этом замечательном макете, т. к. было их там еще бессчетное количество.

В общем, поверьте, товарищи, это был ппц, который к тому же подкрался практически перед самым дедлайном.

Происшествия такого вот характера побудили меня опубликовать список требований и рекомендаций, которые будут полезны как людям, отдающим макеты на html-верстку, так и собственно верстальщикам.

Вы можете переработать эти рекомендации и дополнить ними свое типовое ТЗ на верстку. Многие вещи из перечисленных вполне очевидны, но вы можете извлечь profit из того, что все они собраны в одном месте. Некоторые пункты (к примеру требования к поддержке браузерами или используемым скриптам) для разных контор специфичны, но я не буду далее писать расплывчатых фраз, чтобы этот списочек можно было легко скопипастить и заточить под свою специфику работы.

3. Требования и рекомендации

1. Кроссбраузерность
Сайт должен нормально работать в IE7+, FF3+, Opera9+, Safari4+, Chrome последней мажорной версии (или в зависимости от условий договора с клиентом и года, в котором вы читаете эту статью).

2. Всегда описывайте цвет фона для body даже если он белый.

3. Если используете CSS хаки, комментируйте, что это и для какого браузера, а лучше используйте css_browser_selector.js. Заботьтесь о верстальщиках, которым придется работать с этим макетом после вас.

4. Названия классов и id должны по смыслу соответствовать применению
например, header, menu, footer, news

5. Просьба разделять основные html блоки комментариями. Примерно так:
<!——BEGIN FOOTER —>
<!——END FOOTER —>

Это нужно для создания из сверстанного html макета шаблонов для CMS, после чего комментарии будут удаляться.

6. Не пренебрегать возможностью использовать GIF/PNG с 8-битным альфаканалом вместо PNG-24, где это возможно.

7. Все что можно сделать без Javascript, делать без него.

8. Если Javascript кода много — нужно его выносить в отдельный файл. Обработчики событий тоже лучше отделить и объявлять в отдельном файле.

9. Если это еще не оговорено с заказчиком, предварительно оговорить, какие JavaScript библиотеки вы планируете использовать при верстке макета, чтобы потом не оказалось, что при верстке использовался, к примеру, PrototypeJS, а заказчик планирует в обязательном порядке внедрять на сайт jQuery.

10. Для резиновых макетов обязательно должна быть задана минимальная и максимальная ширина.

11. Если в Т.З. не сказано другое, макет обязательно должен помещаться без горизонтальных скроллбаров в развернутое на весь экран окно браузера при горизонтальной составляющей разрешения экрана 1024px, а если позволяет размер макета, то и 800px.

12. В папке с изображениями не должно быть картинок, не использующихся в верстке. Если что-то исключили из верстки или переделали — не забывайте удалять уже ненужные картинки.

13. Для всех элементов, которые могут содержать текст различной длины, который должен быть вписан в одну строку (например, для кнопок или заголовков, если в дизайне не предусмотрено, что они могут занимать больше одной строки), обязательно задавайте CSS свойство white-space:nowrap.

14. CSS файл должен быть разбит с помощью строк с комментариями на блоки по функциональному назначению, например:

/* ___________1. Сброс CSS____________________*/
/* ___________2. Типовые элементы____________*/
/* _______________2.1. Залоговки______________*/
/* _______________2.2. Ссылки________________*/
/* _______________2.3. Элементы форм_________*/
/*___________3. HEADER (Шапка сайта) __________*/
/*___________4. FOOTER (Подвал )_______________*/
/*___________5. SIDEBAR (Справа)_______________*/

Как именно структурировть стили — вопрос немного холиварный, но главное — как-то это делать.

15. Если сдача верстки производится более чем одним этапом (например, верстальщик отправляет страницы по одной, или если ему возвращаются на доработку уже сверстанные страницы) и вы не используете систему контроля версий для верстки, исполнитель должен в обязательном порядке прикрепить файл с описанием изменений в макете примерно такого содержания:

• Добавил новые картинки в папку img,
• Картинки btnHome.jpg и btnFeedback.jpg уже не нужны, можно удалять
• Изменил html-код в секции файла anketa.html
• Добавил в конец файла main.css новые стили (начиная с .form_row и ниже).

16. Оговорить, в какой кодировке должен быть html-макет. CSS и JS файлы должны быть в той же кодировке, что и макет, иначе вероятность долгой и утомительной охоты на баги критически возрастает.

17. Если в макете присутствует JS, изменяющий DOM — внимательно следить, чтобы все корректно работало в Опере, т. к. этот замечательный браузер при нажатии на кнопочку назад страницу не перезагружает, а отдает закешированный документ, причем очень важный момент: документ не просто закешированный, а еще и с учетом всех модификаций DOM, которые были выполнены с помощью JS

18. Не забывайте прописывать cursor:pointer для кнопок, сделанных не с помощью input. Если вы не знаете, будет на эту кнопку повешен обработчик событий с помощью JS или это будет ссылкой, лучше в любом случае использовать тег <a>.

19. Если вы делаете обработку событий при нажатии на ссылки, следите за тем, чтобы обработчики событий возвращали false, или же используйте href=’javascript:void(0)’ вместо популярного href=’#’, чтобы страница не скроллилась вверх.

20. Верстайте формы правильно: метки полей должны находиться в тегах label, имеющих правильно заполненный атрибут for. Предусматривайте при верстке форм элементы для вывода ошибок валидации и стили для неправильно заполненных полей. Если это не предусмотрено в т.з. и дизайне, обязательно обсудите это с заказчиком.

21. Если в макете используются нестандартные шрифты, обязательно оговорите, можно ли элементы с нестандартным шрифтом делать картинками, если нельзя — обсудите, с помощью какой технологии будет реализовано их отображение (sIfr, Cufon, etc.)

22. Если не оговорено обратное для частных случаев, все блоки, высоту которых ничего в дизайне не мешает сделать динамической, должны иметь именно динамическую (т. е. зависимую от содержания) высоту, а иногда, чтобы ничего не могло потенциально поломать дизайн, нужно задавать и минимальную высоту. Если хотите сделать блок фиксированной высоты — сначала спросите у заказчика.

23. В макетах, где высота страницы зависит от контента (а таких, как правило, большинство), предусматривайте, чтобы футер был прибит к низу браузера при отсутствии/малом количестве контента, если не оговорено обратное.

24. Если макет не проходит 100%-ную html-валидацию, постарайтесь по крайней мере делать так, чтобы использование невалидного кода было оправданно. Не стоит факапить валидность верстки только потому, что «мне так нравится» или «так получается короче»

P.S.

Надеюсь, этот списочек требований и рекомендаций будет вам полезен! Если есть конструктивные мысли, предлагайте в комментариях, чем его можно дополнить.

habr.com

переход к семантической разметке — главная цель HTML / Habr

Первоначально технология HTML (hypertex markup language) была предназначена для описания смысловой структуры веб-документа, то есть для определения частей текста, в которых находятся различные по типу и содержанию части страницы как например заголовки, абзацы, сноски, иллюстрации, гиперссылки и так далее. Говоря академическим языком, HTML создан для семантической разметки документа.

Напомню, что семантика — это раздел языкознания изучающий отношения и способы выделения смысловых структур в речи. К примеру определение членов предолжения (подлежащее, сказуемое, дополнение, определение), изучение отношений и заложенного в них смысла (что является субъектом/объектом действия, а что уточняет их описание и т.д.).

До HTML задача семантической разметки документов решалась с помощью:

• TeX (технологии 1978го года) для макетирования академических публикаций
• SGML (технологии 1968го года) для более широкого спектра задач. SGML очень похож на своего потомка XML за исключением ряда правил, которые в некоторых случаях заметно усложняют чтение разметки, как например разрешение не ставить угловые скобки в тэгах.

Другими словами, если TeX был адаптирован строго под нужды макетирования университетских докладов, научных работ и тому подобного, SGML позволял создавать структуры информации подобные Реляционным Базам Данных, то есть реализоваывать ER-модели (entity-relationship).

(пример ER-модели)

(пример ER-отношений)

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

Тим Бернерс Лии создавая Web в конце 80ых, взяв за основу SGML, упростил синтаксис, создал перечень предопределенных тэгов для макетирования веб-страницы, правила использования которых задал с помощью DTD (технология из семейства SGML которая регламентирует порядок использования тэгов — то есть перечень разрешенных атрибутов, вложенных тэгов, разрешение на текстовый контент и так далее) и мы получили HTML 1.0

Таким образом HTML основанный на SGML первоначально был призван для описания структуры документа в контексте ER-отношений ее частей, то есть определения структуры и содержания документа в терминах сходных к базам данных.

Теперь представьте ситуацию, когда в прикладной программе для того чтоб подвинуть GUI-кнопку на несколько пикселей в какую-либо сторону Вам приходится редактировать структуру базы данных. Парадоксально, но в соверменном вебе это в порядке вещей — очень часто для того чтоб визуально подвинуть какой-либо элемент (GUI-кнопку) приходится изменять HTML-структуру (базу данных)!

Развитию такой ситуации послужила очень острая конкуренция браузеров начавшаяся еще в 90ых, во время которой HTML расширился большим количеством тэгов предназначенных для создания исключительно визуальных эффектов, а не для выделения семантических единиц в структуре веб-документа. Объединение разметки смысловых частей документа и их внешнего оформления в одном месте послужило тому, что современный Интернет оказался совершенно не предназначеным для пользователей с ограниченными возможностями, для которых визуальное оформление веб-сайтов создает существенные препятствия для чтения информации. Более того отображение веб-страниц на устройствах с нестандартными размерами экрана (смартфоны) вместо переключения таблицы стилей требует вдобавок переработки всей структуры веб-документа, что очень неудобно.

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

Резюмируя — заданная HTML’ом DOM-модель веб-страницы должна восприниматься в качестве базы данных с содрежанием и структурой веб-документа и ни в коем случае не должна меняться в зависимости от изменения стилистических элементов на странице.

habr.com

Всегда ли нужна «резиновая» верстка? / Habr

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

На написание этого текста меня натолкнули постоянные споры, возникающие за время моей практики как веб-дизайнера. Собственно, первый раз мне пришлось столкнуться с «резиновыми сайтами» благодаря прихоти заказчика. Когда дизайн проекта был полностью готов, а сам сайт сверстан и подключен, заказчик спросил: «А почему он не растягивается?». Было это достаточно давно, но этот вопрос я слышу примерно раз в 4-5 месяцев. О «резиновой» верстке сайтов говорили и писали много. Говорили что она обязательна, и наоборот, что использование ее ошибка. Однозначно, были причины возникновения резиновости. И утверждать, что использование этой технологии на 99% ошибочно, однозначно нельзя. Любую технологию нужно применить, если она нужна. Я хочу очертить примерную границу применения резиновой верстки.

ЗАРОЖДЕНИЕ.

Любой дизайн это решение задач: эстетика, которая должна сработать нужным образом; удобство, которое должно навести на определенный метод использования или расширить стандартные возможности и т.п. Верстка, это один из этапов реализации веб-проекта, который проектируется непосредственно дизайнером. Выбирая тип верстки, дизайнер решает конкретные задачи, давайте попробуем понять — какие именно.

Чтобы понять задачи, решаемые резиновостью, стоит начать с истории её возникновения.

Первые сайты с подстраивающейся к размеру экрана версткой (резиновые) появились в период исчезновения мониторов с разрешением 640-480, активного использования разрешения 800-600 и первыми представителями 1024-768. Стоит признать, что площадь 640-480 и 800-600 мала для полноценного восприятия информации. А еще и навигация, и банер повесить надо (в те времена они были эффективнее). Растянув наш сайт в 1,6 раза по горизонтали, мы хоть как то приблизим формат сайта к хорошо воспринимаемому всеми формату листа А4. Сделаем тем самым огромное одолжение владельцам новеньких дорогих «больших» мониторов. Тем более, что мы растягиваем не только элементы по странице, но еще и текстовые блоки, которые уменьшаются по высоте, а это иногда убирает скрол! (а это пикселей 30!). Выгоды очевидны!

Получается, главная задача «резиновости» — дать необходимое пространство для контента, не ущемив достоинство владельцев стареньких мониторов.

Так как мы рассматриваем «резиновую» верстку в наше время, стоит обратить внимание на современный парк мониторов. а это (если забыть про нетбуки) от 1024 х 768 и до 2048 х 1152. Математически, мы получаем разницу в 2 раза, что не намного больше чем лет 10 тому назад.

Соотношение размеров между большими и маленькими мониторами почти сохранилось, сохранились ли ставящиеся перед дизайнерами задачи?

КАК ОНО РАБОТАЕТ.

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

1. Текстовые блоки хорошо поддаются растяжению по горизонтали. Они несут, порою, до 90% всей информации на сайте (а значит, их много! Есть что тянуть!). Но бесконечно растягивать их просто нельзя. Наше внимание имеет определенный запас «усидчивости». Если текстовая строка становится слишком длинной, нам просто тяжело ее читать — мы устаем. Недаром, в газетах используют ограничения по ширине текстового блока примерно в 50-55 знаков, а это, даже при увеличенном межбуквенном расстоянии, меньше половины ширины листа А4. Вообще, самой оптимальной длинной строки для быстрого и удобного чтения считается 45 знаков. Минимум тоже есть, это порядка 20-25 знаков. То есть, текстовый блок может быть увеличен от минимума до удобочитаемого максимума не более чем в 2 раза. Разбивать один текст на несколько колонок, как в газете, не рекомендуется. Потому что когда мы просматриваем текст, скролируя сверху вниз, возвращаться наверх в начало второй колонки будет крайне неудобно. Исходя из этого, если текст это основной блок страницы, то мы не можем ее растягивать даже до 900 px! А лучше меньше.

2. Расстояние между различными элементами сайта. При должном уровне навыков, эти области сайта поддаются масштабированию, казалось бы, без потерь. Но есть одно «Но». Дело в том, что «пустое пространство» это не просто «довесок» на страничке. Промежутки между блоками выполняют вполне конкретные задачи: разделяют, группируют схожие блоки, создают акцент на самом важном. Все эти задачи решаются разницей размеров пробелов. например, несколько блоков, разделенных небольшими промежутками, визуально воспринимаются как родственные, или имеющие одинаковую ценность. Блок, имеющих вокруг себя много свободного пространства однозначно ценный, возможно, главный на странице.

Если исходить только из разницы размеров блоков, то совершенно не имеет значение насколько мы их растянем, ведь они будут растягиваться пропорционально. Вроде бы, они все должны справляться со своими задачами… Но тут появляется очередное «Но». Дело в том, что промежутки еще имеют и свой «характер». Возможно, кому-то, далекому от сферы дизайна, это покажется несущественным, но я напомню вам о работе танцора, музыканта, певца. Непрофессионал-танцор может выполнять те же движения что и мастер, музыкант-новичок будет играть по тем же нотам, певец будет петь ту же песню. Мы будем узнавать произведение, но мы скорее всего почувствуем разницу. Если сделать промежутки между родственными блоками в 5 мм, они будут восприниматься как родственные, но если мы их растянем до 10-15 мм, то они начнут безвозвратно разделять «родственников». И ситуацию не спасет даже то, что пропорционально это самый маленький на странице промежуток.

Характер «пустых мест» может влиять и на общий характер страницы. Например, резиновые сайты частенько разрушают требуемое ощущение выверенности, стабильности и надежности. Я не стану сильно вдаваться в этот вопрос, просто потому, что это достаточно специфическая тема, которая хорошо освещается в литературе посвященной дизайну, композиции и изобразительному искусству.

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

4. Растровые картинки при растяжении дают искажения и муар при растягивании в одном направлении. Но можно изменять размер всего изображения, сохраняя пропорции. Либо можно менять размер «окна» картинки, сохраняя ее истинный размер. Увеличивать размер картинок нужно в случаях когда эти картинки нужно показывать в максимально большом размере, например в фотосервисах, в портфолио дизайнеров и фотографов… Однако, так или иначе, это сопряжено с дополнительными техническими усложнениями.

Видео. Могу ошибаться, но мне еще не приходилось встречать варианты простого масштабирования окна потокового ролика (в любом случае, это ресурсоемкая технология). Как правило, это окошко реального размера + возможность посмотреть ролик на весь экран. Но, наши сети пока далеки от идеала, и говорить о тотальном переходе в видео-формат не приходится.

Виджеты, навигация. Как правило, это элементы на которые направлено достаточно много внимания пользователя. Их внутренние компоненты, конечно же поддаются масштабированию. Но изменение выверенных дизайнером пропорций часто ведет к потере читаемости этих компонентов. Эти компоненты вообще стоит рассматривать в отдельности каждый случай, главное не забывать об опасности визуально «развалить» компонент. Ну и как всегда, требуются технологические ухищрения.

Кроме чисто художественных аспектов и законов восприятия информации, есть еще проблема «уставания» нашего глаза. Отчасти, это затрагивается выше в санитарных нормах для текстовых блоков. Не буду уходить в цифры. Простой пример: мало кто станет вешать на рабочем месте лист с важной информацией по текущему проекту за спину или сбоку от себя, частенько наброски, схемы и записки вообще клеят в районе монитора. Чем дальше мы бегаем взглядом, тем быстрее мы устаем. В масштабах экрана это кажется менее существенным. Но чтобы рассмотреть 2 разные картинки у левого и правого края 22 дюймового монитора, нам уже приходиться чуть повернуть голову, мониторы уже стали слишком большие для движения только лишь глазами. Через 4-5 часов сетевого серфинга у пользователя достаточно расфокусируется внимание, чтобы на вашем растянутом сайте ему стало трудно найти нужную информацию.

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

ЧТО ИМЕЕМ.

Дизайнеры по прошествии 10 лет все еще решают проблему нехватки рабочего пространства, и решают ее использованием «резиновой верстки», растягивающей все имеющиеся материалы по экрану монитора. Но наши мониторы давно переступили черту нормального восприятия! С этим можно не соглашаться просматривая очередное продолжение саги «STAR WARS» или играя в одноименный шутер. Картинка фильма и игры похожи на то, что мы видим нашими глазами в жизни. В нем очень много лишней информации, даже максимально эффективный угол нашего зрения всего 5°. За счет уменьшенного угла мозг разгружается от лишней информации. Нас не интересуют все детали, а лишь картина в общем. А невоспринимаемое пространство создает лишь дополнительный «антураж» — зеленая масса леса, толпа… Прибавьте к этому факт, о том что лучше всего мы воспринимаем именно центр экрана, и нам крайне неудобно изучать что либо на краях… А страничка сайта это детали, тексты, анонсы и навигация. Да, можно заставить искать человека это все по большому экрану. И как правило, он находит. Человек может читать текст даже в нижнем правом углу экрана 9-м кеглем. Только это происходит ценой дополнительных усилий зрения и внимания, хоть и небольших на первый взгляд. Присоедините к этому лишние часы работы верстальщика и дизайнера на разработку этого типа верстки.

Стоит заметить, очень многие дизайнеры пришли к выводу, что тянуть бесконечно контент нельзя, точно так же как и сжимать. Понимание этого породило «полу-резиновость». Если человеку достаточно комфортно воспринимать информацию на 900 px ширины (немного больше ширины листа А4), то ради решения какой задачи ее растягивать до 1100 px? И это при том, что даже минимальное разрешение современных мониторов укладывается в ширину 1024 px, а значит, и сжимать не придется.

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

Получив «заряд бодрости» конца 20 века, когда проблемы с площадью действительно были, дизайнеры продолжают решать несуществующие проблемы, а уже «образованные» заказчики требовать эти проблемы решать.

Частенько можно услышать про «законы веба», вроде как они не имеют ничего общего с типографическими правилами. Однако, главное в типографии — подача печатного текста. А до тех пор, пока видео и звук не заменили текст (который составляет гораздо больше 50% контента сайтов), а мы все еще видим биологическими глазами, было бы глупо отказываться от исследований и опыта, накопленного за несколько сотен лет типографии. Тем более, что текст на мониторах из-за низкого разрешения гораздо хуже печатного (72 dpi против 200 dpi и более), да и сами мониторы не способствуют отдыху глаз.

Для тех, кто сомневается в реальности проблем восприятия, предлагаю посмотреть 4 варианта размещения текстов тут: nano.a5.ru

ОПРАВДАНИЕ.

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

Есть еще один случай использования масштабируемой верстки, который не требует каких либо аргументов для права на существования — резиновость, как художественный прием. Но в этом случае один знаменитый совет приобретает новую форму:

Делайте только резиновые сайты = Делайте только сайты красного (зеленого, синего, оранжевого, и т.д.) цвета!

P.S.
Думаю, многим приходилось натыкаться на фразы типа: «Хороший дизайнер должен уметь делать правильную резину!». На мой взгляд, куда важнее умение правильно выбрать: резина или нет?

habr.com

Несколько правил грамотной верстки, которую «любят» поисковые системы / Sandbox / Habr

Материалов по SEO верстке в интернете огромное количество, поэтому иногда даже не знаешь, куда лучше пойти первым делом. Я думаю, что если сайт не будет оптимизироваться изнутри, то оптимизация внешняя почти не имеет смысла — эффект будет намного ниже. Я бы хотел рассказать вам о нескольких правилах грамотной верстки, поставив на них вопросы:

• Что такое SEO-вёрстка?
• В чём особенность SEO-вёрстки?
• Вёрстка должна быть кроссбраузерной?
• Какие теги полезны для SEO?

Итак, начнем. Первое — что такое seo-верстка (далее — просто верстка)?

Это вёрстка кода страницы, которая своими элементами помогает продвижению запросов на целевой странице.

Второе — в чём особенность вёрстки?

Вся особенность в том, чтобы в теле кода страницы как можно выше разместить контентную часть и правильно её подать поисковой системе. Пользователь, как правило, приходит за информацией, а не за кучей графики.

Третье, — верстка должна быть кроссбраузерной?

Ответ однозначен — да. Самый лучшее — кроссбраузерность IE 6+, хотя и сейчас это не так важно, т.к. все переходят на новые браузеры. Т.к. Internet Explorer самый проблемный, то остальные браузеры можно и не рассматривать. Будьте уверены, если кроссбраузерность выше ie 7, то она в других браузерах будет выглядеть хорошо (за исключением использования префиксов webkit-, moz- в css).

Далее — какие теги полезны для SEO?

• Заголовок должен быть или h2 или h3, подзаголовки должны быть не B или STRONG, а h4.
• У картинок обязателен тег ALT.
• Желательно использовать мета теги: meta name=«keywords», meta name=«description».
• Все стили лучше помещайте в отдельный файл (еще лучше, чтобы файл был в папке).
• Скрипты js лучше подгружать ближе к центру или концу страницы. (Ещё можно задать в jQuery, чтоб активировались только при полной загрузке).
• Не стоит увлекаться на страницах тегами B или STRONG. (для поисковиков strong важнее b)

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

habr.com