Как понять архитектуру CSS других людей?
Я довольно хорош с CSS. Однако при работе с чужим CSS, для меня трудно видеть "большее изображение" в их архитектуре (но у меня нет проблемы при работе с листом CSS, который я записал сам). Например, у меня нет проблем с помощью Firebug, чтобы изолировать и устранить перекрестные проблемы совместимости браузера, или устраняя плавающую проблему или изменяя высоту на конкретном элементе. Но если меня просят сделать что-то решительное такой как, "Я хочу, чтобы правильные боковые панели страниц A, B, C и D имели красную границу. Я хочу, чтобы панели правой стороны страниц E, F и G имели синюю границу, если и только если пользовательские мыши", затем мне требуется время долгое время для планирования всех правил наследования CSS видеть "большее изображение".
По некоторым причинам я не встречаюсь с той же трудностью с кодом бэкенда. После быстрого расспроса того, как функция работает, и быстрый контроль контроллера и типового кодекса, я буду чувствовать себя довольным архитектурой. Я буду думать, "разумно предположить, что будет класс Сотрудника, который наследовался Классу Человека, это используется контроллером Отдела". Если я обнаруживаю неудобные детали, которые не согласовываются с полным архитектурным стилем, я уверен, что могу ковать вещи назад на месте.
С чужой работой CSS мне намного более трудно видеть "отношения" между различными классами, и когда и как классы используются. Когда существует много правил наследования, я чувствую себя разбитым.
Я испытываю затруднения при артикулировании моего вопроса и проблем... Все, что я хочу знать, почему это настолько тяжелее, чтобы я видел большее изображение в чужой архитектуре CSS, чем по сравнению с чужим слоем бизнес-логики?
** Это имеет какую-либо вещь сделать с CSS, являющимся относительно новой технологией, и нет многих популярных шаблонов разработки?
7 ответов
Я бы сказал, что, вообще говоря, не существует "архитектуры" в том, как большинство разработчиков пишут CSS (по крайней мере, по моему опыту). Большинство людей создают CSS постепенно, по мере необходимости - это обычно не планируется заранее, как архитектура кода. Часто люди группируют связанные правила в блоки комментариев, или, возможно, в отдельные таблицы стилей, но на самом деле не так много установленных шаблонов, которым можно следовать.
Лучше всего использовать хороший редактор CSS, который позволяет визуально просматривать иерархию правил, определенных в ваших таблицах.
Возможно, потому что CSS - это не архитектура, а представление. Архитектура построена на HTML. Именно HTML ведет вас к элементу.
да... Самая большая проблема в том, что у CSS нет популярных шаблонов проектирования. Вот мой способ ломать чужие CSS
- проверьте каждый элемент через firebug
- попробуйте найти обёртки
- поскольку css всегда последователен, попробуйте выяснить, какой элемент наследует какой атрибут от кого
когда я заканчиваю с этой рутиной, я обычно понимаю их полный подход к дизайну.
Редактировать:
И самое главное - никогда не забывайте исправлять уже написанный CSS, если вы заметили ошибки. Это избавит вас от головной боли. Просто идите вперед и ищите обходные пути, если глюк слишком серьезный.
Разработчики испытывают огромное давление, пытаясь убедиться, что дизайн выглядит единообразно во всех браузерах, и поэтому они начинают халтурить, что только усложняет поддержку и понимание CSS. Всегда есть хорошие практики, которым нужно следовать, например:
- Использовать сброс.
- Комментировать CSS.
- Использовать существующие CSS-фреймворки, не изобретая велосипед. колесо.
- Использовать объектно-ориентированный дизайн везде, где это возможно.
Если вы будете следовать этим практикам, любой сможет следить за CSS с помощью firebug.
Я думаю, что часто люди просто взламывают CSS вместе, не имея представления об общей картине. Часто они просто добавляют вещи, когда они выкладывают вещи, не обращая внимания на какие-либо установленные ими «условности», которые не совсем свежи в их памяти, что приводит ко всевозможным дублированиям и несоответствиям в именах.
Я не думаю, что CSS - это так много нового, поскольку CSS часто находится в сфере компетенции дизайнеров, и часто они не думают об архитектуре, когда что-то проектируют - все в некоторой степени adhoc.
Я знаю, что когда я являюсь лидером, я в первую очередь устанавливаю формальный набор соглашений для именования и организации классов, а затем вбиваю его подчиненным: -)
Во-первых, читать код сложнее, чем писать его.
Во-вторых, я бы сказал, что поскольку CSS позволяет свободную структуру, то люди будут настраивать ее сложным образом, так что я бы сказал, что это природа зверя.
Я борюсь с той же проблемой, и обнаружил, что при работе над чужим CSS полезно разделить проблему на части, сосредоточившись на трех проблемах:
- Layout для больших структурных вещей, таких как
display:,position:, иfloat:, или любого другого CSS, который касается того, как страница структурирована на уровне курса. - Color - это об оформлении. Фоновые изображения, цвета и тому подобное.
- Типографика - это все о тексте.
Немного попрактиковавшись, несложно взять в руки кусок CSS и вычленить эти категории по одной за раз. Возможно, вы обнаружите, что вам поможет закинуть CSS в текстовый редактор и перестроить правила в порядке макет/цвет/типография (или макет/типография/цвет). Сделав это, вы можете обнаружить, что стало легче рассуждать о том, что происходит в дизайне.
Между версткой и типографикой может быть некоторое дублирование в том, как используются поля и отступы (а иногда и границы). Вам нужно будет разобраться с этим в каждом конкретном случае.
Интересно, что большинство "хаков" (обычно обходных путей для IE), похоже, относятся к категории верстки, хотя вы можете столкнуться с хаком типографики, связанным с получением постоянного базового размера шрифта.