lexxcode

Нормально. примерно неделя, как и в тот раз, собственно

21 Декабря

В спеке в примерах есть вообще вариант оборачивания тегом nav сплошного текста вперемешку с ссылками, так что думаю ничего плохого в твоем варианте подавно

А ну так это еще тогда обсудили, и пришли к выводу что то не корректная трактовка идеи Мейера

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

Никто не говорит, что строить лейаут на float это корректно, а те кто так говорит просто что-то не то съели прочитали. Проблема тут лежит в другом, что до недавнего времени не было специальных методов для построения именно лейаута, следовательно разработчики крутились как могли. Ну так давай цитату, что ты там вычитал и обсудим, не вопрос Начнем с того, что css не навязывает каскадность, так же как БЭМ не навязывает отказ от нее же. Мне допустим БЭМ тоже не очень то по душе, но заложенный в него принцип независимых блоков позволяет решать ряд задач, которые с применением излишней каскадности решать по меньшей мере неудобно.

дали бы хоть ссылку на проблему

Тогда шла речь о футере. про меню, в данном случае, я ничего не говорю

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

Great Rash, кстати, в твоем примере overflow: visible; дает не тот результат который бы хотелось, собственно это и понятно. В данном случае тут проблема не в overflow, а в том, что старые IE не умеют переносить текст в кнопке. (по крайней мере в эмуляторе не хочет ни под каким видом) По-моему логичнее делать так margin :10px 0 - схлопывающиеся отступы и все такое)... Мне тоже кажется это более правильным, учитывая что и браузеры используют этот подход по-умолчанию. Но дзен двухсторонних маргинов мне пока что не поддался в полной мере. Так как верхний маргин доставляет проблемы в крайних позициях, когда контактирует с границей своего родителя. Так что я пока склонен применять вариант товарища Great Rash. Но экспериментирую и с двухсторонними маргинами

Так правильно, именно так и должно быть. Неправильно делать так: /* reset.css */h1, h2, h3, h4, h5, p { margin: 0;}/* main.css */h1, h2, h3, h4, h5, p { margin: 0 0 10px;}А у большинства кто использует сброс Мейера именно такая ситуация и получается

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

Мне интересно посмотреть на пример с проблемой. Правда у меня IE11, все остальное в режиме эмуляции А не, есть IE8 на vbx Ну в целом, да. Я как-то сильно категорично выразился. И да это уже не ресет, а кастомный нормалайз, типа Таблички в ресетах, это вообще боль и глубокая травма Это принесло оооочень много проблем, в свое время, пока не отказался от этого. И не только с округлением углов

Отсутствие этих свойств у меня не вызывало проблем в IE8- никогда, прям вообще. Ну да, в IE11 тоже hidden, вместо visible, если бы ты не сказал, я бы и не вспомнил об этом, ибо проблем это не доставляет. Кнопки с вылезающими за границы иконками не часто встречаются (может это мне так везет, конечно), но если и встретится, то ничего не мешает добавить это свойство. Зачем его постоянно таскать за собой по всюду, я не очень понимаю

А ты уверена, что тебе это там нужно? Судя по дизайну, я более чем уверен, что оно будет именно так как нарисовано (плюс-минус косметические изменения текста). Какой смысл городить непонятно что еще и мучиться и тратить лишнее время?

button { position: relative; overflow: visible;}pos:r - бывает нужен по ситуации, но далекоо не всегда. ov:v - бессмысленная запись, ибо оно и так visible по-умолчанию, да и необходимости переопределять это свойство, даже чем-то другим, совершенно нет. button::-moz-focus-inner { padding: 0; border: 0;}Да полезное свойство, но снова таки, в 95% случаев спокойно обходится и без него, в оставшихся случаях оно сугубо индивидуально подстраивается под конкретный тип кнопок. Так что обобщать это незачем, но иногда бывает полезно, да. Давай дальше

Получается, что идеология смарти-подобной шаблонизации не мне одному кажется более адекватной. это радует

Опять таки, это есть какие-то вменяемые шаблонизаторы используются, а-ля привычный html + прикольные_фишки_дополняшки, то что есть в ejs и Smarty (есть и другие, да, но лично я работал только с ними ). А взять те же темы для Wordpress, или, чего хуже, для Joomla, или, подстрелите меня, для Bitrix, то тут без килограмма кофеина не разобраться. Очень много специфичных вещей, с которыми фронтендер не сталкивается в принципе

Это не вопрос религии, а вопрос здравого смысла. Я уже 100500 раз говорил, скажу ещее раз. Ресет это бесполезный кусок стилей. Объяснял это я тоже 100500 раз. Normalize, по сути тоже весьма бесполезен, но в нем хотя бы смысла заведомо больше заложено. Если именно сам Normalize адаптировать под конкретный проект, а не просто кидать как есть и потом все переопределять, то еще куда ни шло.

С просветлением (никакого сарказма, искренне рад твоим успехам )

А с каких это пор в задачи верстальщика входит натяжка верстки на cms? Его задачей является создание грамотной верстки, которую потом без переделок можно будет порезать в шаблон, руками программиста. Да программист не должен особо задумываться о том, что что-то не подходит. Если ему что-то не подходит или не понимает в верстке, то го к верстальщику обсуждать нюансы. А там уже или верстальщик донесет, что к чему, или переделает так, чтобы это было удобно программисту. Другое дело, что в шаблонах smarty или ejs среднестатистический верстальщик разберется с полпинка, в принципе такие задачи можно положить на плечи верстальщика. Он будет заниматься, по прежнему, разработкой в своей среде с небольшими дополнениями. Программисту останется организовать окружение с переменными, которые будет использовать верстальщик. Как по мне, такой подход самый удобный для всех.

ничего по этому поводу не указано, видимо так можно

Кто же мешает?

У меня сейчас очередной период поиска новых путей и комбинаций, люблю я, знаете ли, поэкспериментировать. Принцип подобный БЭМовскому, только компактнее малость и с небольшим дополнением. Примерно так: <div class="block"> <div class="block-element"></div> <div class="block-element_modificator"></div></div>В последнее время стал отделять еще такое понятие как состояние, то что в БЭМ так же решается при помощи модификатора. <button class="btn">Default</button><button class="btn warning">Warning</button><button class="btn danger">Danger</button>в БЭМ это выглядело бы как-то так: <button class="b-btn">Default</button><button class="b-btn b-btn__warning">Warning</button><button class="b-btn b-btn__danger">Danger</button>Вообще в будущем хочу отказаться и от принципа описания модификаторов в синтаксисе с нижним подчеркиванием, в пользу какого-то другого формата. В принципе во всем, что я описал выше, нет ничего особо нового просто попытка найти лучшие пути, комбинируя и экспериментируя

Я пробовал одно время БЭМ довольно активно, правда без тулзов ихних всяких. Была давно весьма горячая тема даже о БЭМе. Как идея и концепция хороша, но реализация через задницу, имхо. В итоге остался на подходе подобному классическому АНБ.