9 сентября 2009 в 1:44
Этой статьей я хочу начать небольшой холивар обсуждение идеального документа, описывающего специфику верстки под Друпал. Эти пункты использую я лично при заказе верстки для описания именно технических особенностей верстки. Еще раз повторяю, этот документ описывает лишь особенности верстки под друпал, а не верстки как таковой, поэтому все общие замечания можете пропускать.
Дополняйте список в комментах, я буду обновлять статью по ходу дела.
Общее
1. Не следует использовать лишние паразитные теги или символы для оформления границ, буллетов списков и т.п.
2. В качестве JS-библиотеки можно использовать только jQuery 1.2.6.
Меню, списки
1. Меню следует делать с использованием тегов ul-li-a, или ul-li-ul-li-...-a для вложенных меню.
2. В любых списках (меню включительно) разделители следует делать только с помощью CSS (напр., без использования "|" внутри HTML)
Формы
1. Форма должна быть заключена в теги <form id="some-form-id"><div>....</div></form>.
2. По возможности, элементы формы должны оборачиваться в теги в виде <div clas="form-item input-id-wrapper"><label>Label: <input id="input-id" /></label></div>
3. По возможности, элементы формы должны идти один за одним без лишних тегов.
4. Если поля группируются, то в качестве контейнеров должны быть теги <fieldset> (с подписью в виде вложенного <legend>)
5. Для кнопок должен использоваться исключительно <input type="submit">.
6. Разные типы полей форм должны иметь разные классы из списка:
<input class="form-text" type="text"><textarea class="form-textarea" ...<input type="checkbox" class="form-checkbox" /><input type="radio" class="form-radio" /><select class="form-select" ...<input type="file" class="form-file" /><input class="form-submit" type="submit">-
<fieldset class="collapsible collapsed">
<legend class="collapse-processed">
<a href="#">Name</a>
</legend>
<div class="fieldset-wrapper">
...
</div>
</fieldset>
Блоки
1. Существует понятие региона, в который будут помещаться блоки. Внутри этого региона, разметку каждого блока по-возможности стоит делать однотипной.
2. Рекомендуется минимизировать количество регионов на странице. Кроме того, рекомендуется использовать одни и те же регионы для остальных макетов. Например, если в одном макете есть регион для сайдбара, в других макетах этот регион и его внутренности должны подчиняться общим правилам.
Контент
1. Контентные блоки (внутри основного контентного региона) следует отделять друг от друга. Разные контентные блоки не могут пересекаться друг с другом.
Еще по теме:
Комментарии
А чем плох
<button>, который по спецификацию вроде как более правильный?Если у последнего элемента нет разделителя, то как лучше это делать в друпале: задавать определённый id или class или ещё как?
Id - это уникальный элемент на странице, класс - это несколько элементов, поэтому правильней класс
Речь идёт про последний (читай единственный) элемент, так что подходит и class, и id.
Но вот что рекомендуют разработчики друпала?
В общем-то это всё и так очевидно, и за исключением jQuery применимо к любой верстке. Если вкратце описать всё выше сказанное: пишите кратко, логично, правильно.
Я бы особое внимание уделил типографике — большинство даже хороших верстальщиков ею совершенно не занимаются. Для этого у меня есть html — шаблон с очень сложно оформленным текстом — который отдается дизайнеру и верстальщику.
Если верстальщик постоянный — возможно предложить ему в качестве названий id и class использовать классы от темы Zen. тогда переделывать верстку в тему будет ещё проще:)
По типографике: «html-шаблон» пишется через дефис, а не через тире. И в конце предложения ставится точка, а не двоеточие и скобка.
Виноват
А я бы еще добавил, что в качестве имен классов нельзя использовать стандартные друпальские стили и классы.
Почему нельзя?
На мой взгляд даже нужно использовать (переопределять) стандартное оформление своим...
Таким переопределением можно сделать админку совершенно нечитабельной. Одно неловкое движение и вся админка разлезлась по странице.
У меня, вроде, нечто подобное было:
http://drupal.ru/node/9661
раздел "Theming" 25-й пункт
Наверное, не
<label>, а<caption>, все же.Все же правильнее использовать тег
<legend>, тк тег<caption>является заголовком таблицыВидимо, то была опечатка, потому что в верстке юзается именно legend:
<legend class="collapse-processed">
<a href="#">Name</a>
</legend>
<div class="fieldset-wrapper">
...
</div>
</fieldset>
Если уж объеденять поля в fieldset, то надо юзать полный вариант.
Сегодня после часовых раздумий появилась идея, собрать административную страничку с формой, списками dd и может еще чем, и с подключенными стандартными стилями. Все это передавать верстальщику при заказе с условием, что эта форма должна или остаться такой же, или улучшиться при подключении стилей верстки.
Это все клево, но отдаляется от темы, которой посвящен топик.
В документе не хватает ответа на вопрос по каждому пункту-
почему так
И следующего за всем просветления -
так вот почему почти все друпал сайты как близнецы.
И главного, на мой взгляд блока,
как сделать так чтобы было иначе.
Я бы еще добавил требование по поводу меню. Думаю, многие юзают http://drupal.org/project/nice_menus. Очень он удобен для выпадающих меню. Было бы неплохо верстать менюхи эти с учетом классов данного модуля.
ЗЫ: стандартная трабла для меня: сверстал человек старницу, подкинул крутой плагин для выпадающего меню и передал девелоперу. И вот тут начинается проблема -- что с этим меню делать.
Полностью поддерживаю, но часто попадаются вредные дизайнеры, которые вынуждают вводить лишние теги. Не стоит сильно пинать верстальщика за такое, ведь в друпале потрясающие возможности по темизации. А вообще, считаю, программист должен подстраивать движок под верстку, а не наоборот. Потому, что код, выдаваемый друпалом, - избыточный и часто мешает
Библиотека jQuery прекрасно сочетается с другими библиотеками.
Используйте следующую конструкцию:
// тело функций jQuery
})(jQuery);
А при необходимости есть функция
Возможно, многим будет полезно узнать про свойство
content, и как заставить его работать в ие.http://drupal.ru/node/32884>> Библиотека jQuery прекрасно сочетается с другими библиотеками.
В принципе, да. Но ИМХО лучше юзать один инструмент, а не тащить в проект любую красивую штуковину, написанную с помощью других библиотек или на чистом javascript. Раньше очень часто приходилось бороться с "чем-то", написанном на "чем-то". Поддерживать и править баги в подобных наработках бывает крайне тяжело. Человек, к примеру, знает http://mootools.net, но остальная команда его не знает. На поддержку такого кода потом тратится куча времени. Поэтому теперь одно из требований -- jQuery и использование плагинов, а не изобретание велосипедов.
Ребят. А может перестанем суетиться вокруг культов и церемоний и просто пойдем делать отличные сайты? Как говорил Чикуенок "Интернет вырос и перестал быть местом тусовки гиков. Юзерам пофигу, как оно там сверстано". Суетитесь вокруг мелочей. А когда я в Сообществе подымал вопросы юзабилити и стандартов поведения сайтов, меня сочли за человека, которому делать нефиг.
Последних может быть несколько на странице.
Мы не юзеры и нам не пофигу.
Дополню: класс для меню следует прописывать во внешнем контейнере.
Неправильно:
Правильно:
Конструкция типа
<?php print theme('links', $links, array('class' => 'mainmenu')); ?>
породит именно
<li>...</li>
</ul>
Почему обязательно во внешнем контейнере? Это глупо даже без Drupal'а. А вот конструкция, предложенная предыдущим оратором еще и first и last классы проставит.
По теме: я в своем проекте подумываю вообще снести стандартные CSS Drupal'а из подключения. Слишком много !important получается, если их не убрать.
2 Дэн
Хватит делать сайты для своего перфекционизма и "чтобы пацанам показать"! Делайте сайты для людей! Простых, тупых, умных. Для всех. Им по барабану на валидность кода. Валидный код и прочие буржуазные предрассудки нужны менеджерам, чтобы принять работу технолога, ибо сами они нихрена зачастую не шарят.
Вот только не нужно оправдывать криворукость разработчиков. Я и сам иногда делаю сайты лишь бы сдать (с ошибками в верстке и без оптимизации кода), но мне за это стыдно. Вы же из этого делаете правило.
2Cherenkevich
Большинству водителей по барабану, как сделана и работает коробка передач, главное: "автомат" или "механика". И что? Пусть инженеры забьют на качество, равномерный износ и т.д., главное - "шоб ехало"?
Этот топик, кстати, не про валидность, а про то какие требования ставить верстальщику, дабы облегчить себе работу по темизации.
Хотя про валидность всё таки скажу, ибо она этому топику не чужда.
Вёрстка, которая выходит из под рук верстальщика должна быть валидной по нескольким причинам:
1. Проверка. Если человек разбирается в вёрстке, он сможет сделать её валидной, если не разбирается - зачем мне его работа?
2. Если вёрстка невалида, то скорее всего верстальщик и о семантической вёрстке не думал, а значить будет разгребать тэги, которые использовались не по назначению.
3. Продолжение второго пункта. HTML - это язык разметки и есть чёткие правила, какие тэги для чего используются и поисковики, при разборе документа этим правилам следуют. Если в структуре HTML-документа будут ошибки, возможна неверная индексация. Поэтому при наличии ошибок валидатора нужно смотреть что они из себя представляют, толи это тэг не закрытый, то ли использование alt в теге a, то ли вообще это совокупность ошибок, на которых вся вёрстка стоит и исправление любой вызовет перекос всего макета. На это нужно время. Лишнего у меня нет, а у Вас?
4. Самое главное. Уважение. Когда Вы пишите письмо, у Вас автоматически проверяется орфография. Ибо писать кому-то с ошибками, значит не уважать себя и респондента. Если мне сдают вёрстку с ошибками, я воспринимаю это как фразу "Хай чел! Вот те, шо просил!" в деловом письме. Это просто неуместно. Иногда, смешно, да, но редко - не все умеют хорошо шутить.
Вопрос немного не по теме: а не потребовать ли у разработчиков Views чтобы они убрали излишний код из шаблонов? Реально бесит это награмождение.
Это уже оффтоп, но я все же отвечу.
В моей практике, оправданная невалидность встречалась всего раз. Если верстальщик ее допускает, то должен хотя бы иметь чем обосновать. В остальных случаях валидность — маст хев.
Лишние теги из шаблонов выкидывать не следует. Вам они ни к чему, но для тех кто умеет использовать только CSS и понятия не имеет о темизации в друпале, они хорошее подспорье (а таких людей много). Все лишнее из шаблонов можно выбросить самому. А чтобы не выбрасывать тыщу раз для каждого проекта, создайте базовую тему со своими чистыми шаблонами и используйте ее в проектах.
И да, эта тема не про валидность, а про то какие требования ставить верстальщику, дабы облегчить себе работу по темизации.
Добавил шестой пункт в раздел форм.
Хм, я просто включаю гарланд для админики и не парюсь
Подскажите, а как можно обернуть форму для комментариев в
<fieldset class="collapsible collapsed">(D5)Так нужно еще и верстку специально под Друпал делать!?
Так это же искуссвто в верстке пропадает.
А можно верстку оставить, а функционал изменить? Много на это времени нужно?