Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 174
Спасибо за статью!
Уже не первый раз вижу упоминание «display:table-cell» на хабре. И вот вроде все красиво и хорошо, но одна маленькая заноза — а не становится ли от этого верстка фактически табличной?
Уже не первый раз вижу упоминание «display:table-cell» на хабре. И вот вроде все красиво и хорошо, но одна маленькая заноза — а не становится ли от этого верстка фактически табличной?
Верстка становиться табличной, когда в ней используются таблицы. В примере верстка хоть и похожа на табличную, но является семантической в отличии от последней.
«Раздражающие» названия тегов в табличной верстке — не самый большой ее недостаток. А значение «table-cell» — позволяет из любого дива или лист-айтема сделать тд. Хотя стоп, я в этом не большой специалист. Лучше вообще в форме вопроса говорить — значение «table-cell» действительно делает из любого тега фактически ТД?
Основная проблема табличной верстки в том, что браузер пока не загрузит полностью структуру таблицы, не будет ее отображать (кроме Оперы, которая вроде таки рендерит до загрузки). Поэтому хоть мы и задаем table-cell, но преимущества div'ной верстки остаются.
Мне почему-то показалось, что «table-cell» будет обрабатываться как обычная ТД, наследуя все табличные прелести. Это не так?
Вот если б вся статья была написана с использованием table, tr и td, то статья в лучшем случае вызвала бы недоумение. А обсуждаемый код всего лишь подменяет названия тегов, сохранив и «квадратно-гнездовое» табличное мышление и все остальные прелести таблиц.
li - тег для списков, а структура html-документа списком не свяляется, поэтому лично мне приведенный выше код кажется гм... не то чтобы несовсем семантическим... бредом откровенным.
что до структуры, то она, собственно, есть только у контентной части. не то чтоб в хеадере и футере ее нет... в них просто, обычно, нет именно того, что принято называть контентом страницы (есть и исключения), так что введение вышеупомянутого кода кажется мне:
- чрезмерным структурированием,
- семантически неверным,
- искажающим страницу при отключенных стилях,
- приволящим к увеличению объема кода.
вывод: фтопку.
все имхо. пусть каждый делает так, как считает правильным.
что до структуры, то она, собственно, есть только у контентной части. не то чтоб в хеадере и футере ее нет... в них просто, обычно, нет именно того, что принято называть контентом страницы (есть и исключения), так что введение вышеупомянутого кода кажется мне:
- чрезмерным структурированием,
- семантически неверным,
- искажающим страницу при отключенных стилях,
- приволящим к увеличению объема кода.
вывод: фтопку.
все имхо. пусть каждый делает так, как считает правильным.
Поддерживаю. Тем более, что автор упомянул, что с float могут возникать глюки в IE, и тут же в своём примере понаписал кучу стилей и хаков отдельно для IE. Так что разницы не вижу. По крайней мере у меня с float не такие уж и огромные проблемы и несильно много хаков приходится писать.
А об этой повсеместной паранойе со структурой и иерархией я вообще молчу. Каждый теперь их ищет даже там, где совсем не нужно.
А об этой повсеместной паранойе со структурой и иерархией я вообще молчу. Каждый теперь их ищет даже там, где совсем не нужно.
имхо, правильно выделять в тексте семантику - основная головная боль. если бы это было тривиальной задачей, это было бы легче использовать и таких проблем с дизайном не было бы. Вы все правильно говорите на счет семантики контентной части.
Согласен. "Иерархия и связи" представляются вложенностью элементов, а не списками.
Я полностью не поддерживаю такую вёрстку, но хочу заметить, что если использовать не UL LI, а OL LI, то структуризация вполне логичная, страница не искажается и семантически страница становиться вполне валидной
ну, по поводу семантической валидности - вот когда W3C будет рекомендовать использовать теги списков для структурирования ВСЕЙ страницы - тогда это и можно будет назвать семантической валидностью. а пока, что при использовании ненумерованных, что при использовании нумерованных списков, валидность исключительно xTML-евская. а ни для кого не секрес, что валидная страница может быть сверстана сверхбезграмотно.
лично я, откровенно говоря, не заплатил бы ни копейки верстальщику, принесшему мне такой вот "шедевр семантики".
лично я, откровенно говоря, не заплатил бы ни копейки верстальщику, принесшему мне такой вот "шедевр семантики".
Представте что тэг table значит по английски не таблица, а к примеру, сетка. И вы верстаете с помошью сеточного layout manger'а.
Никогда не понимал, чего все так привезались к этому table. Пользователю не видо разницы. Зачем тогда вся эта возьня?
Никогда не понимал, чего все так привезались к этому table. Пользователю не видо разницы. Зачем тогда вся эта возьня?
Не надо пихать везде id где можно использовать class, он всётаки не совсем для этого сделан :)
Почему же? Эти елементы на странице больше повторяться не должны, то есть они уникальны, поэтому и используем id.
Повторяться то может и не повторяются, но основное их назначение всё-таки немного другое
Ну так, может все таки откроете вуаль секретности и скажете какое?
Я так понимаю вы имеете ввиду доступ из javascript'a к элементам с заданным id, вследствие быстрого доступа после построения структуры DOM.
Я так понимаю вы имеете ввиду доступ из javascript'a к элементам с заданным id, вследствие быстрого доступа после построения структуры DOM.
Ага. Может конечно ничего криминального в этом нет, но всётаки почему бы не использовать class для его прямых нужд? Долго писать? :)
Раньше я тоже всегда писал через классы, но потом отказался от этого стиля — слишком большой получается CSS (.mainframe .header .top-menu .container ul и т.п.). Не вижу криминала в использвании здесь идентификаторов.
Абсолютно солидарен :)
Какбе вы путаете семантику id и class. В CSS идентификатор логично и правильно использовать без указания родительских элементов (запись
.header #top-menu вообще абсурдна), а классы вообще-то хорошо бы записывать вместе с родителями. Пример: вы задали шапку сайта классом .header {...}, а потом забыли и стали ячейкам-заголокам таблицы тоже присваивать класс .header. Оп-па. Конфликт. Придётся либо менять название класса (что стрёмно), либо перебивать свойства класса в новом стиле (что ещё хуже), либо указывать все классы вместе с родителями (и, в принципе, чем глубже, тем масштабируеме). Но так или иначе, когда-нибудь указывать всю эту цепочку станет лень и вы тоже перейдёте на id-ы =).Именно это и имелось ввиду, но было лень писать :)
> а если у меня шапка сайта #header а потом я делаю,
> не знаю, шапку блока тоже #header
А нельзя, id элемента уникален, а тут получится целых два — вадидатор ругаться будет, да и неправильно это.
> что насчет классов вроде "table_header"? ;)
Это первое «либо», что я указал. Жизнеспособно, но выглядит не очень:
> непонятен мне спор )
Ну и ладно, тогда предлагаю закончить.
> не знаю, шапку блока тоже #header
А нельзя, id элемента уникален, а тут получится целых два — вадидатор ругаться будет, да и неправильно это.
> что насчет классов вроде "table_header"? ;)
Это первое «либо», что я указал. Жизнеспособно, но выглядит не очень:
<table><tr class="table_header"> (кстати, я надеюсь, вы осознаёте что это пример и в реальной жизни надо использовать <table><th>?).> непонятен мне спор )
Ну и ладно, тогда предлагаю закончить.
Я предпочитаю использовать id для обозначения логических частей страницы, например #header, #sidebar, #footer — это такие блоки которых врятли будет больше 1. А вот то что находится внутри этих блоков пишем классами. В данном случае мы вполне законно в разных частях (#header, #content, …) можем использовать одинаковые названия классов
1. сразу именовать нужно нормально. class="page-header page-header-mode-private"
2. регулярно использую правила вида: #moderator-controls {display: none } .state-moderator-is-true #moderator-controls {display: block }
2. регулярно использую правила вида: #moderator-controls {display: none } .state-moderator-is-true #moderator-controls {display: block }
Не вижу криминала в использвании здесь идентификаторов.
А он есть...
Элементы с id требуют гораздо больше памяти при рендеренге. Злоупомтреблять id дурной тон.
А если изначально планируется получать доступ к этим элементам средствами JavaScript? Почему бы тогда не отказаться от использоваться "class"?
Согласен с вами. Тем более при использовани id сразу становиться понятно что элемент уникальный. Это отлично подходит для всяких там header'ов, footer'ов и прочих элементов, которые по своей природе не должны повторяться в на странице.
Так потом будет проще переписывать код.
Так потом будет проще переписывать код.
>Не надо пихать везде id где можно использовать class
Один из основателей w3.org Jeffrey Zeldman рекомендует использовать в этих случаях именно id, как признак того, что этот элемент требует к себе особого отношения.
См. http://www.ozon.ru/context/detail/id/2369681/ стр.193 раздел "id против class"
ЗЫ из этого не следует, что id лучше class, или наоборот, но то что такая точка зрения право на существование - однозначно.
Если не верите - см. верстку
w3.org smashingmagazine.com alistapart.com etc
Один из основателей w3.org Jeffrey Zeldman рекомендует использовать в этих случаях именно id, как признак того, что этот элемент требует к себе особого отношения.
См. http://www.ozon.ru/context/detail/id/2369681/ стр.193 раздел "id против class"
ЗЫ из этого не следует, что id лучше class, или наоборот, но то что такая точка зрения право на существование - однозначно.
Если не верите - см. верстку
w3.org smashingmagazine.com alistapart.com etc
Класс. Главное знал про table-cell, но не использовал =) парадокс
position:absolute и разруливание по пикселям рулит, особенно если весь сайт такой :)
Зачет.
я отстал :(
Черт, я по ходу тоже от жизни немного отстал. :) Весьма интересная техника.
очень не рекомендую использовать списки для верски скелетов.
Семантика?? Какая нафиг семантика в списках?
float верстка не так и сложна для понимания. Намного сложнее будет понимать наследования css свойств для ul li свойств в дереве. Или всем элементом id прописывать?
Семантика?? Какая нафиг семантика в списках?
float верстка не так и сложна для понимания. Намного сложнее будет понимать наследования css свойств для ul li свойств в дереве. Или всем элементом id прописывать?
Что Вы имеете ввиду под "css свойств для ul li свойств в дереве"?
Ведь для трех блоков верстки у нас id уже есть, а для остальных можно прописать общее css-правило.
Ведь для трех блоков верстки у нас id уже есть, а для остальных можно прописать общее css-правило.
Рискну предположить, что сложности понимания - дело опыта и личных пристрастий.
«после сложности» понимания приходит «неудобство»
Я согласен с вами в том, что этот способ несколько противоречив, потому я и назвал его ниже более логичным и элегантным, но не предпочтительным. Мне он не приглянулся, например, потому, что без флоатов средствами css нельзя "переставить местами" колонки. Это только то, что первое пришло на ум (полусонный).
Но что касается неудобства - это всё-таки дело привычки. Ещё мой дед говаривал: "В умелых руках - и х*й сабля!". Что для вас представляется неудобным, кому-то покажется приемлемым. Люди мыслят по-разному, факт.
Но что касается неудобства - это всё-таки дело привычки. Ещё мой дед говаривал: "В умелых руках - и х*й сабля!". Что для вас представляется неудобным, кому-то покажется приемлемым. Люди мыслят по-разному, факт.
Похоже, что предложенный способ логичнее и элегантнее широко известного Святого Грааля (с alistapart.com) и его последующих усовершенствований.
Впечатление немного подпортил тот факт, что для Эксплореров приходится хитрить. Но, увы, ничего идеального в этом несовершенном мире нет.
Впечатление немного подпортил тот факт, что для Эксплореров приходится хитрить. Но, увы, ничего идеального в этом несовершенном мире нет.
Об этом я и писал чуть выше. Здесь же я лишь отметил элегантность и логичность такого решения. Несмотря на недостатки, наверняка это кому-то может пригодиться. Далеко не на всех сайтах есть острая необходимость выдерживать одинаковую высоту колонок, если вы об этом.
А можно сослаться на примеры реализации грааля?
да и вообще, верстка без хаков — утопия. Все равно что движение без трения.
А вот здесь можно поспорить, у меня например 80% всех работ обходятся без хаков.
покажите парочку, пожалуйста.
А можно вопрос? Что именно вы называете хаками?
Дело в том что мне тоже трудно представить кроссбраузерную верстку без использования условных комментариев и подобных вещей.
Без использования хаков мне кажеться нельзя будет реализовать некоторые конкретно поставленные задачи (например решить проблему прозрачности PNG в IE, или в том же IE заставить работать min-width и т.д.).
Дело в том что мне тоже трудно представить кроссбраузерную верстку без использования условных комментариев и подобных вещей.
Без использования хаков мне кажеться нельзя будет реализовать некоторые конкретно поставленные задачи (например решить проблему прозрачности PNG в IE, или в том же IE заставить работать min-width и т.д.).
Абсолютно верно подмечено: что именно называть хаками? Вижу как минимум три варианта:
1. То что решает проблему, но не валидно.
2. То что решает проблему, используя методы отличные от предусмотреных стандартом, но которые являются валидными.
3. И то и другое.
1. То что решает проблему, но не валидно.
2. То что решает проблему, используя методы отличные от предусмотреных стандартом, но которые являются валидными.
3. И то и другое.
Я дико извиняюсь, а как условный комментарий "if !IE" прочитает адресат - браузер, который не читает условные комментарии?
Я всегда полагал, что способы, предусматривающие использование "спецсимволов, делающих правила в CSS видимыми в одних браузерах и невидимыми для других" называются фильтрами... Поправьте, если ошибался.
У нас в компании (занимаемся созданием сайтов) вообще не допускается использовать хаки при вёрстке.
То есть если нужно что-то реализовать и без хаков это не получается, то вы отступаете от желаемого?
Если не удаётся реализовать без хаков, то у нас допускаются небольшие расхождения в отображении в разных браузерах. Таких случаев не очень много и даже в таких случаях отображение не должно бросаться в глаза посетителям сайта. Тоесть обычно чтоб увидить расхождение нужно было бы сравнить отображение в разных браузерах.
примеры в студию. Хотя бы пара примеров ваших версток.
У вас в ссылке «наличие layout» ошибка, одна из букв o — кириллическая :)
А вообще способ не «молодой», где-то уже видел дискуссию на эту тему.
А вообще способ не «молодой», где-то уже видел дискуссию на эту тему.
On having layout переведен на Хабре :)
http://habrahabr.ru/blog/webdev/24553.ht…
http://habrahabr.ru/blog/webdev/24553.ht…
Если честно, на мой взгляд до повсеместного внедрения CSS3 о полностью семантической вёрстке можно забыть — слишком много костылей.
Всё бы хорошо, но списки, имхо, — это несколько перебор.
Разделять глобальные секции в макете всё-таки лучше при помощи простых DIV'ов с говорящими именами.
Разделять глобальные секции в макете всё-таки лучше при помощи простых DIV'ов с говорящими именами.
Вкручивать шаблон в скрипт?
Мальчик, иди про MVC почитай, не мешай взрослым дядям разговаривать.
Мальчик, иди про MVC почитай, не мешай взрослым дядям разговаривать.
Считаете, что представление и логику разделять не надо? Ну что же, флаг в руки.
По поводу того, что вы старше, так "мальчик" это отнюдь не про возраст.
Ну и касательно того, кому кого учить - money talks, bullshit walks. Какой у вас самый крупный проект? У меня стрим-тв и внутренняя BSS, которая обеспечивает жизнедеятельность стрим-интернет и стрим-тв, так что поучить я много чему могу, на самом деле.
По поводу того, что вы старше, так "мальчик" это отнюдь не про возраст.
Ну и касательно того, кому кого учить - money talks, bullshit walks. Какой у вас самый крупный проект? У меня стрим-тв и внутренняя BSS, которая обеспечивает жизнедеятельность стрим-интернет и стрим-тв, так что поучить я много чему могу, на самом деле.
Я не предлагал письками мерятся, я хотел узнать, насколько ваша позичия подкреплена реальным опытом. Социальный wannabe проект в этом плане серьёзно проигрывает системе, держащей большую часть рынка и имеющей на самой крупной инсталляции >300к пользователей.
И да, я трусливое и хамоватое быдло. Вы мне глаза на меня не открыли, но спасибо за попытку.
И да, я трусливое и хамоватое быдло. Вы мне глаза на меня не открыли, но спасибо за попытку.
Money talks, bullshit walks.
Слив засчитан.
Слив засчитан.
Если внятным ответом ты называешь фразу "ущербную стандартную двухслойную структуру + контроллер, подключающий модули" и пару абзацев про логику и слой данных, из которых становится понятно, то ты не слышал про то, что такое CRUD и не видел баз кроме MySQL, то спешу тебя расстроить, это не только не внятный, но ещё и не ответ, просто потому, что вопрос я тебе никакой не задавал.
Незнание основ в связке с личными оскорблениями, стрелочной терминологией и кармодрочкой прямым образм подтверждает утверждение том, что зачастую "малолетний долбоёб" это состояние души, а не возраст.
Keep sucking, baby.
И кстати, а чего ты так возбуждаешься от вопросов об опыте работы? Нечего рассказать в тридцатник и поэтому мучительно больно за бесцельно прожитые годы?
Незнание основ в связке с личными оскорблениями, стрелочной терминологией и кармодрочкой прямым образм подтверждает утверждение том, что зачастую "малолетний долбоёб" это состояние души, а не возраст.
Keep sucking, baby.
И кстати, а чего ты так возбуждаешься от вопросов об опыте работы? Нечего рассказать в тридцатник и поэтому мучительно больно за бесцельно прожитые годы?
Да, smarty, flexy и HTML из XML с использованием xslt я не использую. Сейчас на клиентских устройствах используется клиент на основе патченой специально для них версии qt, и никакого HTML и близко нет.
Ух как дядьки разошлись.)))) Опять забыли что кодер программера не поймет))) ТАкая же история с дизайнером—кодером. Когда вот собираются люди работать над проектом, дизайнеры разрабатывают хороший продукт, кодеры делают хороший код, программеры врезают туда модули.
И дальше по цепочке, а потом все работает и всем нравится.
Чего спорить, работать надо))))
А не раугаться.
Ну ка помиритесь бысренько))))))))))
И дальше по цепочке, а потом все работает и всем нравится.
Чего спорить, работать надо))))
А не раугаться.
Ну ка помиритесь бысренько))))))))))
Ну, об этом я уже говорил выше. К примеру у вас на сайте весь контент (которого, просто огромное количество!!!) находится в таблице. Так вот пока структура таблицы ПОЛНОСТЬЮ не загрузится, в браузере ничего показано не будет. Соответственно если вы все еще на диал-апе (а таких много) то долго будете созерцать пустую картинку в браузере.
Плюс если нужно будет что-либо менять в структуре сайте, то в принципе легче менять если макет на div'ах.
Хотя в целом это уже очень давняя дисскусия, и много на эту тему обсуждений есть. На самом деле все зависит от конкретной цели.
Плюс если нужно будет что-либо менять в структуре сайте, то в принципе легче менять если макет на div'ах.
Хотя в целом это уже очень давняя дисскусия, и много на эту тему обсуждений есть. На самом деле все зависит от конкретной цели.
Пользователей нормальных браузеров меньше, потому что нормальные браузеры не включают в ОС как стандарт.
По поводу того, что нормальный это тот, который популярен, тоже неправда, по той же причине. Многие пользователи IE даже не в курсе что существуют другие браузеры.
По поводу того, что нормальный это тот, который популярен, тоже неправда, по той же причине. Многие пользователи IE даже не в курсе что существуют другие браузеры.
На самом деле любой браузер, в том числе и IE будет сразу отрисовывать всю таблицу, если внутри этой таблицы для всех элементов прописана ширина-высота. Задержки в отображении (и это епархия не только ИЕ) происходят именно из-за расположенных внутри таблицы например картинок. Если картинке прописаны ширина/высота - браузер покажет всю таблицу, и только потом начнет прогружать вложенные элементы.
Хотя div-ая верстка всё-таки лучше. Но не панацея.
Хотя div-ая верстка всё-таки лучше. Но не панацея.
Ушли от табличной верстке к семантической верстке блоками для того, чтобы от них перейти затем к верстке списками. А результат того вообще стоит? Уж лучше тогда таблицы, во всяком случае код получается прозрачнее и проще в сопровождении.
Ну да. Если есть "сетка вёрстки", по которой располагаются элементы, то в каком-то смысле семантичнее использовать таблицу (которая от рождения сетка), т.к. имитировать сетку при помощи деревьев списков это протоворечит здравому смыслу. Скажем есть некая композиция из 6 вертикальных опорных линий и 4 горизонтальных, по которым раскиданы картинки и блоки текста (типичный промо-сайт). Все его красоты всё равно не увидеть в Opera mini и тем более в текстовом браузере... Но это конечно частный случай, для обычных порталов div оправданнее т.к. лучше ведёт себя в нестандартных браузерах (та же Opera Mini) и легче оптимизировать контент под поисковики.
Ну как-то хрен его знает.
А я раньше думал, что семантическая - это значит "по смыслу", т.е. вместо <div id="hd">Header</div> - <h1>Header</h1>, OL, UL - списки, перечисления, меню; "говорящие" тэги сами за себя: address, blockquote, code, и др. А то, что вы показали - как раз совсем не семантический подход.
О каких связях в вашем документе идет речь? h1, h2, h3... не подходят вам для иерархии? Самая лучшая проверка - это отображение сайта в текстовом браузере (lynx). Если в нем сайт смотрится нормально, отслеживается иерархия и связи, то значит семантика вами достигнута. Представьте отображение вашей верстки в lynx'е. Кстати, так его видит поисковый бот.
Но div'ы не могут отобразить структуру документа, для этого семантически более подходят списки, потому как они, в отличие от div'ов передают иерархию и связи, которые присутствуют между элементами.
О каких связях в вашем документе идет речь? h1, h2, h3... не подходят вам для иерархии? Самая лучшая проверка - это отображение сайта в текстовом браузере (lynx). Если в нем сайт смотрится нормально, отслеживается иерархия и связи, то значит семантика вами достигнута. Представьте отображение вашей верстки в lynx'е. Кстати, так его видит поисковый бот.
1. кто будет футер к низу прижимать?
2. у таблиц есть один существенный недостаток - ширины столбцов скачут как попало, не смотря на указанные размеры. table-layout:fixed решает проблему размеров, но емнип там ещё какие-то косяки вылезают...
3. ну и дивы на списки заменять - глупо. див - это элемент без семантики, поэтому его можно спокойно юзать где ни попадя. а вот li - это только для элементов списков (семантически однородных сущностей идущих подряд). шапка, контент и подвал - это совсем не однородные сущности.
2. у таблиц есть один существенный недостаток - ширины столбцов скачут как попало, не смотря на указанные размеры. table-layout:fixed решает проблему размеров, но емнип там ещё какие-то косяки вылезают...
3. ну и дивы на списки заменять - глупо. див - это элемент без семантики, поэтому его можно спокойно юзать где ни попадя. а вот li - это только для элементов списков (семантически однородных сущностей идущих подряд). шапка, контент и подвал - это совсем не однородные сущности.
Расчитывал здесь прочитать комментарии от людей кто воспользовался этой техникой верстки. Ничего полезного не прочитал.
Люди просто обсуждают достоинства и недостатки div и table версток. А также калечность IE. А как же насчет того, что это следующий шаг после div-верстки?
Я скачал страничку и рассмотрел детально.
- Автор использует expression() для задания min-width для IE lte 6. Использовать JS для верстки - в корне не верное решение. У меня вообще этот min-width не сработал для IE. НО! Как бы там ни было я применил свой css-based min-width hack для данной верстки и оно очень хорошо сработало! :)
- http://tjkdesign.com/articles/css-layout… Имеет баг в IE 6. При определенных ширинах экрана правая колонка пропадает напрочь. Похоже дело в том, что при задании ширин колонок типа 33% 33% 33% IE что-то неправильно считает и правая колонка улетает. Решается приблизительно так - одной колонке задается ширина 32.9% или как-то так... :)
-Автор написал о проблемах данной верстки:
В IE lt 7, все width должны быть явно указаны, чтобы секции не вели себя как block-level элементы, так что это решение не поможет вам создать кросс-браузерную верстку с резиновой колонкой (например две жесткой ширины колонки с резиновой средней колонкой). Если именно это вам и нужно, то не отказывайтесь от верстки с float'ами...
Такая верстка не позволит вам поставить контент в начало html кода (необходимо для поисковой оптимизации).
Такая верстка не позволит вам средствами CSS поменять колонки местами, если только вы не переместите их явно в html коде.
ИТОГ: я буду пока использовать div-верстку, а если прочитаю отзывы от людей, практически применивших такую верстку для своих сайтов, и отзывы будут положительные, то я обязательно перейду на ol li.
Люди просто обсуждают достоинства и недостатки div и table версток. А также калечность IE. А как же насчет того, что это следующий шаг после div-верстки?
Я скачал страничку и рассмотрел детально.
- Автор использует expression() для задания min-width для IE lte 6. Использовать JS для верстки - в корне не верное решение. У меня вообще этот min-width не сработал для IE. НО! Как бы там ни было я применил свой css-based min-width hack для данной верстки и оно очень хорошо сработало! :)
- http://tjkdesign.com/articles/css-layout… Имеет баг в IE 6. При определенных ширинах экрана правая колонка пропадает напрочь. Похоже дело в том, что при задании ширин колонок типа 33% 33% 33% IE что-то неправильно считает и правая колонка улетает. Решается приблизительно так - одной колонке задается ширина 32.9% или как-то так... :)
-Автор написал о проблемах данной верстки:
В IE lt 7, все width должны быть явно указаны, чтобы секции не вели себя как block-level элементы, так что это решение не поможет вам создать кросс-браузерную верстку с резиновой колонкой (например две жесткой ширины колонки с резиновой средней колонкой). Если именно это вам и нужно, то не отказывайтесь от верстки с float'ами...
Такая верстка не позволит вам поставить контент в начало html кода (необходимо для поисковой оптимизации).
Такая верстка не позволит вам средствами CSS поменять колонки местами, если только вы не переместите их явно в html коде.
ИТОГ: я буду пока использовать div-верстку, а если прочитаю отзывы от людей, практически применивших такую верстку для своих сайтов, и отзывы будут положительные, то я обязательно перейду на ol li.
О какой семантике такого решения может идти речь? Что у div, что у списков единственная семантика здесь - вложенность. Во всех прочих отношениях они выполняют исключительно роль контейнеров и "параллельны" содержанию.
а что, еще есть люди, которые используют ie for mac?
Не понял чем плохи флоаты? Никаких катастрофических глюков не встречал.
Списки для структуры - имхо большая семантическая ошибка.
А что если у элементов создающих табличную сетку будет фон или бордеры??? Тогда в ie все будет совершенно по-другому (имею в виду высоту псевдоячеек).
Имхо можно будет использовать, когда ie начнет поддерживать display: table;
За статью спасибо.
Списки для структуры - имхо большая семантическая ошибка.
А что если у элементов создающих табличную сетку будет фон или бордеры??? Тогда в ie все будет совершенно по-другому (имею в виду высоту псевдоячеек).
Имхо можно будет использовать, когда ie начнет поддерживать display: table;
За статью спасибо.
лучше бы текст нормальными заголовками оформили, честное слово, смешно читать текст о семантике, размеченый комбинацими <br /> и <strong> вместо заголовков
по тексту, мне представляется несколько сомнительным использование списков для разметки страницы. Страница представляет собой всё же отдельные блоки информации, которые уже объединены <body>. Зачем их лишний раз связывать, не совсем понял. Возможно хорошая замена врапперу, конечно… Не знаю, напоминает, лично мне, велосипед с лишним колесом
по тексту, мне представляется несколько сомнительным использование списков для разметки страницы. Страница представляет собой всё же отдельные блоки информации, которые уже объединены <body>. Зачем их лишний раз связывать, не совсем понял. Возможно хорошая замена врапперу, конечно… Не знаю, напоминает, лично мне, велосипед с лишним колесом
Объясните дураку, почему списки более семантичны для вёрстки, чем таблицы?
По-идее в соответствии с семантикой, списки нужно использовать для списков, разве нет?
По-идее в соответствии с семантикой, списки нужно использовать для списков, разве нет?
Вот я тоже пока читал об этом думал.
Сначала, когда все хором начали переходить с табличной верстки на дивы главным аргументом было, то что таблицы — для табличных данный, а блоки — для разметки. А ведь список — это такой же элемент, для свойственных ему данных, это если отталкиваться от вышеописанных суждений.
Сначала, когда все хором начали переходить с табличной верстки на дивы главным аргументом было, то что таблицы — для табличных данный, а блоки — для разметки. А ведь список — это такой же элемент, для свойственных ему данных, это если отталкиваться от вышеописанных суждений.
Кроме описанных выше способов верстки, есть еще один эффективный, но к сожалению редко используемый - div'ы с отрицательными отступами. Использование этого метода обеспечивает:
В общем виде шаблон страницы имеет вид:
Также легко реализуется прижатие футера к низу страницы, независимо от высоты контента.
40 готовых лейаутов, выполненных с помощью этой техники можно посмотреть и скачать здесь: http://blog.html.it/layoutgala/
- Валидный HTML и CSS
- Совместимость с браузерами Internet Explorer/win 5.0, 5.5, 6, 7; Opera 8.5+, Firefox 1.5+, Safari 2.
- Семантический код.
В общем виде шаблон страницы имеет вид:
<div id="container">
<div id="header">Header</div>
<div id="wrapper">
<div id="content">Content</div>
</div>
<div id="navigation">Navigation</div>
<div id="extra">Extra stuff</div>
<div id="footer">Footer</div>
</div>
Также легко реализуется прижатие футера к низу страницы, независимо от высоты контента.
40 готовых лейаутов, выполненных с помощью этой техники можно посмотреть и скачать здесь: http://blog.html.it/layoutgala/
По этим шаблонам уже не первый год верстаю.
Скрещиваю их когда нужно с абсолютным футером и все)
По теме — прием конечно надо знать, в определенных случаях бывает полезно
Скрещиваю их когда нужно с абсолютным футером и все)
По теме — прием конечно надо знать, в определенных случаях бывает полезно
Я пользуюсь этой техникой и честно говоря прижимать к низу так очень не удобно, хотя и вполне реально, вообще-то я себе и не представляю плавающую модель без отрицательных полей.
Статья - альтернативный взгляд на очевидные вещи. Спасибо.
Я лично такой конструкцией пользоваться не буду, т.к. вполне устраивает "плавающая модель".
Хотя после статьи посмотрел в спецификацию. :)
Что до "специфичных вещей" и интересных свойств "display". В спецификации их( свойств) много, причем много вкусных и интересных. Но! ie6 их не понимает! И пока он( ie6 ) не "умрет" об этих свойствах стоит забыть, т.к. браузер ie6 - это больше половины пользователей!
Небольшой оффтоп. Сорри, но просто наболело.
Скажу вам такую вещь: пользуйтесь id для верстки как можно реже. А лучше вообще не пользуйтесь! Для верстки есть селектор "class". Просто когда я вижу использование id не для своих целей - это уже не семантическая верстка!
Я лично такой конструкцией пользоваться не буду, т.к. вполне устраивает "плавающая модель".
Хотя после статьи посмотрел в спецификацию. :)
Что до "специфичных вещей" и интересных свойств "display". В спецификации их( свойств) много, причем много вкусных и интересных. Но! ie6 их не понимает! И пока он( ie6 ) не "умрет" об этих свойствах стоит забыть, т.к. браузер ie6 - это больше половины пользователей!
Небольшой оффтоп. Сорри, но просто наболело.
Скажу вам такую вещь: пользуйтесь id для верстки как можно реже. А лучше вообще не пользуйтесь! Для верстки есть селектор "class". Просто когда я вижу использование id не для своих целей - это уже не семантическая верстка!
Аргументируйте, пожалуйста, свою позицию по поводу использования class вместо id.
Для верстки id менее подходит. Например.
1. Нельзя объеденять стили нескольких айдишек для одного элемента.
То есть так работать не будет:
А так будет:
2-е айдишка приоритетнее класса. То есть используя айдишки вместо классов - я лишаю себя менее приоритетного( class ) и оставляю только более приоритетное
3-е с классами можно сделать один блок и потом его размножить. С айди - так нельзя.
Например такое легко можно размножить( то есть скопипастить один и тот же блок в футер и хедер, не меняя и запятой)
Section 1
Section 2
Section 3
Я понимаю, каждый разрабатывает как ему/ей удобно. Но айди оставляю для программистов. И считаю классы более гибкими и удобными. Хотя бы в силу описанного выше.
1. Нельзя объеденять стили нескольких айдишек для одного элемента.
То есть так работать не будет:
А так будет:
2-е айдишка приоритетнее класса. То есть используя айдишки вместо классов - я лишаю себя менее приоритетного( class ) и оставляю только более приоритетное
3-е с классами можно сделать один блок и потом его размножить. С айди - так нельзя.
Например такое легко можно размножить( то есть скопипастить один и тот же блок в футер и хедер, не меняя и запятой)
Section 1
Section 2
Section 3
Я понимаю, каждый разрабатывает как ему/ей удобно. Но айди оставляю для программистов. И считаю классы более гибкими и удобными. Хотя бы в силу описанного выше.
Мда. Теги скушало. Код для 1-го
Айдишки так использовать нельзя $lt; div id="contentArea subPage " >
Классы так использовать можно $lt; div class="contentArea subPage " >
Пример кода для 3-го пункта
$lt; div class="contentArea " >
$lt; div class="contentArea subPage " >
$lt; div class="sub1 " >Text1$lt; ⁄ div >
$lt; div class="sub2 " >Text2$lt; ⁄ div >
$lt; div class="sub3 " >Text3$lt; ⁄ div >
$lt; ⁄ div >
Айдишки так использовать нельзя $lt; div id="contentArea subPage " >
Классы так использовать можно $lt; div class="contentArea subPage " >
Пример кода для 3-го пункта
$lt; div class="contentArea " >
$lt; div class="contentArea subPage " >
$lt; div class="sub1 " >Text1$lt; ⁄ div >
$lt; div class="sub2 " >Text2$lt; ⁄ div >
$lt; div class="sub3 " >Text3$lt; ⁄ div >
$lt; ⁄ div >
вы не совсем привыкли к специфичности, судя по всему
попробуйте сочетать ID и CLASS
если у вас есть блок содержимого какой-то области на под странице (?)
то так и говорите, что это ID=contentArea CLASS=subPage
кстати, очень удобно задавать классы и идентификаторы у тела документа
на данный момент лично мой фаворит, вот такая модель:
т. е. для заглавной страницы Яндекса, к примеру я бы сделал вот так:
CSS подпись для тех, кто захочет переопределить стили для моего сайта в своём браузере
вобщем это единственное полезное что я вычитал и "Пуленепробиваемого веб-дизайна" :D
попробуйте, мне кажется вам понравится
попробуйте сочетать ID и CLASS
если у вас есть блок содержимого какой-то области на под странице (?)
то так и говорите, что это ID=contentArea CLASS=subPage
кстати, очень удобно задавать классы и идентификаторы у тела документа
на данный момент лично мой фаворит, вот такая модель:
<body id="css-signature" class="typeofthepage">т. е. для заглавной страницы Яндекса, к примеру я бы сделал вот так:
<body id="yandex-ru" class="index">CSS подпись для тех, кто захочет переопределить стили для моего сайта в своём браузере
вобщем это единственное полезное что я вычитал и "Пуленепробиваемого веб-дизайна" :D
попробуйте, мне кажется вам понравится
Я же не призываю совсем отказываться от айдишек!
Более того, с вами абсолютно согласен, что для некоторых вещей надо использовать айди. Как в примере с появляющимся/скрываемым блоком, динамически меняющимся содержимым, и еще море примеров... Тут только айди.
Моя ремарка была к тому что не надо путать айдишки и классы. И смотреть что и где лучше и удобнее применять.
Такой вопрос. А что вы подразумеваете под специфичностью? Сайты "под несколько языков", сайты под различные агенты( например КПК)... что?
Более того, с вами абсолютно согласен, что для некоторых вещей надо использовать айди. Как в примере с появляющимся/скрываемым блоком, динамически меняющимся содержимым, и еще море примеров... Тут только айди.
Моя ремарка была к тому что не надо путать айдишки и классы. И смотреть что и где лучше и удобнее применять.
Такой вопрос. А что вы подразумеваете под специфичностью? Сайты "под несколько языков", сайты под различные агенты( например КПК)... что?
xорошая статейка..
может кому поможет.
может кому поможет.
А мне кажется, что эта схема не имеет права на жизнь.
Как-то 2 года таму назад, когда я искал первую работу, одно крупной Ростовское интернет-агентство предложило выполнить мне тестовое задание таблицами и дивами, тогда мне только исполнилось 18 и о верстке дивами я разве что слышал, начал искать материалы, ничего не нашел...потом мне самому пришла в голову мысль сделать именно так, как в примере...это первый и последний раз когда я так делал, ибо это просто замусоревание css-кода.
О тактико-технических характеристиках данной схемы:
Размер html-кода - как при табличной верстке
Размер css-кода - огромный
Семантика html-кода - как при табличной (у автора видимо неправильное понимание слова "семантика")
Сематика css-кода - отсутствует
Понятность кода - отсутствует
По сути является табличной версткой, только мы ещё берем на себя часть работы браузера, создавая свою таблицу.
Предлагаю ещё 2 метода:
1) давай те сделаем новую БОЛЕЕ СЕМАНТИЧНУЮ плавающую модель
<table><tr><td>1 блок</td><td>2 блок</td></tr></table>
css:
table {display: block;}
tr {display: block;}
td {display: block; float: left; width: 50%;}
2) Или вот ещё классный вариант избежать путаницы с class и id, давайте их просто не использовать XHTML позволяет нам создовать свои теги, давайте воспользуемся этими возможностями и напишем:
<header>
<left>Блок 1</left>
<left>Блок 2</left>
</header>
css:
header {display: block; width: 100%;}
left {display: block; float: left; width: 50%;}
Да, конечно пострадает валидность, зато очень короткий и действительно семантичный код.
З.Ы. а вообще каждый сам для себя решает, как ему делать, главное результат: если Ваша верстка будет легко встраиваться в CMS, будет всем понятна и будет работать в браузерах через 20 лет, то наплюйте на все советы :)
Как-то 2 года таму назад, когда я искал первую работу, одно крупной Ростовское интернет-агентство предложило выполнить мне тестовое задание таблицами и дивами, тогда мне только исполнилось 18 и о верстке дивами я разве что слышал, начал искать материалы, ничего не нашел...потом мне самому пришла в голову мысль сделать именно так, как в примере...это первый и последний раз когда я так делал, ибо это просто замусоревание css-кода.
О тактико-технических характеристиках данной схемы:
Размер html-кода - как при табличной верстке
Размер css-кода - огромный
Семантика html-кода - как при табличной (у автора видимо неправильное понимание слова "семантика")
Сематика css-кода - отсутствует
Понятность кода - отсутствует
По сути является табличной версткой, только мы ещё берем на себя часть работы браузера, создавая свою таблицу.
Предлагаю ещё 2 метода:
1) давай те сделаем новую БОЛЕЕ СЕМАНТИЧНУЮ плавающую модель
<table><tr><td>1 блок</td><td>2 блок</td></tr></table>
css:
table {display: block;}
tr {display: block;}
td {display: block; float: left; width: 50%;}
2) Или вот ещё классный вариант избежать путаницы с class и id, давайте их просто не использовать XHTML позволяет нам создовать свои теги, давайте воспользуемся этими возможностями и напишем:
<header>
<left>Блок 1</left>
<left>Блок 2</left>
</header>
css:
header {display: block; width: 100%;}
left {display: block; float: left; width: 50%;}
Да, конечно пострадает валидность, зато очень короткий и действительно семантичный код.
З.Ы. а вообще каждый сам для себя решает, как ему делать, главное результат: если Ваша верстка будет легко встраиваться в CMS, будет всем понятна и будет работать в браузерах через 20 лет, то наплюйте на все советы :)
Хмм.. а есть ли способ создавать свои теги, сохраняя при этом валидность? Кроме XML-XSLT, конечно.
честно говоря, не знаю, да и по-большому счету не считаю такое построение правильным, это преведет к очередному мусорнику в таблицах стилей, ведь браузер в любом случае сначала определяет стандартные стили для всех определенных в нем тегов, переопределяя их мы во-первых создаем ещё один мусорник (ведь для каждого нововведенного тега необходимо указать все стандартные свойства типа overflow), а во-вторых браузер будет напрасно работать инциализируя сначала "нормальные теги", потом нововведенные.
Я считаю, что правильнее всего по-максимум пользоваться тем, что тебе дали разработчики браузера, все необходимы виды тегов уже существуют и подбирая для каждого конкретного случая наиболее подходящий мы как раз и добиваемся симантичности, понятности и малых размеров кода.
Я считаю, что правильнее всего по-максимум пользоваться тем, что тебе дали разработчики браузера, все необходимы виды тегов уже существуют и подбирая для каждого конкретного случая наиболее подходящий мы как раз и добиваемся симантичности, понятности и малых размеров кода.
соглашусь практически со всеми, что такая разметка уж чересчур. у списков есть своё предназначение, а именно - построение списков, а не структуры документов.
так же улыбнуло, что автору не нравится юзать при вёрстке дивами хаки, но сам же тут себе и противоречит приводя теже самые хаки.
пока что лучше дивов с флоатами ничего не придумано. и не надо так бояться использовать таблицы, если они там к месту и логически подходят, то не надо извращаться дивами и как тут списками.
так же улыбнуло, что автору не нравится юзать при вёрстке дивами хаки, но сам же тут себе и противоречит приводя теже самые хаки.
пока что лучше дивов с флоатами ничего не придумано. и не надо так бояться использовать таблицы, если они там к месту и логически подходят, то не надо извращаться дивами и как тут списками.
спасибо за статью! сам уже как месяц-два назад столкнулся с этим... пока что все устраивает =)
Разметка структуры документа через списки - плохо. Выше уже все сказано.
Почему id плохо, см., например, позицию web-разработчиков из Яндекса (сам подход спорный, но про class и id все правильно).
Добавлю от себя ворчание про * {margin:0;padding:0;} - см. reset.css
А одним из лучших трехколоночных layout'ов считаю вариант Matthew James Taylor.
Почему id плохо, см., например, позицию web-разработчиков из Яндекса (сам подход спорный, но про class и id все правильно).
Добавлю от себя ворчание про * {margin:0;padding:0;} - см. reset.css
А одним из лучших трехколоночных layout'ов считаю вариант Matthew James Taylor.
Чем же он спорный? Давайте поспорим.
Здравствуйте. Не хочу спорить. :)
Скорее специфика повседневных задач, у кого-то помельче, у кого-то покрупнее - не у всех случаются два футера.
Если заказчик использует какой-нибудь wysiwyg (боже упаси), уж лучше я задам общие стили для контента от id, на душе спокойнее.
С однотипной версткой не все так просто. Вот я часто использую dl списки для блоков с кратким представлением.
Скорее специфика повседневных задач, у кого-то помельче, у кого-то покрупнее - не у всех случаются два футера.
Если заказчик использует какой-нибудь wysiwyg (боже упаси), уж лучше я задам общие стили для контента от id, на душе спокойнее.
С однотипной версткой не все так просто. Вот я часто использую dl списки для блоков с кратким представлением.
150 комментариев и никого не удивило слово "Елементы"?
Согласен со мнением большинства. Использование списков в качестве разметки страницы никак нельзя назвать семантически верным.
взглянув на название статьи я уж было обрадовался что автор расскажет о порочной практике использования div {float: left} вместо ячеек таблиц (вот как раз щас переделываю с нуля нормальной вёрсткой один такой проектик: насчитал 20(!!) вложенных друг в друга блоков, ужас!..
а вместо этого - второй такой же вредный способ строительства.
плохому учите
а вместо этого - второй такой же вредный способ строительства.
плохому учите
матерь божья
это, господа, пипец полный.
Но div'ы не могут отобразить структуру документа, для этого семантически более подходят списки, потому как они, в отличие от div'ов передают иерархию и связи, которые присутствуют между элементами.
это, господа, пипец полный.
Верстать всё подряд в table, li или div - идиотизм! Работать надо с каждым элементом по его главному предназначению. Если надо таблицу построить - table, если меню или любой другой список - ul & ol, если надо отдельный блок или обёртку - div, если новости - dt.
Второй пример под IE 6 на маленьких разрешениях проваливается — верхняя граница начинает разваливаться
Свойства CSS надо использовать по предназначению. Свойство FLOAT, предназначено для обтекания...
Эелементы списка в HTML предназначены для списков.
Вообще прием который описан статье ... просто не практичен.
Эелементы списка в HTML предназначены для списков.
Вообще прием который описан статье ... просто не практичен.
Смущает это: No div, no float, no clear, no hack*, no joke!
м в самом коде это:
не такой уж это No div.
м в самом коде это:
не такой уж это No div.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Верстка без float'ов