Искусство и дзен написания CSS

Автор оригинала: Jim Jeffers
  • Перевод
Я делаю шаблоны на чистом HTML/CSS уже больше восьми лет. За это время я убедился, что различные соглашения и документирование помогают в работе. Конечно, они не спасают от периодических CSS-кошмаров. Они лишь делают их менее болезненными. Мое решение — следовать определенным принципам в написании стилей. Эти принципы образуют основание, на котором будет строиться все дальнейшее написание стилей, облегчая работу над растущим проектом.

Урок первый: Будь конкретным только там, где надо


Люди стесняются полностью использовать наследование стилей. Многие, кто работал с CSS долгое время, пишут очень сложные псевдо-селекторы, чтобы обработать конкретный элемент. Это все хорошо и круто, но способствует развитию нездоровой привычки — мы перестаем писать простые правила.

Мне преподали этот урок уже много раз. Я предпочитал быть аккуратным. Писал стили, которые были по-настоящему четкими и конкретными. Но это плохо. Особые правила загоняют в рамки, из которых потом очень трудно выбраться. Вместо этого, более обобщенные правила сделают ту же самую работу, и останется только дописать нестандартный код, когда ситуация того потребует. Взгляните на пример ниже:


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

Чтобы увидеть, как делать не нужно, посмотрите на пример ниже (третий набор правил как раз описывает добавление специфичных для конкретной ситуации стилей):


Это вроде как фундаментальный урок CSS. Мы можем написать стили, применимые к большинству объектов, а для особенных сделать более конкретные. Большинство людей, пишущих CSS, знают это. Чего обычно не знают — гораздо безопасней избежать лишней сложности, не создавая слишком особенных правил. Вот что надо запомнить:
  • Сложность ваших стилей прямо пропорциональна сложности ваших селекторов.
  • Рефакторинг CSS-селекторов с целью уменьшения их конкретности гораздо трудней написания изначально простых правил с добавлением более сложных потом.

Урок второй: Надо с чего-то начинать


Работаете вы один или командой — начинать стили надо с одного и того же. Точка отсчета — это набор правил, который определяет, какое поведение вы ожидаете от окружения. Это обычно важно если вы работаете над стилями постоянно, и еще важней, если разработчиков несколько. Каждый должен видеть одну и ту же страницу, поэтому наличие одинаковой основы — лучший трюк, помогающий в этом.

Моя точка отсчета — CSS Reset Эрика Мейера. К несчастью, использование сброса стилей для продакшена — спорный вопрос. Опытные разработчики считают, что это ненужно или просто плохо, но на самом деле мы все используем сброс в той или иной форме. Проблема сброса на самом деле в том, что он так называется. Это не сброс, это основание, на котором строятся наши ожидания поведения браузера.

На самом деле, даже если мы не используем CSS-сброс, нам все равно приходится его реализовывать, только в еще более изощренной форме. Мы кругом повторяем сами себя, там где это нужно, чтобы добиться желаемого поведения. Самый известный пример — отступы (margins). Каждый браузер для каждого элемента имеет свои стили по умолчанию. Ни один нормальный человек не сможет запомнить их все.

Если не задать свою точку отсчета, придется работать с браузерной. А значит, среда разработки становится менее предсказуемой и контролируемой. Это на самом деле страшно.

Я не говорю, что CSS-сброс — Святой Грааль написания хорошего кода. Вовсе нет. Он может быть вашей головной болью, если не приспособить его как следует. Ведь многие не любят какие-либо настройки в файле сброса, например отключение жирности у элемента <strong>. Это потому что чужой файл сброса — всего лишь пример. Вам и вашей команде необходимо доработать его под свои нужды. Если надо, чтобы <strong> был жирным — подправьте сброс. Со временем вы разработаете свой reset.css (хоть и на самом деле стоит его назвать base.css). Ключевые моменты этого урока:
  • Собственные базовые (сбросовые) стили позволяют лучше контролировать окружение.
  • Для групп разработчиков одинаковые базовые стили — ключ к удобству совместной работы.
  • Базовые стили не гарантируют кроссбраузерности, но все равно дают ожидаемый результат.

Урок третий: Полагайтесь на конкретность правил, а не их порядок


Основной принцип CSS — если написать два одинаковых селектора, приоритетней будет последний. Иными словами, важен порядок. Но это довольно опасно — порядок будет влиять, если вы напишете селекторы одинакового приоритета.

