Владимир З.
36 лет, Украина
366 сообщений
#10 лет назад
Собственно, вопрос насчет reset.css
1. Переопределение тегов типа <img>, <span> и пр.(например, сброс margin'ов-padding'ов в ноль);
2. Сброс маркеров list-style в значение none
это может считаться багами верстки?
Заранее благодарен за ответы
Максим Богуславский
40 лет, Россия
2206 сообщений
#10 лет назад
С такими вопросами к Sir_Michael. Он точно знает https://www.weblancer.net/users/Sir_Michael/
Михаил Валенцев
37 лет, Россия
2195 сообщений
#10 лет назад
Здравствуйте

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

Для контента после resrt.css нужно обязательно восстанавливать уже кроссбраузерные отступы-размеры для часто используемых тегов (h1..h6, p, ul, ol и т.д.), ну и маркеры через background для списков.
Проще всего задать отдельный "восстанавливающий" класс.
Андрей Халецкий
33 года, Беларусь
3563 сообщения
#10 лет назад
Стесняюсь спросит, а зачем?

ЧТо касается вопроса - я бы такую верстку не принял. Сайт должен себя вести предсказуемо при использовании "обычных" тегов.
Михаил Валенцев
37 лет, Россия
2195 сообщений
#10 лет назад
SmartDesign
Зачем сбрасывать отступы и маркеры у списков? Чтобы верстка в разных браузерах выглядела одинаково.
Раньше это делали с * {margin:0;padding:0}.
Михаил Валенцев
37 лет, Россия
2195 сообщений
#10 лет назад
Не грех, если есть свое понимание для чего и почему.)
Team Zodios
34 года, Украина
75 сообщений
#10 лет назад
Как говорили на РИФе - самый лучший ресет - ресет написанный тобой.
А переопределяют значение потому что у разных браузеров для ряда структур заданы разные величины
http://zodios.net/htmlcss/defoltnye-znacheniya-parametrov-css-raznykh-brauzerov.html
Михаил Валенцев
37 лет, Россия
2195 сообщений
#10 лет назад
Цитата:
Как говорили на РИФе - самый лучший ресет - ресет написанный тобой.

А там не вспоминали о моменте, что над проектом может работать не один верстальщик? Или все же речь шла о css-фреймворках
Владимир З.
36 лет, Украина
366 сообщений
#10 лет назад
Цитата ("Sir_Michael"):
Для контента после resrt.css нужно обязательно восстанавливать уже кроссбраузерные отступы-размеры для часто используемых тегов (h1..h6, p, ul, ol и т.д.), ну и маркеры через background для списков.

О, точно, где-то тут собака и зарыта. А если я использую, например <span> в хедере и задаю его каскадом (типа .header span) или отдельным классом, а в контентной части вообще данный тег не использую - я должен его глобально переопределять после обнуления в reset.css?
А то у меня тут с заказчиком терка - он сам верстку натягивал на движок (причем по его словам "с горем пополам натянул", теперь там некоторые тексты расползаются или исчезают, и я вроде как в этом виноват.
Михаил Валенцев
37 лет, Россия
2195 сообщений
#10 лет назад
У span'ов по умолчанию отступов и нет.

Но, допустим, если был ul/olсписок - после reset.css у него никаких отступов нет и маркеров не будет. И если заказчик забил в контент список (а в движке наверняка какой-нибудь wysiwyg) и список у него отобразился просто текстом в столбец - это совсем не то, что ожидал пользователь, следовательно уже баг верстки.

Другое - если ширина контента ограничена, а пользователь пытается вставить туда какую-нибудь таблицу в два раза большей ширины. Тут никакой вины верстальщика нет.
В принципе и с этим можно бороться, чтобы верстка не поехала - задать контенту overflow:hidden (тогда то что не влезет обрежется) или overflow:auto (появится scroll внутри контента).

Для себя делаю как - определяю класс "восстановительный" класс .recovery (у меня там заголовки h1..h6, ul,ol,dl списки, а также p и div - обычно этого достаточно) и добавляю его к контентной части:
...
<div class="header">...</div>
<div class="content recovery">...</div>
...
<div class="footer>...</div>
...


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