Как справиться с необходимостью изменения имен классов CSS - PullRequest
7 голосов
/ 22 февраля 2012

Я ищу стратегии людей, чтобы справиться с неизбежной необходимостью изменить или иным образом адаптировать класс CSS для размещения новых элементов HTML. Я нахожусь в такой ситуации довольно часто, поэтому я надеюсь, что другие люди разделяют мою боль и могут посоветовать здесь.

Представьте, что у вас есть таблица продуктов с хорошим семантическим названием класса products. Это правильно оформлено в вашей таблице стилей. Через несколько месяцев ваш начальник попросит вас создать список сотрудников на сайте, «стилизованный точно так же, как список продуктов».

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

  • Дайте ему также имя класса products. Это самое быстрое решение, но оно разрушает семантику. Наименование не имеет особого смысла, особенно для будущих разработчиков.
  • Измените имя класса на то, что может охватывать как товары, так и списки сотрудников Это сведет на нет полезность отделения разметки от стиля, поскольку HTML потребуется изменить. Кроме того, я не могу вспомнить ни одного непрезентативного имени класса, которое могло бы быть применимо к продуктам и штатному расписанию.
  • Введите новое имя класса и отредактируйте файл CSS так, чтобы .products { ... } становился .products, .staff { ... }, .products thead th.number { font-weight: bold } становился .products thead th.number, .staff thead th.number { font-weight: bold } и т. Д. Еще одно уродливое решение, которое со временем будет только усложняться.

Как лучше всего действовать здесь?

N.B. Я уверен, что эта проблема легко решается с помощью фреймворков, таких как LESS (я не использовал это лично), но это решение кажется мне скорее «сокрытием», чем реальным лекарством.

Ответы [ 8 ]

3 голосов
/ 22 февраля 2012

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

Пример:

.table-полосатый {}

2 голосов
/ 22 февраля 2012

Здесь в основном есть две школы мысли.

1) Стиль, который следует за разметкой 2) Разметка, которая следует за стилем.

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

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

Во втором вы создаете много общих стилей, а затем адаптируете свою разметку, чтобы соответствоватьстили.Например, у вас могут быть классы «float», «thinBorder», «bold», а затем применить эти стили к вашей разметке.Недостатком здесь является то, что если ваш стиль нуждается в изменении, то вы должны изменить HTML (или сделать жирный шрифт не жирным, или что-то подобное).Положительным моментом является то, что ваш CSS намного более чист и удобен в обслуживании.

Это отстой, но вы должны сделать компромисс.

2 голосов
/ 22 февраля 2012

Как насчет варианта 4:

Сделайте копию "продукты" в качестве "персонала" и продолжайте работать над ними по отдельности с течением времени.

1 голос
/ 22 февраля 2012

Хмм ...

По сути, корень проблемы в том, что ваша первоначальная мысль о создании первого класса стилей (.products) была названа слишком узко.Не всегда возможно знать, что вам понадобится повторно использовать значительную часть определения CSS на более позднем этапе, но, исходя из вашего вопроса, кажется, что вы занимаетесь этим видом деятельности.

Базовая структура CSSнет способа сказать «сделать мой новый стиль (.staff) таким же, как другой стиль (.products) с этими переопределениями»

Но я считаю, что LESS-фреймворк действительно дает вам возможностьопределить класс (.coolTable) со всеми свойствами и быстро повторно использовать эти свойства в нескольких других определениях класса (.products и .staff).

Каркас LESS не является 'cover-вверх, а не только расширение возможностей CSS.

0 голосов
/ 22 февраля 2012

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

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

0 голосов
/ 22 февраля 2012

Я бы выбрал первый вариант, чтобы иметь класс products с этим блоком .... или, может быть, как class="products staff"

Таким образом, у меня не будет дублирующихся стилей (даже из будущих аспектов).когда код / ​​стили могут сильно измениться), и любые специфические стили для продуктов могут быть сделаны таким образом новым классом (или другим способом использования родительского класса в стилях для придания большей специфичности стилей).

Да, product слово класса здесь не имеет особого смысла, но опять же, даже для будущих разработчиков, оно все равно означает, что вы используете стили класса персонала , не связанные с логикой ...

Но все-таки да, если можно легко изменить разметку с product на какое-то другое слово, я бы это сделал ... но не в качестве такого основного требования в этом случае ...

0 голосов
/ 22 февраля 2012

Я пойду с first option, потому что, если все одинаково и там просто изменение содержания.Таким образом, предыдущий класс products лучше использовать и для персонала. Вы можете отдельно определить панель своего персонала с помощью комментария <-- staff plan--> внутри HTML-страницы.

0 голосов
/ 22 февраля 2012

Это одна из вещей, которые мне действительно не нравятся в CSS. Имея в своем распоряжении все мощные языки, этот кажется просто поврежденным с самого начала, чтобы обрабатывать очень распространенные сценарии, подобные вашему. Я тоже все время с этим борюсь и в итоге либо копирую все определения, связанные с .product, в мой новый, либо добавляю свой новый в .product. Их можно вытащить позже.

Мне нужно также изучить препроцессоры, потому что я хотел бы сделать что-то такое, как OOP-y - определить b 'базовый класс', от которого наследуются и выходят и .product, и .mynewone.

Но № 3 - ваша лучшая ставка ИМО.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...