С увеличением стилей все хуже удается их контролировать. Чтобы не затруднять работу, мы делим файлы на секции. Или даже разделяем правила на отдельные файлы.

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

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

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

Урок четвертый: Будь ясным и выразительным


Нужно хорошо себе представлять, чего вы хотите. Надо четко знать, как и что должно делаться в вашем документе. Как это делается в CSS? Очень просто — комментированием. Мы можем предоставить достаточное количество документации в наших CSS-файлах, просто их комментируя. Можно использовать комментарии для:
  • Описания наилучших практик.
  • Указания на организационные моменты.
  • Обеспечения ссылок на ресурсы.
Здесь две проблемы. Первая — немногие люди используют комментарии в файлах стилей. Вторая — многие авторы не видят в этом необходимости. Второе, видимо, следует из первого.

Давайте подумаем, почему мы не пишем комментарии и не документируем код, даже если это полезно. Первая причина в том, что наши файлы от этого увеличиваются в размерах. Да, это действительно так, но можно ведь запросто использовать YUI Compressor, или написать простенький скрипт, который автоматизирует процесс уменьшения файлов и удаления комментариев из кода для продакшена.

Вторая причина заключается в том, что вы, скорей всего, единственный, кто будет работать с этими стилями. Это очень недальновидно. Всегда, всегда (всегда!) думайте о том, что кто-нибудь когда-нибудь может работать с этим файлом кроме вас. Вы ведь не будете трудиться над этим проектом вечно. Иными словами — считайтесь с тем, что кто-нибудь, возможно, будет дописывать или редактировать ваши стили. Вы можете либо подсказать, как это сделать лучше всего и без вас, либо вычищать и переписывать все самому, когда вас позовут чинить сломанный сайт.

Уметь ясно изъясняться гораздо тяжелей, чем кажется. Как лучше всего рассказать, чего вы ожидаете от вклада другого разработчика? Лично я пишу свои лучшие практики в виде коротких наставлений с примерами и комментариями в начале файла. Что-то вроде такого:


Смысл в том, что можно использовать комментария для ясного и четкого объяснения манеры, в которой должен быть написан код. Просто оформляйте все свои файлы определенным образом. Пользователи Textmate могут воспользоваться специальным бандлом для этого. Что надо запомнить по этой теме:
  • Используйте комментарии, чтобы обозначить, как код должен быть написан и отформатирован другими.
  • Всегда помните, что после вас над файлом может работать кто-нибудь другой.
  • Используйте комментарии для разбиения кода на разделы. Комментарии могут помочь в навигации по документам.
