Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 296
Обычно стили не структурирую, но дописываю родительский элемент, и сортирую тоже по ним. Пример:
В одну строку написано для наглядности, обычно разворачиваю
#header span{color:white;}
#header .button{margin:5px; padding:5px;}
#content a{color:blue;}
#footer .copyright {font-size:80%;}В одну строку написано для наглядности, обычно разворачиваю
Имелось ввиду, ближайший уникальный родительский элемент. Если в div#header содержится div#menu, то такая запись
#menu a{font-weight:bold;}лучше чем#header a{font-weight:bold;}и даже лучше чем#header #menu a{font-weight:bold;}div#menu я указал для примера. Точно также я редко в стилях указываю к tagName, использовать классы действительно лучше, так как привязываешь события к элементам с соответсвующим классом, и даже если div.menu_item вдруг станет li.menu_item, в скриптах ничего менять не придется, а в стилях разве что самую малость.
Ну как сказать, гарантированно уникальные элементы, в общем-то тоже неплохо с id живут (#header, #content, #footer). Зрительно быстрее распознаются.
Или вдруг, вам, к примеру, потребуется еще один тэг body. Не смейтесь, я такое лично видел, штук пять на странице было.
Не должно быть такого «вдруг», каждый элемент изначально уникален или же нет. Если уникален — присваивайте id, не уникален — класс.
Все равно не могу представить ситуацию, когда нужно клонировать #content, #header или #footer. Приведите пример
Не должно быть такого «вдруг», каждый элемент изначально уникален или же нет. Если уникален — присваивайте id, не уникален — класс.
Все равно не могу представить ситуацию, когда нужно клонировать #content, #header или #footer. Приведите пример
конструктор шаблонов, где нужно внутри конструктора рисовать превью страницы
Вы как с луны свалились. «Вёрстка независимыми блоками» вам ни о чём не говорит?
vitaly.harisov.name/article/independent-blocks.html
vitaly.harisov.name/article/independent-blocks.html
обе записи плохи с точки зрения производительности, лучше всего
.header_menu_link {font-weight:bold}
или на худой конец
.menu .link{font-weight:bold}
.header_menu_link {font-weight:bold}
или на худой конец
.menu .link{font-weight:bold}
С точки зрения производительности, очевидно, лучше так и только так:
#id {}
#id {}
спасибо! все правильно
все по делу
по пункту 2:
самим верстать нужно, а не искать за гроши левого фрилансера, который накуярит непонятно чего перед дедлайном.
это проблема мелких веб-студий, которые экономят на верстке и это сказывается потом на их имидже
самим верстать нужно, а не искать за гроши левого фрилансера, который накуярит непонятно чего перед дедлайном.
это проблема мелких веб-студий, которые экономят на верстке и это сказывается потом на их имидже
На самом деле если есть уже проверенный фрилансер-верстальщик, то для небольшого объема работ держать своего не вижу смысла.
Либо юзать p2h.com или вот наш аналог markuper.com
markuper.com капец, разработчики интерфейсов…
зашел — почитал, стало интересно, а где прайс? где хоть какието контакты и хоть что то кроме текста? О__О
зашел — почитал, стало интересно, а где прайс? где хоть какието контакты и хоть что то кроме текста? О__О
Если чесно, это я так себя пропиарил — етно Мы. Занялись таким делом, даже ка кто на хабре писали. Все только руки не доходят сделать калькулятор на сайт да портфолио повесить, так как хотим сделать все очень красиво, и чисто с точки хрения кода — сами думаю понимаете:). Впринципе если инетерсно по прайсу, в личку напишите, я Вас проконсультирую. Мало ли когда пригодиться.
как же вы зарабатываете деньги, если собственным сайтом отпугиваете клиентов?
В основном за счет личных связей с промо студиями(они обычно работают с флэшом), но иногда у них бывают заказы на обычные html сайты. Вот тут и Мы :)))) А что конкретно Вас отпугивает?
Дак отпугивает отсутствие тех же самих «контактов» и «портфолио»
нет контактов и прайса, хотелось бы портфолио…
и еще сайт начисто убивает Chrome и Safari
— вообщем — низкий класс
и еще сайт начисто убивает Chrome и Safari
— вообщем — низкий класс
Хотелось бы узнать какого рода убийство происходит. Так как мы не заметили убийства(с нашей точки зрения), сейчас даже заходил с htc desire(webkit)- все было прекрасно. А как профи посомтрите верстку(сам код), тоже интерсен Ваш коммент. Заранее спасибо.
"(клиентские стороны богатых веб-приложений)"
Фраза убила насмерть. Богатые веб-приложения, ага.
Фраза убила насмерть. Богатые веб-приложения, ага.
Не забудьте еще за вычитку текста, когда дойдут руки доделать сайт: там немало очепяток и других помарок — лексических и орфографических.
Это всегда вопрос цены. Если внешний верстальщик выдаст тот же результат за меньшие деньги, в чём может быть резон использования своего верстальщика?
Ещё раз повторюсь: при «том же результате». Доступность, загруженность, очное общение — как раз те вещи, которые позволяют повысить качество результата. Но они же, волей-неволей, повышают реальную стоимость работы. Ибо это и амортизация оборудования и арендная плата за помещение и налоговые/пенсионные выплаты по зарплате и необходимость оплаты времени простоя и т.д. и т.п.
Короче, оценивается соотношение цена/качество.
Иногда получается реально дешевле в финале иметь несколько фрилансеров на «чёрной работе» и, например, одного специалиста, который всё сведёт воедино, отшлифует, подправит, если надо. Говоря про дешевизну в финале имею в виду и расходы на подгонку к рабочему варианту получаемый от фрилансеров результат. Очень, очень часто бывает выгоднее использовать внешних разработчиков.
И именно для того, чтобы их использование было максимально эффективным (читай — потребовались бы минимальные усилия для допиливания/доработки) и нужны эти правила.
Короче, оценивается соотношение цена/качество.
Иногда получается реально дешевле в финале иметь несколько фрилансеров на «чёрной работе» и, например, одного специалиста, который всё сведёт воедино, отшлифует, подправит, если надо. Говоря про дешевизну в финале имею в виду и расходы на подгонку к рабочему варианту получаемый от фрилансеров результат. Очень, очень часто бывает выгоднее использовать внешних разработчиков.
И именно для того, чтобы их использование было максимально эффективным (читай — потребовались бы минимальные усилия для допиливания/доработки) и нужны эти правила.
Ну на самом деле Вы посмотрите на какое сообщение я отвечал и к чему именно относились мои возражения :) Я против категоричного утверждения, что верстать надо только самим а не искать более дешёвый вариант. Имхо практически любой девелопмент — часть некоего коммерческого проекта. А бизнес — он стремится снижать цену и повышать прафит.
Так что если удастся использовать более дешёвую рабочую силу, застраховавшись от рисков (хотя бы при помощи правил или использования БЭМ) — то так и стоит поступить.
ЗЫ: спасибо за ссылку, кстати, любопытненько.
Так что если удастся использовать более дешёвую рабочую силу, застраховавшись от рисков (хотя бы при помощи правил или использования БЭМ) — то так и стоит поступить.
ЗЫ: спасибо за ссылку, кстати, любопытненько.
Мелкие веб-студии как раз обычно сами верстают, а проблема аутсорс-фрилансеров – это проблема студий со штатом 20+ человек, когда поток проектов большой, и внутренних ресурсов не всегда хватает по дедлайнам – гораздо выгоднее сформировать аутсорс-команду и сливать работу им, а не пытаться вывозить всё на себе.
По первому пункту — сайт должен РАБОТАТЬ в IE6, но никак не выглядеть в нем так же, как в других браузерах. Пользователь хочет красоту — пусть обновляет IE или устанавливает другой браузер.
Поддерживаю. Тоже не правлю неправильные отступы и выравнивания в IE6, только ошибки скрипта и редкие случаи, когда элемент страницы вообще недоступен (наехало что-то сверху, селекты любят так делать)
Хотя, как я убедился, многие вещи без проблем дожили до IE8, да и еще несколько прибавилось.
Хотя, как я убедился, многие вещи без проблем дожили до IE8, да и еще несколько прибавилось.
Это уже решать заказчику. Конечно, не обращая внимания на IE6, верстать на много приятнее и лучше, в том числе и для современных браузеров. Но бизнес–цели, зачастую, важнее.
Да, давно пора уже прекратить поддержку этого старья!
IE6 ещё используют верстальщики, считающие, что есть пользователи, использующие IE6 :)
IE6 ещё используют верстальщики, считающие, что есть пользователи, использующие IE6 :)
+ старайтесь не использовать кириллические комментарии в CSS. чревато, особенно при дальнейшем переходе проекта на utf ;)
Предлагаю обсудить этот момент.
Если кодировка CSS файла такая же, как HTML и в теге link для подключения CSS она тоже задана правильно атрибутом charset, то я так понимаю, никаких проблем не возникает.
Возможно стоит лучше в пункте 16, где речь идет о кодировках, упомянуть об атрибуте charset тега link?
Если кодировка CSS файла такая же, как HTML и в теге link для подключения CSS она тоже задана правильно атрибутом charset, то я так понимаю, никаких проблем не возникает.
Возможно стоит лучше в пункте 16, где речь идет о кодировках, упомянуть об атрибуте charset тега link?
Старайтесь не переводить проекты на UTF, а сразу делать в нём.
Бред.
спасибо, полезно да же для себя
Я бы добавил ещё обязательную проверку на CSS и HTML валидаторе куда-нибудь в начало, чтобы не было забытых обязательных атрибутов у тегов и просто неподдерживаемого синтаксиса. Для большинства проектов — настоятельная рекомендация полной валидности, для остальных — минимальное количество ошибок, и, как и написано у вас в последнем пункте, оправданных ошибок.
А так всё очень по делу, спасибо!
А так всё очень по делу, спасибо!
Всё верно написано. У нас даже есть своя внутренняя документация, чтобы все верстальщики писали однотипно.
Забавно, мы так и делаем :) По умолчанию
Да-да, каюсь )
Привет конкурентам:)))))
А минусы от конкурентов? :))))))
Ребята, вы молодцы, чесно. Очень понравился дизайн вашего сайта — легкий, что надо. Удивили Ваши цены, у нас в среднем стоит 4000р макет за главную. Правда я так понял вы работаете как физические лица, а мы как юрики, отсюда и наши цены. Название себе прикольное выбрали, мы тоже долго думали:))) так что впринципе понимаем некий труд. Из минусов, довольно слабенький калькулятор у Вас, а мы сейчас какраз свой доделываем. Я вот пока писал коммент подумла, что с Вашими ценами, мы можем работать как партнеры:))))
Пишите в личку :)
А калькулятор, лично я за простоту, свои задачи он решает.
Хотя я думаю, пару пунктов мы добавим.
А калькулятор, лично я за простоту, свои задачи он решает.
Хотя я думаю, пару пунктов мы добавим.
4тыр за верстку главной???
черт возьми, а я все ломаю голову, сколько же за верстку брать…
не, ну у нас столько точно не заплатят…
но вообще — дали повод задуматься)
черт возьми, а я все ломаю голову, сколько же за верстку брать…
не, ну у нас столько точно не заплатят…
но вообще — дали повод задуматься)
Ну я буду чесным, среди своих думюа не стоит скрывать:))) Тут вс епросто если ты рабоатешь как Юр лицо, тебе ндао платить за офис и бугалетра как минимум плюс зп верстальщикам + зп себе, любой бизнес если не имеет 100% накрутки не будет успешен, либо иметь огромный оборот(чего у нас точно нет). Поэтому в среднем верстальщик получает около 2000 ща униклаьный макет, а вообще то даже и все 2500, мы своих Верстаков не обижаем.
да эт я все понимаю, сам учредитель студии)
просто у нас профиль по-ширше, и студия не берет такие мелкие заказы на всякую верстку.
а мне вот иногда предлагают поверстать на досуге, и я ломаю себе голову, сколько за это брать…
опыта много, знаю что сверстать могу любой макет (ну разве что не какой-то вообще нереальный), все валидно и кросбраузерно (кроме ИЕ6, манал я его, нервы дороже. хотя, конечно, и под него можно, но за отдельные деньги) и т.д. и т.п.
но вот во сколько все это оценить — это проблема…
просто у нас профиль по-ширше, и студия не берет такие мелкие заказы на всякую верстку.
а мне вот иногда предлагают поверстать на досуге, и я ломаю себе голову, сколько за это брать…
опыта много, знаю что сверстать могу любой макет (ну разве что не какой-то вообще нереальный), все валидно и кросбраузерно (кроме ИЕ6, манал я его, нервы дороже. хотя, конечно, и под него можно, но за отдельные деньги) и т.д. и т.п.
но вот во сколько все это оценить — это проблема…
А по вашему сайту, тяжеловат. Да и дизайн если честно, так себе, если быть конструктивным. В Хроме действительно тяжеловато работает.
Я не поленился, сделал карту кликов для главной страницы:
Скажите, почему самый привлекающий внимание элемент оформления — простая статичная картинка. Хот-бы интерактив какой-то сделали.
Скажите, почему самый привлекающий внимание элемент оформления — простая статичная картинка. Хот-бы интерактив какой-то сделали.
оп. а подскажите плиз, как сие сделать?
Этот вопрос мне задавали тысячу раз если честно :)
На самом деле интерактив там будет. С цветом и типом фона.
На самом деле интерактив там будет. С цветом и типом фона.
у вас если кликнуть в пункт меню, ползунок прыгает к нему.
логично было бы сделать, если ползунок передвинуть к пункту меню, то он кликается.
а то сейчас болтается без дела, как говно в ополонке… все его дергают, а толку никакого…
логично было бы сделать, если ползунок передвинуть к пункту меню, то он кликается.
а то сейчас болтается без дела, как говно в ополонке… все его дергают, а толку никакого…
Сделайте там на каком-то небольшом участке пасхалку в виде купона на скидку. Крутишь эту штуку и в какой-то точке всплывает окошко: «Нашему клиенту пытливому от разработчиков благодарных великая скидка предоставляется!»
Для пункта 15 отлично подходит система контроля версий, которую, правда, использовала лишь одна контора, с которой я работал.
Как по мне, оптимизация изображений — вообще очень важная составляющая верстки. Понимать, когда сохранять в jpg (и до какой степени его сжимать), когда в png-8 или png-24 — значит, сохранять драгоценные килобайты странички. Веб-страничка — как девушка, большой вес должен быть чем-то оправдан.
По пункту 20 я бы не согласился. Вставлять элемент формы внутрь тега label вполне допустимо и не нарушает стандартов, более того, позволяет избавиться от атрибута for и, как следствие, атрибута id у элемента формы.
То что вставка элементов input внутрь label позволяет избавиться от for — не знал, спасибо.
В принципе, как вариант, можно делать и так. Но это немного ограничивает дальнейшую свободу в стилизации форм, да и при табличной верстке форм (от которой все-таки желательно уходить) такой вариант неприменим.
В принципе, как вариант, можно делать и так. Но это немного ограничивает дальнейшую свободу в стилизации форм, да и при табличной верстке форм (от которой все-таки желательно уходить) такой вариант неприменим.
Сомневаюсь, что стоит нанимать верстальщика, которому нужно все это объяснять.
К сожалению, можно предположить, что если не объяснять, то у нас не будет появляться новых верстальщиков.
А старые достойные давно уже заняты делом :-)
А старые достойные давно уже заняты делом :-)
Пусть всяк верстальщика такого нанимает,
который понимает.
(подражание Козьме Пруткову)
который понимает.
Человек обычно идёт по пути наименьшего сопротивления. И верстальщик тоже может попытаться решить какие-то проблемы наиболее «простым» (читай быстрым) способом, даже если результат будет заведомо плох. Ибо если нигде не обговорено иное, то можно и «схалтурить». Например, структуризация CSS файлов — дело нужное для дальнейшего девелопмента, но не имеющее явного внешнего отображения. Потому, если сроки поджимают, а требование не сформулировано явно — его можно и не выполнять. Даже зная, что так сделать — не совсем правильно.
хороший список. правда в списке упоминаются все моменты высокого уровня. дополню из своего опыта:
— css классы должны быть в определенной иерархии. например нельзя использовать *{margin:0; padding:0}, можно #header *{margin:0; padding:0}. Таким образом мы избежим будущих коллизий при установки новых модулей.
— имена картинок должны быть в нижнем регистре, и без кириллицы, и без пробелов
— имена css классов должны быть в нижнем регистре, и без кириллицы, и без пробелов
— пункты навигации(меню, pager...) должны выделяться исключительно добавлением определенного класса в элемент. например: ".selected", ".hover"
— в тег «a» всегда должен входить тег «span», пример: <a href="/path/path/" class="ico_home"><span>Link</span></a>.
Нужно для контроля стиля всей ссылки и текста по отдельности. В примере указан случай навешивания иконки на ссылку, но подчеркивание должно быть только у текста
— фоновый цвет иконок должен быть прозрачным. Очень часто при незначительных изменениях дизайна, цвета иконки остаются без изменений.
— css классы должны быть в определенной иерархии. например нельзя использовать *{margin:0; padding:0}, можно #header *{margin:0; padding:0}. Таким образом мы избежим будущих коллизий при установки новых модулей.
— имена картинок должны быть в нижнем регистре, и без кириллицы, и без пробелов
— имена css классов должны быть в нижнем регистре, и без кириллицы, и без пробелов
— пункты навигации(меню, pager...) должны выделяться исключительно добавлением определенного класса в элемент. например: ".selected", ".hover"
— в тег «a» всегда должен входить тег «span», пример: <a href="/path/path/" class="ico_home"><span>Link</span></a>.
Нужно для контроля стиля всей ссылки и текста по отдельности. В примере указан случай навешивания иконки на ссылку, но подчеркивание должно быть только у текста
— фоновый цвет иконок должен быть прозрачным. Очень часто при незначительных изменениях дизайна, цвета иконки остаются без изменений.
Воздержитесь от использования *, заклинаю! Поиск элементов во многих браузерах идет спава налево, т.е. при записи #header * {...} сначала будут найдены все элементы DOM, а из них отсортируются все те, которые принадлежат #header. Представляете что будет с браузером на слабой машине при большом документе?
Спасибо за советы, но по большему счету рекомендации, которые вы предлагаете, могут быть использованы в качестве внутренних правил конкретной организации для штатных верстальщиков к примеру, а я старался писать о максимально общих моментах. Я вот не принуждаю верстальщиков использовать underscore вместо любимого горбатого регистра, т. к. не вижу для этого никаких объективных причин глобального характера. А вот внутри организации конечно же верстальщикам стоит договориться, как именовать классы.
Пункт про навигацию мне понравился больше всего.
Пункт про навигацию мне понравился больше всего.
«В примере указан случай навешивания иконки на ссылку, но подчеркивание должно быть только у текста»
a img { text-decoration: none; }
Кроме того, обязательно включать span в a неверно с идеологической точки зрения. Потому, что представление начинает диктовать семантику.
А подталкивает вас к этому, видимо, использование «звездочки».
a img { text-decoration: none; }
Кроме того, обязательно включать span в a неверно с идеологической точки зрения. Потому, что представление начинает диктовать семантику.
А подталкивает вас к этому, видимо, использование «звездочки».
иконка навешивается на «а» с помощью css. я не вижу в моем примере использования тега img. и вообще стараюсь использовать тег img как можно меньше. стараюсь делать дизайн макета по максимуму контролируемым при помощи css
согласен про a+span
иконку, думаю, лучше вешать на ссылку определенного класса через background без лишних элементов
иконку, думаю, лучше вешать на ссылку определенного класса через background без лишних элементов
«Все поля ввода были вставлены внутрь тегов label»
А тут что не так? К label пишется for если input не внутри. А в остальных for опускается. Тут нет ничего плохого
А тут что не так? К label пишется for если input не внутри. А в остальных for опускается. Тут нет ничего плохого
Плохое в том *читайте далее*, что каждая такая конструкция была вставлена еще и в отдельную форму, причем при попытке убрать лишние формы, верстка разваливалась.
А то что вставка элементов input внутрь label позволяет избавиться от for — не знал, спасибо
А то что вставка элементов input внутрь label позволяет избавиться от for — не знал, спасибо
К сожалению, это не работает в ие, приходится делать кучу айдишников и привязывать к ним лейблы.
Соглашусь.
Атрибут for у label сделан как раз для тех случаев, когда нельзя вложить в него input или элемент формы, связанный с ним, если не ошибаюсь.
Но вроде бы работает криво без указания for в IE6/7.
Атрибут for у label сделан как раз для тех случаев, когда нельзя вложить в него input или элемент формы, связанный с ним, если не ошибаюсь.
Но вроде бы работает криво без указания for в IE6/7.
да, меня тоже удивило возмущение о вставке инпутов в лейблы. это валидно и нормально. а местами очень-очень удобно, т.к. позволяет сделать инпут с подписью единым неразрывным целым, не оборачивая их в лишний блок.
но про отдельные формы — это да…
вообще, там такой ад описан, что я такое делал когда впервые открыл фронтпейдж лет в 16…
но про отдельные формы — это да…
вообще, там такой ад описан, что я такое делал когда впервые открыл фронтпейдж лет в 16…
я бы еще добавил css reset
не всегда это нужно
В целях обучения, без резета полезнее.
Если какая-то проблема лучше знать как её решить (хотя бы подсмотреть в тот же самый резет), чем всё время резет цеплять целиком.
Просто из него в большинстве случаев требуется лишь малая доля, так как часто приходиться переопределять большинство дефолтных значений при вёрстке и то, что они сначала были сброшены, оказывается лишним.
Если какая-то проблема лучше знать как её решить (хотя бы подсмотреть в тот же самый резет), чем всё время резет цеплять целиком.
Просто из него в большинстве случаев требуется лишь малая доля, так как часто приходиться переопределять большинство дефолтных значений при вёрстке и то, что они сначала были сброшены, оказывается лишним.
Я просто про то, что у макета иногда/частенько (у кого как) приходится описывать все эти самые отступы и прочее. В таком случае получается, что сначала идут стили сбрасывающие всё в ноль, а потом определяющие нужные значения css-свойств, отсюда излишняя избыточность. Не говоря уже о том, что в резете есть ещё куча правил, которые никогда и не используются.
То, что стили у браузеров разные, это не имеет значения. Так, например, отступ у какого-то элемента может стоять у них самый разный, зачем мне его сбрасывать сначала резетом, а потом прописывать нужный, когда можно сразу прописать требуемый.
Сервисы это хорошо, но смысл моего высказывания был в том, что иногда лучше прописать нужное свойство явно, если возникает проблема, чем цеплять целиком резет.
Сервисы это хорошо, но смысл моего высказывания был в том, что иногда лучше прописать нужное свойство явно, если возникает проблема, чем цеплять целиком резет.
>>>для firebug есть плагин, который позволяет отследить неиспользуемые стили
Подскажите, пожалуйста, название
Подскажите, пожалуйста, название
Все правильно, все верно, только вот мне интересно, до каких пор будет поддерживаться IE6? Что это за некрофилия? Не пора ли всем верстальщикам дружно отказаться от этого геморроя, дабы он вымер окончательно и безповоротно?
До тех пор, пока это в ТЗ будет прописывать заказчик. Как вариант — можно за этот пункт повышать цену.
Лично я за, как и все верстальщики, но это зависит не только от моих личных пожеланий.
p.s.: некрофилия по отношению к IE6 — очень удачная метафора, улыбнуло )
p.s.: некрофилия по отношению к IE6 — очень удачная метафора, улыбнуло )
мы вон на сайте студии подумали, и решили уже и ИЕ7 отфутболивать на заглушку с обновлением браузера: bicycle-day.com/ie.html
Ну тут логика была примерно следующая: если на сайт зайдет «маркетолог», который не в состоянии даже браузер нормальный поставить, то работать с ним в направлении вэба (да и не только) будет невыносимо и лучше ну его в пень. Нервы дороже.
Ну тут логика была примерно следующая: если на сайт зайдет «маркетолог», который не в состоянии даже браузер нормальный поставить, то работать с ним в направлении вэба (да и не только) будет невыносимо и лучше ну его в пень. Нервы дороже.
+1000
правда я отфутболиваю все ИЕ ниже 7
правда я отфутболиваю все ИЕ ниже 7
кстати если можно заверните страничку в zip со всеми ресурсами )) я бы скачал…
хоть и сижу на фф, но довольно интересно почему не предлагаете оперу, зато есть сафари?
Спасибо за ссылки на портативные версии, мне не пришло в голову вставлять их в заглушки.
Замечательно собранная подборка самых основных советов по верстке. Схоронил в избранном, благодарю.
Для пункта 15 — оговорить использование систем контроля версий — SVN или других.
Для непутевых — дать ссылку на FAQ и все дела.
В Windows — TortoiseSVN или TortoiseHG довольно простые, а на уровне commit/update использовать даже обезьянка сможет:)
Для непутевых — дать ссылку на FAQ и все дела.
В Windows — TortoiseSVN или TortoiseHG довольно простые, а на уровне commit/update использовать даже обезьянка сможет:)
Да… 3ий пункт совершенно верный.
Иногда ИЕ начинает игнорировать написанное после коммента
Иногда ИЕ начинает игнорировать написанное после коммента
да, все правильно.
только п.3 спорный, все-таки с точки зрения оптимизации, они должны быть слиты. другой вопрос, что это могут сделать уже прогеры в продакшне — слить и сжать
только п.3 спорный, все-таки с точки зрения оптимизации, они должны быть слиты. другой вопрос, что это могут сделать уже прогеры в продакшне — слить и сжать
Мне кажется, не всегда разумно сливать их в 1 файл. Например есть общие стили, а есть дополнительные для конкретных страниц (корзины там, фильтров с списке товаров). Зачем на главной грузить лишнее? Пусть оно будет загружаться по мере необходимости. Понятно, что в сумме их должно быть не много (то есть если в процессе вы используете отдельно top-menu.css и header.css их конечно надо объединить в продакшене).
>но это уже совсем на уровне запредельном
Некоторые CMS/фреймворки/шаблонизаторы делают это на уровне движка:
— в код шаблонов вставляется что-то вроде {% use_style common.css %}, {% use_style header.css %}, {% use_style menu.css %} {% use_style contact_form.css %}и т. п. только там где они нужны в коде
— движок для каждой комбинации на лету генерирует css файл в кеше (если его ещё там нет), при этом могут удаляться комментарии и лишние пробельные символы, упаковка в gz и производить прочую «обфускацию», и подставляет его имя в link
Основной недостаток: нельзя кешировать на стороне клиента общий для всех страниц css, для каждого нового сочетания исходных css он будет передаваться по новой. Хотя, конечно, никто не запрещает использовать один общий css традиционно в html, а странично-специфичный генерировать при обработке шаблонов (как вариант в шаблонизатор можно встроить группы css файлов, но мне такие реализации не встречались)
Некоторые CMS/фреймворки/шаблонизаторы делают это на уровне движка:
— в код шаблонов вставляется что-то вроде {% use_style common.css %}, {% use_style header.css %}, {% use_style menu.css %} {% use_style contact_form.css %}и т. п. только там где они нужны в коде
— движок для каждой комбинации на лету генерирует css файл в кеше (если его ещё там нет), при этом могут удаляться комментарии и лишние пробельные символы, упаковка в gz и производить прочую «обфускацию», и подставляет его имя в link
Основной недостаток: нельзя кешировать на стороне клиента общий для всех страниц css, для каждого нового сочетания исходных css он будет передаваться по новой. Хотя, конечно, никто не запрещает использовать один общий css традиционно в html, а странично-специфичный генерировать при обработке шаблонов (как вариант в шаблонизатор можно встроить группы css файлов, но мне такие реализации не встречались)
Вообще поддерживаю, но в статье я говорил о каких-то максимально общих случаях, процитирую себя: «Как именно структурировть стили — вопрос немного холиварный, но главное — как-то это делать.»
4. Я и рассматриваю случай, когда проект уже внедрен. Понятно, что не стоит внедрять макет, пока он полностью не утвержден, но иногда бывают моменты, когда с точки зрения менеджера проектов макет выглядит вполне нормально, а баги находятся уже на стадии внедрения.
6. Иногда приходится работать с чужими проектами, которые вовсе не на UTF-8
6. Иногда приходится работать с чужими проектами, которые вовсе не на UTF-8
Вообще, для хорошего верстальщика это все уже в подсознание забито…
п3 и п.7 — конфликтуют :) хотя вообще спасибо что напомнили про этот скрипт, я давно от него отказался, но иногда все-таки он очень помогает, особенно для оперы
п.21 — fontsquirrell.com, и не парить себе мозги. выдает универсальное решение
ну а так, есть спорные моменты…
и да, ну зачем, зачем пинать чертов ИЕ6?
я только за это требование взвинтил бы вам цену на верстку минимм вдвое, а то и втрое
п3 и п.7 — конфликтуют :) хотя вообще спасибо что напомнили про этот скрипт, я давно от него отказался, но иногда все-таки он очень помогает, особенно для оперы
п.21 — fontsquirrell.com, и не парить себе мозги. выдает универсальное решение
ну а так, есть спорные моменты…
и да, ну зачем, зачем пинать чертов ИЕ6?
я только за это требование взвинтил бы вам цену на верстку минимм вдвое, а то и втрое
Спасибо за минусы :) habrahabr.ru/blogs/webdev/101464/#comment_3144657
А если по делу, я бы добавил еще версию для печати. Как минимум, что бы не разъезжалось, при чем готовых версий довольно много.
Но конечно, по любому, этот момент тоже обсуждается с заказчиком.
Потом, я бы добавил min-height и max-height для textarea в WebKit. Раздражает когда, textarea ломает макет при расширении размера.
А если по делу, я бы добавил еще версию для печати. Как минимум, что бы не разъезжалось, при чем готовых версий довольно много.
Но конечно, по любому, этот момент тоже обсуждается с заказчиком.
Потом, я бы добавил min-height и max-height для textarea в WebKit. Раздражает когда, textarea ломает макет при расширении размера.
Мне кажется, если пользователь сам себе расширяет textarea — значит ему это надо, и я бы отрывал руки, если бы мне не дали расширить поле ввода до того размера, до какого мне нужно, пусть даже я поломаю этим макет. Это я его ломаю, а не верстальщик. Я, как юзер, привык что могу менять, не запрещайте мне этого делать!!!
Я имел в виду min-width и max-width если честно. Вопрос спорный, но, я смотрю по тенденциям, что даже Google в своих сервисах это практикует (только вчера видел, точно не понмю в каком именно).
раздвинь на хабре поле слишком широко ;-)
Спасибо,
еще на хабре есть полезная статья как правильно писать css. Здесь
еще на хабре есть полезная статья как правильно писать css. Здесь
По п.3. еще можно порекомендовать www.modernizr.com/
Это на тот случай, если graceful degradation предусмотрено ТЗ.
Это на тот случай, если graceful degradation предусмотрено ТЗ.
Спасибо, интересная библиотечка, поковыряем. По логике вещей это правильней — отталкиваться от поддерживаемых фич а не от версии браузера, но проблема в том, что помимо поддержки каких-то фич, браузеры отличаются еще и специфическими багами в вещах, которые как бы поддерживаются.
Оффтопик.
Дорогие верстальщики, вас много в этой теме, плз откликнитесь те, кто верстает на 960gs (сетка, 24 колонки, 960.gs/demo_24_col.html ) и кому в целом данная статья показалась правильной.
(всё верно, но 24-ого пункта быть не должно — всё должны быть валидным хотя бы в маркетинговых целях + можно пожелать использовать теги html5)
если это про вас, вы это умеете — напишите мне в хабрапочту, изредка требуется такое…
Дорогие верстальщики, вас много в этой теме, плз откликнитесь те, кто верстает на 960gs (сетка, 24 колонки, 960.gs/demo_24_col.html ) и кому в целом данная статья показалась правильной.
(всё верно, но 24-ого пункта быть не должно — всё должны быть валидным хотя бы в маркетинговых целях + можно пожелать использовать теги html5)
если это про вас, вы это умеете — напишите мне в хабрапочту, изредка требуется такое…
По пункту 15: может быть попробовать использовать системы контроля версий?
2. не только цвет фона, но и цвет текста. и делать так каждый раз когда цвет фона меняется в дочерних элементах.
5. зачем? можно же использовать элемент footer
7. противоречит 3 х)
14. лучше разбивать по файлам с соответствующими названиями и использовать автоматический сборщик типа css-suki
15. если этапов больше одного — надо завести репозиторий. и по коммитам это всё будет видно
16. utf-8, и нечего тут обсуждать.
17. она не кэширует, она замораживает страницу. со всеми вытекающими.
19. href=«javascript:// load details»
5. зачем? можно же использовать элемент footer
7. противоречит 3 х)
14. лучше разбивать по файлам с соответствующими названиями и использовать автоматический сборщик типа css-suki
15. если этапов больше одного — надо завести репозиторий. и по коммитам это всё будет видно
16. utf-8, и нечего тут обсуждать.
17. она не кэширует, она замораживает страницу. со всеми вытекающими.
19. href=«javascript:// load details»
В добавок ко всему упомянутому, стоило бы еще сразу зафиксировать, с каким DOCTYPE делать верстку.
согласен. ибо нефиг на месте топтаться
Ну возможно стоит просто указать «правильный» список совместимых браузеров? :)
новые тэги можно писать так без скриптов:
[h:footer xmlns:h=«www.w3.org/1999/xhtml»]...[/h:footer]
h\:footer {...}
[h:footer xmlns:h=«www.w3.org/1999/xhtml»]...[/h:footer]
h\:footer {...}
считаю что если у фрилансера нет мозгов, то ты хоть 3 тех-задания напиши, толку не будет — получишь кашу!
Еще стоило бы оговорить, что количество подключаемых CSS должно быть минимизировано. Незачем выносить шрифты в один файл, цвета в другой, а оступы в третий. Практика довольно распространенная. Может разработчику оно и удобно, но сопровождать это дело, мягко говоря, не в кайф. Многократно проверено на личном опыте.
Еще мегаважное требование: строгое соблюдение отступов во вложенных тегах. Желательно делать отступы табами. Иногда такая мешанина тегов попадалась — хоть рыдай. Прежде чем разобраться в структуре, приходилось самому отступы расставлять. Вот тут-то и всплывали незакрытые или дважды закрытые теги…
Угу
и
две большие разницы. Впрочем, фиксировать этого не стоит. Если верстальщик не знает таких вещей — это очень слабый верстальщик.
и
две большие разницы. Впрочем, фиксировать этого не стоит. Если верстальщик не знает таких вещей — это очень слабый верстальщик.
Пробельные символы можно загнать в html-комментарий и всеравно перенести правильно. Это тоже не слишком красиво, но лучше, чем в одну строчку, или (о ужас!) делать перенос внутри тегов. Кстати, в django потом комментарии можно убрать и обернуть код в {% spaceless %}.
Это разные форматы для разных целей. Про то, где их применять, можно написать отдельную статью (и скорее всего она уже написана). Кстати, GIF с альфаканалом, на сколько я знаю, не существует. Да и, строго говоря, полупрозрачный 8-и битный PNG тоже не содержит альфаканала.
когда речь идёт о полупрозрачности png-8 сразу не подходит :)Видимо вы не все знаете о PNG :)
www.artlebedev.ru/tools/technogrette/img/png-4/
сильно зависит от характера изображений
Комментарии делаю несколько иным способом:
это облегчает понимание где что заканчивается даже в случае путаницы с табулированием
<div class="myclass myotherclass">
...
</div><!-- myclass myotherclass -->
<div id="myid">
...
</div><!-- #myid -->это облегчает понимание где что заканчивается даже в случае путаницы с табулированием
2. Всегда описывайте цвет фона для body даже если он белый.
Можно я на Вас буду молиться?
Подавляющее большинство верстальщиков и разработчиков забывают об этом. В итоге очень смешно смотрятся такие сайты в моём дефолтном браузере, у которого фоновый цвет по умолчанию совсем не белый.
А по моему это детские болезни
сам себе злобный буратин…
Извините, но ATimofeev, написавший выше, прав.
Это — детские болезни. Но они встречаются очень и очень часто. Мне кажется, что не продумать такой простой вещи, как
Это — детские болезни. Но они встречаются очень и очень часто. Мне кажется, что не продумать такой простой вещи, как
body {background-color:#FFFFFF;} — просто небрежное отношение к своей работе.Сразу видно, что писал программист )
Ваши требования к вертке явно ориентируются на сложный проект, поддержкой и сопровождением которого предстоит заниматься и дальше. Причем не одному человеку. А для среднего сайта достаточно соответствия пунтам хотя бы с первого по четвертый.
Как результат – куча оголтелых манагеров, которые прочли этот пост, будут бездумно тыкаться в ваш чеклист даже при верстке элементарной однодневной фигни. Думаю, не будет лишним отметить, для проектов какого масштаба следует оперировать вашим чеклистом.
Ваши требования к вертке явно ориентируются на сложный проект, поддержкой и сопровождением которого предстоит заниматься и дальше. Причем не одному человеку. А для среднего сайта достаточно соответствия пунтам хотя бы с первого по четвертый.
Как результат – куча оголтелых манагеров, которые прочли этот пост, будут бездумно тыкаться в ваш чеклист даже при верстке элементарной однодневной фигни. Думаю, не будет лишним отметить, для проектов какого масштаба следует оперировать вашим чеклистом.
А подскажите вот какой момент: когда в дизайне в .psd файле повторяющийся фон, как он должен передаваться верстальщику? Дизайнер должен на отдельном слое дать один фрагмент? В общем, чтобы потом верстальщик-нарезальщик не тратил время на поиск фрагмента, который размножался.
Как вообще принято?
Как вообще принято?
Хороший верстальщик должен быть с фотошопом на ты. И должен уметь преобразовать нарисованную дизайнером кнопочку, фон, элемент управления и т. д. таким образом, чтобы облегчить себе жизнь в процессе вёрстки. Например, если у дизайнера нарисовано 10 кнопок разных цветов с градиентом от светлого к тёмному, то верстальщик (если конечно требования заказчика не позволяют использовать css-градиент) должен сам сделать полупрозрачную картинку бело-черного градиента и менять потом только лишь background-color, а не создавать 10 картинок buttonBlue, buttonRed, buttonYellow и т. д.
Хм… дизайнер при изображении кнопок уже создал этот градиент. Зачем верстальщику это делать снова? Тем более как-то ведь надо дать понять верстальщику, что все кнопки будут выглядеть именно так, именно с таким градиентным переходом.
Дизайнер создаст 10 кнопок разных цветов с градиентом. В фотошопе это будут градиенты от светло-зеленого к тёмно-зеленому, от светло-красного к тёмно-красному и т. д. Хороший верстальщик создаст градиент от чёрного к прозрачному и будет накладывать его поверх кнопок. Таким образом ему не придется делать 10 картинок для кнопок. И в css он будет менять только свойство background-color, а градиент на кнопке будет создаваться автоматически.
Я понял, что Вы имеете в виду. Конечно, так и стоило бы сделать. В идеале. Но дизайнер разве не такой же метод использует? Вернее, похожий?
Ибо если так, то кто ему мешает положить этот градиент на отдельный слой, чтоб верстальщик мог использовать готовую заготовку? К тому же и у дизайнера работа упростится — не надо плодить градиентных кнопок, а просто повторно использовать готовую методу.
А если он использует другой метод — кто поручится, что просто наложение градиентной кнопки на фон даст точно тот же переход цветов, который был нарисован?
Ибо если так, то кто ему мешает положить этот градиент на отдельный слой, чтоб верстальщик мог использовать готовую заготовку? К тому же и у дизайнера работа упростится — не надо плодить градиентных кнопок, а просто повторно использовать готовую методу.
А если он использует другой метод — кто поручится, что просто наложение градиентной кнопки на фон даст точно тот же переход цветов, который был нарисован?
В идеале конечно должно быть так как вы говорите. Но это лишь один нюанс, а их гораздо больше. И обучить дизайнера всем этим нюансам займет слишком много времени. Поэтому чаще всего верстальщик перелопачивает потом весь макет. Рисует градиенты, стандартизирует отступы, подгоняет под сетку и т. д.
О да. И это, кстати, одна из распространённых проблем — многие дизайнеры не придерживаются каких-то стандартов, в результате на разных макетах могут быть разные отступы, кнопки могут быть выполнены с разными градиентами, блоки на страницах перекрывать друг дружку и т.д. и т.п. Но, имхо, указать метод «рисования» кнопок — это всё же работа дизайнера. Верстальщик не должен гадать, так или эдак рисовать градиенты.
если дизайнер не поддаётся обучению — гнать его надо
Я этого не умею.
п. 14:
Даже в комментариях не использовать кириллицу.
Даже в комментариях не использовать кириллицу.
Поддерживать оперу < 9.5 — ад. Тем более количество пользователей таких версий меньше процента
На чём основывается ваше утверждение? У меня другая статистика.
На статистике конечно. Приведите вашу и тематику сайта тоже. Количество посетителей тоже имеет значение : ) Есть информация по развлекательно-информационному сайту с посещаемостью 35000 посетителей в сутки (общая статистика по браузерам такая же как по рунету) + есть информация по узкоспециализированным сайтам (лидируют IE, в том числе 12% с IE6) — и там и там пользователей < 9.5 меньше процента, что позволяет на них забить
www.yandex.ru
Выборка за последнюю неделю июля, 40M посетителей.
Opera 10.6 8.71636 Opera 10.5 3.57901 Opera 10.0 - 10.2 3.36054 Opera 9.6 2.66327 Opera 9.0 - 9.2x 1.32989 Opera 9.4 - Opera 9.5 0.95827 Opera 7.x - 8.x 0.18064
Выборка за последнюю неделю июля, 40M посетителей.
Кстати, господа верстальщики, если кто-то из вас согласен с большей частью этого списка и в данный момент ищет постоянную работу в Питере, напишите мне в личку.
Лучше всего сверстать самому!!!
Спасибо, буду давать ссылку на этот пост верстальщикам.
Если уж cursor:pointer, то тогда сразу и для IE:
cursor:pointer;//hand;
За href='javascript:void(0)' я бы по рукам бил. Лучше все-таки прописать href='#', а потом довесить на domload:
cursor:pointer;//hand;
За href='javascript:void(0)' я бы по рукам бил. Лучше все-таки прописать href='#', а потом довесить на domload:
$$("a[href=#]").each(function(a){
a.href="javascript:void(0)";
})
Спасибо большое! Очень полезные советы. Ко многому уже со временем сам пришёл, но попадись мне такой материал в то время, когда я только учился верстать, то, я думаю, я сэкономил бы очень много времени.
Кроме п. 1 все — на любителя, спорно(любой можно повернуть с точностью до наоборот) и сильно зависит от задачи…
Как то при социализме уже жили, когда все ходили в одинаково пошитых штанах :)
Как можно уместить в 22 надуманных кем-то пункта все случаи?
Сорри, глянув на возраст топик стартера — все списал на юный возраст и квалификацию начинающего…
Как то при социализме уже жили, когда все ходили в одинаково пошитых штанах :)
Как можно уместить в 22 надуманных кем-то пункта все случаи?
Сорри, глянув на возраст топик стартера — все списал на юный возраст и квалификацию начинающего…
Безусловно, большинство рекомендаций — дело вкуса. Но устаканивать их все-таки надо. Когда меня спрашивают, а почему такой стандарт а не такой, то я говорю, что в общем-то без разницы. Главное, что СТАНДАРТ ДОЛЖЕН БЫТЬ.
Зачем оно надо?
После того как статический HTML-макет сайта сверстан, его «оживляют» зачастую совсем не те программист(ы), которые делали верстку. И если верстка сделана плохо, это сильно усложняет жизнь девелоперам. Комменты в CSS и HTML, отступы в разметке — все это сильно поможет девелоперам при сопровождании.
В процесс разработки вовлечено несколько людей, но результат труда должен быть единообразен. Если часть CSS-классов поименованно в верблюжьей нотации а часть с разделением слов через дефис, то лично для меня это тревочный сигнал. Это показатель не очень высокого качества производственных процессов, возникают сомнения в качестве управления проектом.
Так что штаны должны быть пошиты одинаково. Разумеется, стандарт может отчасти меняться от проекта к проекту. Но еще раз повторюсь, что стандарт должен быть. Обязательный к исполнению всеми членами команды. И как девелопер должен заметить, что соблюдать стандарты не так уж и сложно.
Зачем оно надо?
После того как статический HTML-макет сайта сверстан, его «оживляют» зачастую совсем не те программист(ы), которые делали верстку. И если верстка сделана плохо, это сильно усложняет жизнь девелоперам. Комменты в CSS и HTML, отступы в разметке — все это сильно поможет девелоперам при сопровождании.
В процесс разработки вовлечено несколько людей, но результат труда должен быть единообразен. Если часть CSS-классов поименованно в верблюжьей нотации а часть с разделением слов через дефис, то лично для меня это тревочный сигнал. Это показатель не очень высокого качества производственных процессов, возникают сомнения в качестве управления проектом.
Так что штаны должны быть пошиты одинаково. Разумеется, стандарт может отчасти меняться от проекта к проекту. Но еще раз повторюсь, что стандарт должен быть. Обязательный к исполнению всеми членами команды. И как девелопер должен заметить, что соблюдать стандарты не так уж и сложно.
Мои 5 копеек, чуть запоздало.
Если это реальная ссылка, то настоящий адрес в ней уже будет. Если адреса нет, то и ссылки быть не должно. А должен быть любой элемент с cursor:pointer и обработчиком onclick. Это называется семантика и обратная совместимость.
Если почитать соответствующие спеки внимательно, то именно такое поведение и подразумевается. Если кто-то «не как все», то это не значит, что он ошибается в своих действиях. И ведь мало кто из разработчиков вспоминает, что кроме возвращений назад, бывают ещё и автозаполнители форм, которые не вызывают ожидаемых событий. Это вообще очень сложный вопрос. Единственный возможный совет: «проверяйте всё и всегда, особенно подразумеваемые вещи».
Весь JS нужно выносить во внешний файл. В этом вопросе стоит быть гораздо категоричнее, иначе JS-код пухнет, теряет логику и начинает подчинять весь документ. Разве что вы Яндекс и занимаете супер-оптимизацией… но это вряд ли :)
Основывать вёрстку (а значит, в какой-то мере, доступность информации) на JS, который может отвалиться, быть отключённым или просто не сработать — это безумие. Вы писали этот JS-код? Вы тестировали его на всех браузерах, на всех платформах, на всех девайсах? Вряд ли.
В общем, список получился довольно сумбурным. Важные вещи перемешаны с сиюминутными проблемами.
19. Если вы делаете обработку событий при нажатии на ссылки, следите за тем, чтобы обработчики событий возвращали false, или же используйте href='javascript:void(0)' вместо популярного href='#', чтобы страница не скроллилась вверх.
Если это реальная ссылка, то настоящий адрес в ней уже будет. Если адреса нет, то и ссылки быть не должно. А должен быть любой элемент с cursor:pointer и обработчиком onclick. Это называется семантика и обратная совместимость.
17. Если в макете присутствует JS, изменяющий DOM — внимательно следить, чтобы все корректно работало в Опере, т. к. этот замечательный браузер при нажатии на кнопочку назад страницу не перезагружает
Если почитать соответствующие спеки внимательно, то именно такое поведение и подразумевается. Если кто-то «не как все», то это не значит, что он ошибается в своих действиях. И ведь мало кто из разработчиков вспоминает, что кроме возвращений назад, бывают ещё и автозаполнители форм, которые не вызывают ожидаемых событий. Это вообще очень сложный вопрос. Единственный возможный совет: «проверяйте всё и всегда, особенно подразумеваемые вещи».
8. Если Javascript кода много — нужно его выносить в отдельный файл
Весь JS нужно выносить во внешний файл. В этом вопросе стоит быть гораздо категоричнее, иначе JS-код пухнет, теряет логику и начинает подчинять весь документ. Разве что вы Яндекс и занимаете супер-оптимизацией… но это вряд ли :)
3. Если используете CSS хаки, комментируйте, что это и для какого браузера, а лучше используйте css_browser_selector.js
Основывать вёрстку (а значит, в какой-то мере, доступность информации) на JS, который может отвалиться, быть отключённым или просто не сработать — это безумие. Вы писали этот JS-код? Вы тестировали его на всех браузерах, на всех платформах, на всех девайсах? Вряд ли.
В общем, список получился довольно сумбурным. Важные вещи перемешаны с сиюминутными проблемами.
Если это реальная ссылка, то настоящий адрес в ней уже будет. Если адреса нет, то и ссылки быть не должно. А должен быть любой элемент с cursor:pointer и обработчиком onclick. Это называется семантика и обратная совместимость.
Использование ссылки вместо кнопки частенько помогает избежать использование яваскрипта для обработки «hover». Можно, конечно, утверждать, что всё это финты ушами, но…
Использование ссылки вместо кнопки частенько помогает избежать использование яваскрипта для обработки «hover». Можно, конечно, утверждать, что всё это финты ушами, но…
JS для имитации :hover на любом объекте нужен только для IE6 и младше. Проблема теряет свою актуальность с каждым днём, а для некоторых уже давно потеряла.
Можно конечно попробовать придраться, но по сути я с Вами согласен. И ссылка должна быть ссылкой. И :hover в нормальных браузерах обрабатывается корректно. И шестой експлорер надо выкорчёвывать калёным железом. Так что проблема теряет актуальность с каждой минутой.
Рано вы его хороните, это зависит от клиентов. И не говорите, что на таких клиентов следует забивать. Бизнес важнее, чем технологический экстаз и мы должны отталкиваться от сугубых реалий действительности. Да, проблема теряет свою актуальность, но она все еще есть.
ну если его не хоронить, так он ведь, сука, никогда и не сдохнет! :(
Это не технологический экстаз, это банальное уважение к самому себе. Гораздо приятнее, полезнее и просто выгоднее для вас будет тратить время на новый проект, а не на танцы вокруг трупа IE6.
Но, опять же, я не отрицаю, что бывает и клиника — ваш заказчик сельская бухгалтерия, а верстальщики прикованы наручниками к батарее. Тогда — да :)
Но, опять же, я не отрицаю, что бывает и клиника — ваш заказчик сельская бухгалтерия, а верстальщики прикованы наручниками к батарее. Тогда — да :)
Сельская бухгалтерия — это вполне себе могут быть корпорация с десятками тысяч рабочих станций и кучей унаследованного внутреннего софта, который писался в эпоху IE6 и заточен под него. Так, что можете быть отвязанными от батарее и от заказов от таких компаний, которые наверняка имеют финансы и потребность, в отличии от «уважающих себя» тинейджеров, с ворованным Win7…
Я почему-то не теряю уважения к себе, делая качественную верстку, выглядящую одинаково хорошо во всех браузерах, даже в IE6.
Да, лично мне как верстальщику, было бы и приятнее и полезнее и выгоднее тратить время на новый проект, а не на адаптацию макетов к IE6. А еще мне хотелось бы жить на Гаваях в домике с видом на море и жену негритянку.
Но в организации, в которой я работаю, на первом месте интересы клиента.
Взгляните на проблему шире, она актуальна не только для сельских бухгалтерий. Вы обошли своим вниманием кучу брендов, у которых, к примеру, целевая аудитория — домохозяйки.
Я думаю, такие заказчики вполне грамотно поступают, требуя поддержку IE6 от веб-разработчиков.
Чтож, кто-то возможно отказался бы от такой грязной и невыносимой работы. А мы все еще, о ужас, соглашаемся делать сайты с поддержкой IE6 :)
Да, лично мне как верстальщику, было бы и приятнее и полезнее и выгоднее тратить время на новый проект, а не на адаптацию макетов к IE6. А еще мне хотелось бы жить на Гаваях в домике с видом на море и жену негритянку.
Но в организации, в которой я работаю, на первом месте интересы клиента.
Взгляните на проблему шире, она актуальна не только для сельских бухгалтерий. Вы обошли своим вниманием кучу брендов, у которых, к примеру, целевая аудитория — домохозяйки.
Я думаю, такие заказчики вполне грамотно поступают, требуя поддержку IE6 от веб-разработчиков.
Чтож, кто-то возможно отказался бы от такой грязной и невыносимой работы. А мы все еще, о ужас, соглашаемся делать сайты с поддержкой IE6 :)
Повторюсь: я не отрицаю, что в специфических случаях важна поддержка IE6. Есть куча вариантов, начиная с сельской бухгалтерии, заканчивая домохозяйками. Но список универсальных правил будет полезен чуть больше, чем двое суток, если он будет смотреть в перспективном направлении, а не копаться маргинальных случаях.
Поэтому:
— Элемент должен быть ссылкой только если он содержит осмысленный URL или якорь в атрибуте href, иначе это должен быть любой другой подходящий элемент с
— Для имитации :hover на других элементах, в IE6 можно использовать: a:hover, expression или Javascript
Так ведь лучше, правда?
Поэтому:
— Элемент должен быть ссылкой только если он содержит осмысленный URL или якорь в атрибуте href, иначе это должен быть любой другой подходящий элемент с
cursor:pointer и onclick="…".— Для имитации :hover на других элементах, в IE6 можно использовать: a:hover, expression или Javascript
Так ведь лучше, правда?
а на кнопках разве ховер не работает? :-о
Также при создании макетов и отправке их на верстку нужно обращать внимание на наличие стилей для:
— Заголовков 1-3 уровня в контенте;
— Нумерованных и маркированных списков;
— Таблиц, названий и заголовков таблиц;
— Элементов форм, также верстать поля форм заполненными, чтобы можно было сразу видеть стиль текста.
Также стоит проверить стили для:
— strong,
— em,
— dl, dt, dd
— blockquote
Обязательно нужно указать какими должны быть активные ссылки (и другие кликабельные элементы), посещенные, при наведении курсора.
Это необходимо для того, чтобы потом, при заполнении сайта контентом не возникало проблем.
Требования к структуре каталогов, например:
Файлы .html называть именами соответствующих *.psd файлов.
Именование CSS-файлов:
— reset.css — css-ресет.
— style.css — основные стили, которые относятся ко всему сайту и главной странице.
— inner.css — выносить стили, которые относятся к внутренним страницам, если нужно что-то переопределить.
— form.css — стили форм.
— pages.css — стиль постраничного вывода (страницы 1 2 3 4… 11 12)
— debug.css — временный файл используется программистами для правок верстки, которые потом должен пересмотреть верстальщик и вынести/подправить соответствующим образом.
— ie.css — стили для ИЕ.
— ie6.css — для ИЕ6.
В основных файлах не использовать хаков, только валидный CSS. Все что касается ИЕ — в отдельные файлы и подключать через Conditional Comments.
— Заголовков 1-3 уровня в контенте;
— Нумерованных и маркированных списков;
— Таблиц, названий и заголовков таблиц;
— Элементов форм, также верстать поля форм заполненными, чтобы можно было сразу видеть стиль текста.
Также стоит проверить стили для:
— strong,
— em,
— dl, dt, dd
— blockquote
Обязательно нужно указать какими должны быть активные ссылки (и другие кликабельные элементы), посещенные, при наведении курсора.
Это необходимо для того, чтобы потом, при заполнении сайта контентом не возникало проблем.
Требования к структуре каталогов, например:
htdocs (тут лежат все файлы .html) └─-- (каталог «-» дефис, файлов не содержит) ├─css ├─img ├─js ├─plugins │ ├─jquery │ ├─jquery-fancybox │ └─swfobject └─swf
Файлы .html называть именами соответствующих *.psd файлов.
Именование CSS-файлов:
— reset.css — css-ресет.
— style.css — основные стили, которые относятся ко всему сайту и главной странице.
— inner.css — выносить стили, которые относятся к внутренним страницам, если нужно что-то переопределить.
— form.css — стили форм.
— pages.css — стиль постраничного вывода (страницы 1 2 3 4… 11 12)
— debug.css — временный файл используется программистами для правок верстки, которые потом должен пересмотреть верстальщик и вынести/подправить соответствующим образом.
— ie.css — стили для ИЕ.
— ie6.css — для ИЕ6.
В основных файлах не использовать хаков, только валидный CSS. Все что касается ИЕ — в отдельные файлы и подключать через Conditional Comments.
Каждый HTTP-запрос к серверу имеет довольно ощутимые накладные расходы. Поэтому количество скриптов, картинок и стилевых файлов желательно минимизировать. Подробнее см. в книге «Разгони свой сайт». Лично я обычно весь CSS храню в 1-2 файлах, но стили сгруппированы и снабжены комментариями.
При деплое все файлы склеиваются в один/несколько и минимизируются. Изначально всё делать в одном файле — ад. Если вы конечно не делаете сайт-визитку из 2х страниц
Забегая наперед, скажу
1. Все запросы к каталогу «-» обрабатывает nginx.
2. Для всех файлов стилей используется minify
3. Все файлы на продакшине, как css так и js сливаются в один.
Так и выходит, как вы говорите, всего 2 файла — 1 css и один js, но для девелопмента это неприемлимо, так как править файлы по нескольку десятков килобайт — удовольствие еще то.
Кроме того, разбивка на файлы бывает и больше, может быть так, что в отдельные файлы выносятся стили для текста и для основной разметки макета, а также стили, которые использует javascript. Также бывает еще файл basis.css, в котором после ресета устанавливаются основные отступы, начертания, кегль и размеры шрифта.
1. Все запросы к каталогу «-» обрабатывает nginx.
2. Для всех файлов стилей используется minify
3. Все файлы на продакшине, как css так и js сливаются в один.
Так и выходит, как вы говорите, всего 2 файла — 1 css и один js, но для девелопмента это неприемлимо, так как править файлы по нескольку десятков килобайт — удовольствие еще то.
Кроме того, разбивка на файлы бывает и больше, может быть так, что в отдельные файлы выносятся стили для текста и для основной разметки макета, а также стили, которые использует javascript. Также бывает еще файл basis.css, в котором после ресета устанавливаются основные отступы, начертания, кегль и размеры шрифта.
очень полезный пост, хотя бы тем, что к нему написали много интересных комментариев :)
Отличная статья получилась. Много рекомендаций добавил в свои. Хочу поделится некоторыми своими:
• Соответствие стандартам W3C.
• Верстка должна быть логически верной:
o При отключенном css, сайт должен отображаться в следующем порядке: шапка, главное горизонтальное меню (если есть), левая часть (если есть), контентная часть, правая часть(если есть), подложка.
o На страницах обязательно использовать теги h1, h2, h3 в соответствии с логической нагрузкой надписи. Например, название страницы делать h1.
o Все выделения жирным и курсивом должны быть сделаны с помощью тегов strong и em соответственно. При необходимости использовать CSS, но только с вышеуказанными тегами. Теги b и i не использовать, для выделения блоков со смысловой нагрузкой. (пункт появился, после того как кто-то сделал: span class=«b»)
• Контентные части сайта, куда будет выведен текст из визуального редактора, должны корректно отображать текст (p, b, i, etc), картинки (img), ссылки (a ), таблицы (table, tr, td, th), списки (li, ul и т.д.), без использования в тегах классов стилей. Необходимо использовать только класс внешнего контейнера.
• Рамки на картинках всегда являются элементом верстки, а не картинки. Тени, отблески и т.д. считаются рамкой картинки.
• По возможности, как можно больше элементов вносить в общий шаблон. Все страницы сайта шаблонизируются таким образом, что существует главный шаблон, и в него подгружаются разные внутренние шаблоны. Исключения составляют абсолютно разные страницы, например: версия для печати, загрузочная страница. Если в общем шаблоне остаются части, которые будут меняться, то необходимо комментариями отметить это, а так же предоставить верстку этих частей, во всех отображениях.
• Если сайт будет на нескольких языках, то нарезать все картинки с надписями для разных языков. Называть картинки необходимо %название%_%указатель языка (ru|ua|en|…)%.jpg|gif|etc.
• Соответствие стандартам W3C.
• Верстка должна быть логически верной:
o При отключенном css, сайт должен отображаться в следующем порядке: шапка, главное горизонтальное меню (если есть), левая часть (если есть), контентная часть, правая часть(если есть), подложка.
o На страницах обязательно использовать теги h1, h2, h3 в соответствии с логической нагрузкой надписи. Например, название страницы делать h1.
o Все выделения жирным и курсивом должны быть сделаны с помощью тегов strong и em соответственно. При необходимости использовать CSS, но только с вышеуказанными тегами. Теги b и i не использовать, для выделения блоков со смысловой нагрузкой. (пункт появился, после того как кто-то сделал: span class=«b»)
• Контентные части сайта, куда будет выведен текст из визуального редактора, должны корректно отображать текст (p, b, i, etc), картинки (img), ссылки (a ), таблицы (table, tr, td, th), списки (li, ul и т.д.), без использования в тегах классов стилей. Необходимо использовать только класс внешнего контейнера.
• Рамки на картинках всегда являются элементом верстки, а не картинки. Тени, отблески и т.д. считаются рамкой картинки.
• По возможности, как можно больше элементов вносить в общий шаблон. Все страницы сайта шаблонизируются таким образом, что существует главный шаблон, и в него подгружаются разные внутренние шаблоны. Исключения составляют абсолютно разные страницы, например: версия для печати, загрузочная страница. Если в общем шаблоне остаются части, которые будут меняться, то необходимо комментариями отметить это, а так же предоставить верстку этих частей, во всех отображениях.
• Если сайт будет на нескольких языках, то нарезать все картинки с надписями для разных языков. Называть картинки необходимо %название%_%указатель языка (ru|ua|en|…)%.jpg|gif|etc.
Спасибо!
Пункты 2.2, 4 и последний — однозначно очень ок, первый входит в то, о чем я говорил в своем последнем пункте, остальные можно пообсуждать или возможно как-то по-иному сформулировать.
2.1 — а в каких случаях сайт вдруг может отобразится без CSS, просветите? Браузеры без поддержки CSS все еще популярны? :)
2.3 — почему именно так с i,b,em,strong?
Пункты 2.2, 4 и последний — однозначно очень ок, первый входит в то, о чем я говорил в своем последнем пункте, остальные можно пообсуждать или возможно как-то по-иному сформулировать.
2.1 — а в каких случаях сайт вдруг может отобразится без CSS, просветите? Браузеры без поддержки CSS все еще популярны? :)
2.3 — почему именно так с i,b,em,strong?
2.1. — это требование со стороны SEO, а не со стороны отображения дизайна.
2.3. — b и i, решили не использовать, т.к. визуальные редакторы вставляют именно strong и em, потому для единообразия и решили.
2.3. — b и i, решили не использовать, т.к. визуальные редакторы вставляют именно strong и em, потому для единообразия и решили.
2.1. Тогда нужно говорить не о порядке отображения блоков на странице с отключенным CSS, а о порядке их расположения в html-макете. А этот порядок может очень зависеть от типа контента конкретного сайта.
2.3. Решение такого характера можно и полезно использовать во внутренних правилах вашей фирмы, но опять же, в статье я пытался говорить о каких-то максимально общих моментах.
Предпоследний пункт я бы вот как-то переформулировал
Есть над чем подумать спасибо автору. Стандартизация это экономия времени.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Требования к html-верстке