Комментарии 83
Хороший подход к верстке.
А идея мне нравится, надо будет попробовать в использовании
Для этого нужно сначала сформулировать и запустить проект. Пока желающих нет(
Я готов помочь чем смогу
Вы верстаете? дизайните?
К счастью нет ) Программирую я, с CSS конечно знаком, но не уровень верстальщика.
Мне, как программисту, такое очень надо. Создавая свои проекты, даже прототипы, всегда обидно, что выглядят они некрасиво, а мастерства сделать это лучше нету пока.
Ох… в последнее время столько хороших заметок. закладки нещадно растут.
Еще одна статья «под звездочку». Спасибо.
Еще одна статья «под звездочку». Спасибо.
Аналогично. Бывает пишешь админку, написал виев, а css писать лень, ибо верстаю плохо.
Для шапки сайта, в html5, используется
header, а не head. Поправьте пожалуйста.
А вы уверены что стоит использовать тег menu? Может быть лучше nav?
Да, возможно, nav лучше…
А вы на подскажете, чем они отличаются?
А вы на подскажете, чем они отличаются?
Разницы между классом «nav» и «menu» нету совершенно ни какой.
Просто каждый называет классы по разному и в итоге ни какой разницы нету, это конкретнео пожелание одного человека, но не более.
Равно сильно как и в верху упомянули вместо «head» использовать «header».
Разницы нету ни какой, класс вообще можно назвать как угодно, хоть просто «shapko» и разницы в отображении ни какой не будет.
Просто каждый называет классы по разному и в итоге ни какой разницы нету, это конкретнео пожелание одного человека, но не более.
Равно сильно как и в верху упомянули вместо «head» использовать «header».
Разницы нету ни какой, класс вообще можно назвать как угодно, хоть просто «shapko» и разницы в отображении ни какой не будет.
Из спецификации HTML5:
А вот menu — это «совсем не то»:
The menu element represents a list of commands.
Если полистаете спецификацию ниже, увидите — примение у menu совершенно не такое, как у nav. Вот, скажем, здесь, на хабре, кнопки под полем для ввода комментария или кнопки голосования — это то, что можно поместить в menu. А nav — почти все ссылочные блоки.
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element.
А вот menu — это «совсем не то»:
The menu element represents a list of commands.
Если полистаете спецификацию ниже, увидите — примение у menu совершенно не такое, как у nav. Вот, скажем, здесь, на хабре, кнопки под полем для ввода комментария или кнопки голосования — это то, что можно поместить в menu. А nav — почти все ссылочные блоки.
я думаю это все же разные вещи
меню — это меню
навигация — это строки вида «главная — список элементов — элемент»
меню — это меню
навигация — это строки вида «главная — список элементов — элемент»
Я согласен. Лучше сделать для html4 обёртку div.nav, а для html5 — элемент nav. Внутри вложенный список ul.
Подобный метод «раскраски» как-правило применяется в корпоративных сайтах. Например logitech.ru. Разве-что подача немного отличается от вашей. Думаю, к этому моменту подходят любые серьёзные веб-девелоперы, у которых проектов более чем 10-20. Тут-то и появляются специфичные для верстки , и прочее прочее прочее.
Теперь должен отметить, что попытка создать универсальную библиотеку это хорошая идея. Но большинство будет верстать именно так как привыкло, потому что схема, раз встретившаяся повторяется в нескольких курируемых проектах.
Также должен заметить, что проекты, как-правило специфичны, поэтому часть правил всё-равно будет изменено. Зачастую это даже логично и удобно. Например, вышеприведённый отлично подходит для того же logitech, так как является его фирменным цветом, в других преоктах будет .
Теперь должен отметить, что попытка создать универсальную библиотеку это хорошая идея. Но большинство будет верстать именно так как привыкло, потому что схема, раз встретившаяся повторяется в нескольких курируемых проектах.
Также должен заметить, что проекты, как-правило специфичны, поэтому часть правил всё-равно будет изменено. Зачастую это даже логично и удобно. Например, вышеприведённый отлично подходит для того же logitech, так как является его фирменным цветом, в других преоктах будет .
Парсер съел все мои теги).
Тут-то и появляются специфичные для верстки [b class=«green»][/b], [div class=«sideleft»][/div], и прочее прочее прочее.
Например, вышеприведённый [b class=«green»][/b] отлично подходит для того же logitech, так как является его фирменным цветом, в других проектах будет [b class=«red/yellow/blue/etc»][/b].
Тут-то и появляются специфичные для верстки [b class=«green»][/b], [div class=«sideleft»][/div], и прочее прочее прочее.
Например, вышеприведённый [b class=«green»][/b] отлично подходит для того же logitech, так как является его фирменным цветом, в других проектах будет [b class=«red/yellow/blue/etc»][/b].
Спасибо за конструктивизм)) Во-первых, применение CSSL мне видится не совсем в продакшне, то есть это — база для дизайна, а не сам дизайн. Самим дизайном это может быть уместно лишь, наверное, на личных сайтах и во всяческих админках. Во-вторых, основная идея — их две — это используй современные технологии и не забивай голову специфическими классами (большинство приведённых в тексте поста классов совпадают с тегами HTML5). В-третьих, в идеале — создание библиотеки готовых CSS'ок ))
Тут-то и появляются специфичные для верстки b class=«green», div class=«leftside», div class=«rightside», и прочее прочее прочее.
Например, вышеприведённый b class=«green» отлично подходит для того же logitech, так как является его фирменным цветом, в других прoектах будет b class=«red/blue/white/etc».
Парсер съел теги.
Например, вышеприведённый b class=«green» отлично подходит для того же logitech, так как является его фирменным цветом, в других прoектах будет b class=«red/blue/white/etc».
Парсер съел теги.
ИМХО, имена классов типа «green», «big» и т.д. демонстрирует совершенно неправильное применение css и непонимание его сути. Классы должны описывать не то, как элемент выглядит, а то, чем он является. Тогда не надо будет, если потребуется сделать заколовки красными вместо зеленых, переписывать во всем коде имена с «green» на «red».
Но этот флеш-ролик на logitech.ru просто убивает и сводит на нет всю работу веб-девелоперов. С жутко тормозящего сайта в последнем ФФ на нормальной конфигурации компьютера хочется уйти
В целом, штука замечательная. Спасибо. :)
Лично мне очень нравится использование «независимых блоков», о которых рассказывал Виталий Харисов.
vitaly.harisov.name/article/independent-blocks.html
Но публичного фреймворка с независимыми блоками пока нет. Как знать, быть может, что вы начнете его создавать %)
vitaly.harisov.name/article/independent-blocks.html
Но публичного фреймворка с независимыми блоками пока нет. Как знать, быть может, что вы начнете его создавать %)
красивая утопия :)
«Аоследовательность» — поправь
Мне кажется, что при использовании вложенных меню кроме класса li.active необходим еще класс, который указывает путь в меню. Например:
<li>item 1</li>
<li class="path">item 2
<ul>
<li>item 2-1</li>
<li class="active">item 2-2</li>
<li>item 2-3</li>
</ul>
<li>item 3</li>
<li>item 4</li>
<li>item 1</li>
<li class="path">item 2
<ul>
<li>item 2-1</li>
<li class="active">item 2-2</li>
<li>item 2-3</li>
</ul>
<li>item 3</li>
<li>item 4</li>
Любопытно: Вы отбили красные строки. Пробелами.
input.checkbox, input.button, input.submit — почему не использовать input[type=checkbox], input[type=....] и т.д.?
Мне, как программисту, это очень интересно. Но есть большое НО! Пока есть шестой ИЕ и для него надо писать отдельный css чтобы он отрабатывал «правильно» (а это отнимает не малое время), придется смериться что данная проблема останется… гребаный ИЕ6…
поправьте «должна находиться перед div.dection (section)»
А есть ли тут, на хабре, верстальщики или дизайнеры, которые хотели бы поучаствовать?
А почему доктайп XHTML 1.0, а не
<!DOCTYPE>?
Вообще-то тэг menu есть и в 4.0 и в 4.1(может и в 3 и в 2, не смотрел) html, хотя он там deprecated.
10.4 The DIR and MENU elements
DIR and MENU are deprecated.
Весело, правда?
10.4 The DIR and MENU elements
DIR and MENU are deprecated.
Весело, правда?
Ну ивообще я не понял, что вы сделали. Как по мне это просто стандартные стили на ваш вкус. В чем продвинутость, «фрэймворкность»?
Т.е. вы просто поменяли стадартный css на свой. Плюс добавили несколько классов.
Я что-то не понял наверное в сути.
Т.е. вы просто поменяли стадартный css на свой. Плюс добавили несколько классов.
Я что-то не понял наверное в сути.
Идеи очень похожи на m5 css framework. Сначала сброс, потом прописываем все тэги. На текущем проекте использую его, при этом добавляя свои стили для таблиц, меню и др. элементов, которые недостаточно прописаны в данном фреймворке. В результате получается примерно тоже, что и у вас, только больше ориентированное под конкретный дизайн.
Что-то не очень понял суть этого фреймворка…
Посмотрите пример. Тот же простой html в основе + описание основных тэгов. Добавьте к этому описания недостающих тэгов и классы для новых элементов и получите свою идею. Подойдет как основа для развития ваших идей.
В Style #2 заголовки прижимаются к таблицам. Мне кажется вы пытаетесь разрешить отступ заголовка через стиль абзаца p { padding-bottom: 22px; }. Не лучше ли использовать h2, etc { margin-top:… }?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Раскрась свои теги. CSSL