Примечание переводчика: опытным разработчикам читать здесь нечего, они и так должны все это знать. С другой стороны, сравнительно недавно написанная статья затрагивает моменты, которые редко рассказываются в учебниках и самоучителях по HTML/CSS. В свое время те же самые выводы я сделал на основе горького опыта, поэтому, думается мне, новичкам, еще не испытавшим все горести и тяготы неправильно заложенной основы разработки, эта статья сильно поможет. Все-таки, действительно — best practices.
Пользуясь случаем, хочу передать привет и благодарность разработчикам сервиса translated.by

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 88

    +5
    Все правильно, и даже то что ничего нового :)

    Тут упомянули про рефакторинг стилей. Хотелось бы увидеть кто чем пользуется.
    И для тестирования тоже ( что в общем часть процесса рефакторинга обычно ).
      +2
      я недавно делал рефакторинг на самом моем большом проекте. пользовался тем же, чем и при разработке — Aptada + Zen conding, Firefox + Firebug
        +2
        боже ж ты мой, что творится с речью, когда всю ночь правишь текст.

        Aptana и Zen coding, конечно же
          0
          aptana и zen coding?

          И что аптана умеет рефакторить стили?
          например переименовывать селектор глобально по файлу или проекту или сливать/разделять классы?
          автоматом проверять результирующие стили по DOM страницы?
            +1
            ну для меня рефакторинг это не столько простое переименование, сколько изменение внутренней структуры без изменения внешнего поведения, поэтому я переделывал все довольно основательно — с нуля, удалив много наркоманского лишнего кода, и уменьшив размер стилей втрое
              +1
              Aptana на данный момент единственный IDE, который поддерживает максимум функционала Zen Coding. Остальные редакторы — лишь частично.
                0
                А что там кроме шорткатов и темплейтов?
                Имхо это умеют все приличные IDE
                  0
                  Не во всех IDE есть встроенные темплейты для всех CSS3 свойств — fz -> font-size:, bd+ -> border: 1px solid # и т.д.

                  Привыкнув, уже невозможно писать иначе.

                  Не видел чтобы IDE умели разворачивать ul.class>li*2>a в


                  или оборачивать обычный текст

                  например
                  текст
                  меню
                  из макета

                  через ul.class>li*>a в

                  • например
                  • текст
                  • меню
                  • из макета


                  А в остальном Вы правы — ничего такого Zen coding и не умеет. Вещь в общем-то бесполезная.
                    0
                    если честно нифига не понятно.
                    оборачивать в теги выделенный текст может даже tiny на WP :)
                      0
                      Непонятно, потому что парсер съел теги. Оборачивать многострочный текст он тоже может?

                      В последнем примере должно было получится вот что

                      [ul class=«class»]
                      [li][a href="#"]например[/a][/li]
                      [li][a href="#"]текст[/a][/li]
                      [li][a href="#"]меню[/a][/li]
                      [li][a href="#"]из макета[/a][/li]
                      [/ul]
                        0
                        понятно :) легко делается, только в два приема — сначала ul и потом li.

                        WP у меня умел раньше строки в отдельные li оборачивать — я убрал, поскольку неудобно — я часто элементы многострочные делаю.
                  0
                  Espresso?
                    0
                    Notepad++ с ZenCoding plugin :)
                      0
                      Кажется последнее нововведение .class или #class (с опущенным div) есть только в версии для Аптаны.
                        0
                        #asdd [=>]
                        .asdaw [=>]

                        Так что работает в NPP
              0
              Автор, что у вас за редактор на скриншотах?
                +3
                notepad++?
                  +2
                  Notepad++

                  в оригнале код подсвечен github-овским скриптом, у меня же возможность вставлять JS не было, а Source Code Highlighter пока не умеет показывать CSS.

                  пришлось выкрутиться таким вот образом
                    +2
                    s-c.me умеет CSS подсвечивать, хотя ваш вариант, тоже очень хорошо смотрится.
                      0
                      о, так сделали! у меня быстро не нагуглилось
                      спасибо, буду знать
                      0
                      наверняка scintill'овский движок )
                      использую Scite-ru, кстати, замечательный редактор, при должной настройке
                    0
                    По-моему выводы из 3-го урока немного противоречат выводам из 1-го урока. Но в целом я с автором согласен, хотя и не строго следую правилам из последних 2-х уроков.
                      0
                      нет, противоречивого там нет. «сначала обобщенные, потом конкретные» не в плане появления в коде, а в порядке создания. тот же стиль для тега <p> может быть создан где угодно, но если написать для него класс, который перезапишет какие-то его свойства, то неважно где он будет указан — вес селектора по классу больше, чем вес селектора по тегу
                      +1
                      У нас в проектах, после нарезки шаблона, всегда делаю как реккомендует урок 1…
                      А когда отдаю программистам на внедрение, они путаются, ругаются и всячески хотят, чтобы я делал «как не надо в уроке 1»…
                      Странно это всё… ))
                        0
                        они еще далеки от просветления :) хотя смотря какие программисты — если это какой-нибудь друпал, то вполне возможно что ругань оправдана, там свои стандарты кодинга
                          0
                          они из .Net… )
                        +1
                        Такой момент. Вечно пишут, что комментарии — это забота о том, кто будет разгребать код после вас (ну и о том, чтобы этот кто-то вас потом не отвлекал за советом). Мне кажется, более мотивирующим тут будет, что комментируемый код — забота о себе самом: когда вы взглянете на ваш код через месяцок-другой (особенно, если активно обращаться к нему в этот период не приходилось)…
                          0
                          Здорово, когда помнишь все нюансы стандартов наизусть, но если в редакторах других языков есть всяческие подсказки-помощники, то как обстоят дела с css? Помнится, пользовался TopStyle. Может кто-то юзает бесплатные (или менее дорогие) и не менее удобные аналоги?
                            0
                            Eclipse.org Вам в помощь, друг мой. И работать и учить.
                              0
                              Есть хорошая вещь, JetBrains WebStorm — www.jetbrains.com/webstorm
                              Что называется, «От создателей IntelliJ Idea!» :)
                              Перелез на неё с Aptana, лучше пока ничего не попадалась. Оно пока beta (но более чем юзабельно), поэтому бесплатно.
                                +1
                                И Эклипс хорош, и, уверен, джетбрейнс, но хотелось что-нибудь попроще. Пишу по большей части в Notepadd++. Ставить ради «подцветки» и хинтов css перечисленных выше монстров… как-то страшно :-).
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    Попроще это только если нужно поправить что-то в уже существующем коде или если для вас это скорее хобби, а не работа.

                                    Такие «монстры» в комплекте предоставляют огромное количество незаменимых утилит, которые позволяют автоматизовать рутинные процессы и очень сильно сэкономить время и силы при каждодневном использовании.
                                      0
                                      мы используем идею. её тормоза уже погубили не одну сотню нервных клеток и человекочасов…
                                        0
                                        Не раз встречал утверждение менеджеров софт-девелоперских компаний, что девелоперам надо давать на рабочее место самые супер-путер мощные компы и огромные мониторы и что это себя достаточно быстро окупает.
                                    0
                                    За что человека минусуют — за то что высказал свое мнение?

                                    В вебшторме куча мелочей, на первый взгляд очевидных, но отстутствующих в Аптане — переход к css-объявлениям при клике на имя css-класса, css-рефакторинг, можно забыть про ctrl+s — сохранение при потере фокуса и т.д. и т.п. Заружается заметно быстрее.

                                    Сам сидел на Аптане из-за Zen coding, но потом появилась нативная поддержка Zen coding в вебшторме и с каждым EAP все более и более полная.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    Ушел с NetBeans на Eclipse из-за отсутствия поддержки ZendDebugger. Хотя со временем пришлось отказаться и от ZendDebuggera, из-за отсутствия его под FreeBSD, все равно остаюсь на Eclipse, по причине наличия большого количества полезных расширений, нежеле в NetBeans'e.
                                      0
                                      Извините, а можно примеры полезных расширений?
                                      Просто использую NetBEans и наверное чего-то не знаю. Вдруг тоже на Эклипс полезу…
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          Ну у меня стоит:
                                          Epic — редактирования Perl в Eclipse. Для NetBeans ничего для перл, кроме «подсветки синтаксиса» я и не нашел.
                                          MyLyn — для связи с JIRA. Да, в NetBeans оно работает по умолчанию.
                                          Subversive SVN Connector — Как видно для работы с SVN репозитарием. Для NetBeans есть расширение для SVN, но я с ним тогда еще не сталкивался, так как в те времена еще не познал всех прелестей SVN.
                                          Пара расширений для Preview HTML и CSS.
                                          Кстати очень важный аспект — при использовании в NetBeans CSS редакторе IE хака "//" весь CSS становится невалидным и нельзя сделать предпросмотр стиля. Это в свое время очень напрягало.
                                          Ну и в Eclipse мне очень нравится Outline для навигации по любым структурам. Не знаю был/есть ли такой в NetBeans.

                                          Если кто-то решит корить меня по поводу использования IE хака, то могу сказать, что это пройденный этап, и я решил генерировать индивидуальные стили для каждого из браузеров. Потому что зачастую для WebKit Chrome/Safari приходится так же прописывать что-то индивидуальное. Хотя может просто еще руки кривые.
                                      0
                                      Мне тоже из всего (специально переберал, пробовал) тоже более всего NetBeans по душе пришёлся. Может на навороты для PHP-разработок он бедноват, но EclipsePDT/Zend по сравнению с ним какими-то неуклюжеватыми показались. О WebStorm сейчас впервые узнал, попробую. NotePad++ через Total Commander по F4 исполюзую для быстрого подравления и каких-то манипуляций.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Интересно, а какие советы можно получить по поводу оптимизации CSS стоит ли для продакшена, убирать все коменты, записывать все свойства в одну строку, тем самым снижая размер CSS файла?
                                        0
                                        webo.in/articles/habrahabr/14-minifing-css/ исчерпывающая статья
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            Юрий Ткаченко писал в блоге Яндекса про абсолютно независимые блоки и подход с сокращением наименований классов. Утверждают, что добились прироста в скорости отрисовки страницы до 100% в ие6-7.
                                              0
                                              Если память не изменяет это постобработка, типа минификации.
                                              В любом случае головняк с поддержкой индивидуального стиля для каждого уникального элемента не стоит 100% в ИЕ6 и даже ИЕ7
                                                0
                                                Обработка, как я понял, производится для сокращения длинных имен классов до буквенных сокращений. Стоит или нет — в любом случае зависит от задачи и проекта. Но, соглашусь, основной стиль для сайта я бы так делать не стал.
                                              0
                                              Как же коробит от стилей с отступами и каждым свойством на новой строке. Это наглядно и удобно лишь в документации и в небольших стилях. Но когда правил десятки, то читать файл невозможно. При чтении файла ищется конкретный селектор, а не свойства, поэтому гораздо удобнее, когда эти селекторы отсортированы по смыслу и идут друг под другом — сразу все видно. А уж конкретные свойства посмотреть — можно и горизонтальным скроллом воспользоваться, ничего в этом страшного. Тем более далеко не всегда свойств у селектора много.
                                                +1
                                                не могу согласиться. Хотя бы потому, что при одной опечатке парсер пропустить всю строку, и будете ездить по все простыне горизонтальным скроллом. Выделение так не удобно делать — если курсор слетает на другую строку, которая закончилась раньше, то скролл может сдвинуться, ну и т.п.
                                                  –3
                                                  Это все ерунда, по сравнению с тем, что файл просто становится не читабельным. В случае с нормальной IDE это не актуально, но далеко не во всех случаях удобно ее использовать.
                                                    –1
                                                    Вы считаете, что на втором скрине в статье верхняя половина кода более читабельна чем нижняя?

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

                                                    Тоже самое с именами правил — последнее правило в строке будет найти не так уже легко.

                                                    .class, .other-class > ul, .another-class ol li{… }
                                                      +1
                                                      Да, верхняя половина более читабельна.

                                                      Да по барабану, где будут начинаться свойства. 90% времени при чтении файла уходит на поиск и анализ объявленных селекторов, а не их свойств. Если я определился, какой селектор мне нужен, то большая часть работы уже сделана. Дальше я уж как-нибудь в этой строке найду, где там отступы задаются или шрифт. И заданные свойства мне интересны только в контексте выбранного селектора, мне незачем их сравнивать с со свойствами других селекторов (за редким исключением при оптимизации).
                                                        0
                                                        вам нужно сделать рефакторинг и не страдать больше хернёй 90% времени
                                                          0
                                                          Рефакторинг чего? Чужого кода? Речь вроде шла не о конкретном проекте, а вообще о стиле написания. Или вы мне предлагаете сразу начать делать рефакторинг всех моих проектов — прошлых и будущих? Спасибо, добрый человек.
                                                          Знаете, задачи разные бывают. Не всегда проекты делаются с нуля. Бывает, что заказчик обращается за доработками с кодом, который ему делали другие. Мне ему сразу предлагать сдеать рефакторинг за n*10 часов, при том, что сама задача может занять только n часов?
                                                          В общем для многих это дело привычки, доказывать что-то бессмысленно.
                                                            –1
                                                            конечно, лучше умножать говнокод ;-)
                                                              +2
                                                              Причем тут говнокод? Только из-за того, что стиль написания другого человека не совпадает с вашим, вы готовы его оскобрить и обвинить в написании говнокода?
                                                                –1
                                                                если 90% ремени тратится на поиск правила — значит это говнокод
                                                                  +1
                                                                  90% при чтении файла (т.е. не когда вы код пишете, а когда вам нужно что-то исправить, как правило в чужом коде или в старом проекте, к которому вы давно не возвращалиь). И потом проценты — это величина относительная. В абсолютных величинах при работе с однострочными селекторами у меня 90% составляют, допустим, 1 минуту, а с красиво отформатированными «не говнокодерскими» — 3 минуты, при этом кто-то скажет, что это составило всего лишь 10% времени от чтения файла (непонятно, только, на что ушли остальные 90% — на любование красотой и изяществом?)
                                                                    –1
                                                                    уф, а не проще нажать Ctrl+F?
                                                                      0
                                                                      Далеко не всегда. Ctlr-F не даст представления о том, какие селекторы объявлены и куда лучше дописать правило.
                                                                      Форматированный файл обычно на 10 экранов бывает. В то время как однострочные селекторы вполне могут уместиться на одном экране, что дает целостную картину о стилях.
                                                                        –1
                                                                        статья о том, как лучше оформлять свой код. если вам попался чужой код, да еще и говняный, то не надо ругать автора, который проповедует просто другую идеологию. по которой, кстати, наплевать, где находится селектор. что дает возможность вбить его в Ctrl+F и получить максимум пару совпадений.
                                                                          0
                                                                          Я где-то ругал автора? Я высказал свое мнение. Оно может совпадать с мнением окружающих, а может быть прямо противоположным.
                                                                          0
                                                                          фолдинг спасёт отца русской демократии
                                                  0
                                                  по поводу комментов.
                                                  в третьем примере многострочный русскоязычный коммент.
                                                  разве это не приводит к проблемам во всеми любимом браузере?
                                                    0
                                                    в третьем примере перевод
                                                    кириллица в комментариях не-юникод-файла приведет к проблемам во всеми любимом браузере
                                                    +3
                                                    никак не могу понять прикол записи правил по алфавиту, почему бы не задать сначала шрифтовое описание, затем отступы и позицирование, бекграунды и тд?
                                                    иначе получается для того, чтобы задать width и height и position нужно первую строку писать где-то вверху, следующую в конце и позицию в середине столбика параметров. Также и редактирование, добавил педдинга, убрал ширины, снова скачешь по всему столбику.

                                                    имхо куда приятнее:
                                                    .stylename{
                                                    font-style: italic;
                                                    font-weigt: bold;
                                                    width: 50px; height: 100px;
                                                    position: absolute;
                                                    top: 0; left: 20px;
                                                    }

                                                    нежели:

                                                    .stylename{
                                                    font-style: italic;
                                                    font-weigt: bold;
                                                    height: 100px;
                                                    left: 20px;
                                                    position: absolute;
                                                    top: 0;
                                                    width: 50px;
                                                    }

                                                    имхо, это все равно, что читать описание мобильного телефона на сайте и видеть его ширину вверху страницы, толщину — по середине, а высоту- внизу.
                                                      0
                                                      правила со свойствами не путаете?
                                                        +2
                                                        Тот же самый вопрос можно отнести и к сортировке правил по алфавиту. Гораздо удобнее и логичнее, когда правила сгруппированы в соответствии с логикой html-кода.
                                                          0
                                                          мне тоже это слово не понравилось, но дабы не нарушать терминологию поста использовал его
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                            0
                                                            Идеалогически правильнее top right bottom left
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                          +2
                                                          каскад — зло. его лучше стараться минимизировать
                                                            +2
                                                            первое правило — требует уточнения!
                                                            Автор видимо пытается донести идею о том что нужно устанавливать в базовых стилях тот внешний вид, что идёт по всему сайту,
                                                            но выбрал плохой пример для этого.

                                                            За стили типа p {font-size: 0.75em} — надо руки отрывать, я лично отрываю)
                                                            Самый простой пример почему: будет у вас на сайте, на страничке редактируемой из визига, такой код:

                                                            <div class="some-block-from-wysiwyg">
                                                            <p>Lorem ipsum...</p>
                                                            Lorem ipsum
                                                            </div>


                                                            Всё, приплыли, размер шрифта у текста внутри абзаца и просто в блоке будет разный!
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                                +1
                                                                речь о том что юзер через визиг может вставить текст и без абзацев, копипастом например.

                                                                да и не в визиге дело, вместо текста вне абзаца может быть текст внутри списка, текст внутри span, им получается чтож теперь тоже размер задавать? :)

                                                                но главный факап — изменение размера шрифта абзаца при помещении его в блок, которому задан какой-то font-size. Всё внутри этого блока будет с одним font-size, а абзацы — с другим.
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                              0
                                                              Можно поинтересоваться, а что это за редактор кода?
                                                                +6
                                                                нет, это секретная информация. сообщается только тем, кто читает комментарии
                                                                  0
                                                                  +1
                                                                  Я бы обязательно упомянул про технику верстки абсолютно-независимыми блоками. Когда проект реально большой и верстают много людей, то без этого ОЧЕНЬ трудно.
                                                                    0
                                                                    Кстати комментарии в цсс желательно писать на английском, т.к лично в своём опыте встречал проблемы в вёрстке из- за этого. Соответственно дзен заключатеся не только в красивом и грамотном оформлении и написании цсс стилей, но и в постоянном развитии и совершенствовании, в том числе и в английском.
                                                                      0
                                                                      встречал проблемы в вёрстке из-за этого
                                                                      Если кодировка в css совпадает с основной кодировкой сайта, то проблем быть не должно :)

                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                    Самое читаемое