Блок — независимый от окружения компонент. Он не может рассчитывать на то, что стили сброшены какими-то внешними по отношению к блоку средствами.

Но если стили по факту сброшены, что плохого случится с блоком, который "даже не расчитывал"?

С блоком ничего плохого не случится, но:

1. В ресете не остается смысла, если все блоки работают без него. Это просто лишний код, который придется доставлять клиенту.
2. Ресет — это точно такие же глобальные стили, от которых БЭМ рекомендует отказаться. Почему для ресета нужно исключение?
3. Если не обращать внимания на скорость рендеринга, то как минимум все эти стили мешаются в веб-инспекторе при разработке.

В своих проектах мы часто использовали блок reset-css https://github.com/factorymn/bem-factory/tree/master/common.blocks/reset-css

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

В нем остается нужда только если нужно собрать страницу заглушку супер быстро в которой НЕ будут использованы уже разработанные блоки.

Ещё момент: после ресета невозможно вернуть стили в состояние по умолчанию. А иногда это бывает надо. Мы с этим нахлебались при вёрстке Яру и Почты, когда надо было показывать внешний HTML as is.

Вопрос хороший и толкового ответа на апельсинах так и не увидел. Reset.css, как вы сами знаете, делает сброс стилей, отменяя стили браузера по-умолчанию. normalize.css - наоборот приводит свойства разных тегов к их значениям по-умолчанию. Хотя reset и normalize делают разные вещи, в целом благодаря использованию одного из них мы гарантированно избавляемся от одной проблемы - любой тег в любом браузере будет иметь одинаковые свойства и их значения. Если же отказаться от reset-а или normalize-а, то возникают следующие вопросы к тем, кто предлагает от них отказаться: 1) скажем, заюзав reset, мы всегда знаем, что у тега

значение margin будет равно 0 ВО ВСЕХ браузерах. Если же мы не будем использовать reset, то мы, посмотрев, что в спецификации для тега

значение margin равно margin:20px 0, решили, что поскольку элементу

как раз такое значение margin и надо, то в стилях этого элемента ничего для margin не прописывали. Все вроде здорово, но завтра один из браузеров выпускает новую версию своего браузера и плюет на спецификацию и делает значение margin для тега

уже не 20px 0, а 30px 0. И все, теперь наш абзац новости в разных браузерах выглядит по-разному. Вопрос в том, как вы учитываете в разработке такой недостаток или вы полагаетесь на то, что все браузера строго блюдут стандарты? 2) если не использовать reset, то тег ul имеет по-умолчанию маркированный список. Тег ul используется очень часто и, если не использовать reset, то придется везде в стилях отменять margin и list-style-type у элементов, которые вешаются на тег ul. Как вы боретесь с этим, хотя слово борьба не совсем уместно, скорее как вы поступаете в этой ситуации?

@vithar, можешь привести пример ситуации, когда надо возвращать состояния по умолчанию?

@varya Показ письма в почте, показ поста в блоге, когда контент приходит из другой системы, которую ты никак не контролируешь.

А как же normalize.css? Reset просто зануляет все стандартные значения, это плохо, потому что не каждому блоку это нужно. А вот normalize приводит все стили в разных браузерах к единому дефолту, это хорошо. Каждому блоку не придется это делать самостоятельно.

@just-boris Тут только есть момент небольшого кол-ва неиспользуемого css. depsByTags нужно ;-)

@just-boris Например, normalize установит одинаковые значения отступов для всех списков, а потом мы в своем блоке menu будем вынуждены перебивать эти отступы на одни, в блоке nav — на другие, в контенте страницы — на третьи. В результате профит от использования normalize оказывается минимальным.

@tadatuta normalize же так не работает, он же фиксит особенности браузеров, и если у тега p браузер A ставит по умолчанию 20px отступов, а браузер Б 30px, то даже без использования normalize придется предопределять в блоках эти отступы.

Учитывая, что почти любому блоку можно проставить любой тег, блок может начать по-разному отображаться в разных браузерах, потому что значения отступов/цветов/чего угодно другого не нормализованы. Также при верстке текстов это будет особо заметно, там готовых блоков то как таковых нет.

Opera 12.x добавляет всем элементам невидимый в инспекторе outline: 3px. Это вылазит боком в тестах на вёрстку, например. Лучше бы этот стиль сбрасывать автоматически.

Хотелось бы вернуться к вопросу. Как уже отмечал @pavel06081991, допустим нужно сделать меню на тегах ul li, мы сбрасываем дефолтные стили списка, чтобы не было маркеров и отступов. Таким образом, нам приходится учитывать, что меню будет построено на списках, что противоречит изначальной абстрактности независимых блоков. Такая же проблема с кнопками - нужно учесть, что класс оформления кнопки может быть применен к button, a, div, span, input. Получается, единственный аргумент, который привел Виталий Харисов @vithar , - если в проекте будет внешний html.

@monochromer Не противоречит. Чем будет построено меню — описывается в шаблоне блока меню, как стили туда навешать — описывается в стилях того же блока меню. Т.е. вся информация об этом — находится только в блоке меню и нигде больше. Значит блок ни от чего не зависит. Чтд.

В этом примере есть меню, построенное на одних и тех же стилях, но на разных тегах. Чтобы устранить различие, нужно добавить в стили, как минимум,

list-style-type: none;
padding: 0;

Получается, что мы должны учитывать, что меню может (вернее, с вероятностью 99% будет) построено на ul.

Если ты решил строить меню на ul, то ты добавишь это в основные стили. Я пока не могу придумать при каких обстоятельствах ты захочешь строить меню то на div'ах, то на ul, но если это очень нужно, то определись какой вариант будет по умолчанию, а второй вариант опиши через модификатор, куда и запишешь отличия

Так что в итоге ? Reset использовать ?

@rtxrulez Вроде в треде все сошлись на том, что reset смысла не имеет, но в некоторых случаях может быть удобно использовать normalize. Впрочем, мы в bem-библиотеках его не используем.

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

Мне кажется это даже не противоречит методологии БЭМ так как это фактически тоже самое переопределение, скажем так переопределение начального уровня.