Как понимать чужие CSS-архитектуры?

Question

Я достаточно хорошо разбираюсь с CSS. Тем не менее, при работе с чужим CSS мне трудно увидеть «большую картину» в их архитектуре (но у меня нет проблем при работе с таблицей CSS, которую я написал сам). Например, у меня нет проблем с использованием Firebug для изоляции и исправления проблем совместимости между браузерами, а также с исправлением плавающей проблемы или с изменением высоты для определенного элемента. Но если меня попросят сделать что-то радикальное, например: «Я хочу, чтобы правые боковые панели страниц A, B, C и D имели красную рамку. Я хочу, чтобы правые боковые панели страниц E, F и G имели синяя рамка в том и только в том случае, если пользователь наведет курсор мыши на «, тогда у меня уйдет много времени, чтобы наметить все правила наследования CSS, чтобы увидеть« большую картину ».

»

По какой-то причине я не сталкиваюсь с такой же сложностью с бэкэнд-кодом. После быстрого обсуждения того, как работает функция, и быстрого осмотра кода контроллера и модели, я буду чувствовать себя комфортно с архитектурой. Я подумаю: «Разумно предположить, что будет класс Employee, унаследованный от класса Person, который используется контроллером Department». Если я обнаружу неудобные детали, которые не соответствуют общему архитектурному стилю, я уверен, что смогу все вернуть на свои места.

Работая с чьим-то CSS, мне гораздо сложнее увидеть «взаимосвязи» между различными классами, а также то, когда и как эти классы используются. Когда есть много правил наследования, я чувствую себя подавленным.

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

** Имеет ли это какое-то отношение к тому, что CSS является относительно новой технологией, а популярных шаблонов дизайна не так много?

Answer 1

Я бы сказал, что, вообще говоря, нет никакой «архитектуры» в том, как большинство разработчиков пишут CSS (по крайней мере, по моему опыту). Большинство людей создают CSS постепенно, так как нужны правила - обычно это не планируется заранее, как архитектура кода. Часто люди группируют связанные правила с блоками комментариев, или, возможно, в отдельных таблицах стилей, но на самом деле не так много установленных шаблонов для подражания.

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

Answer 2

Я думаю, что много раз люди просто взламывали CSS вместе, не имея представления об общей картине. Много раз они просто добавляют что-то, когда выкладывают вещи, не обращая внимания на какие-либо «условные обозначения», которые они установили, которые не являются свежими в их сознании, что приводит ко всем видам избыточных имен и расхождений.

Я не думаю, что CSS настолько нов, как то, что CSS часто является сферой для дизайнеров, и часто они не думают архитектурно, когда проектируют что-то - все происходит несколько неожиданно.

Я знаю, что когда я веду, я устанавливаю формальный набор соглашений для именования и организации классов как одну из первых вещей, которые я делаю, а затем вбиваю их в подчиненные подчиненные: -)

Answer 3

Я борюсь с той же проблемой и обнаружил, что при прохождении чужого CSS полезно разобраться в проблеме, сосредоточившись на трех проблемах:

• Макет для больших структурных элементов, таких как display:, position: и float:, или любого другого CSS, который описывает структуру страницы на уровне курса.
• Цвет - это украшение. Фоновые изображения и цвета и тому подобное.
• Типография это все о тексте.

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

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

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

Answer 4

да .. Самая большая проблема в том, что у CSS нет популярных шаблонов дизайна. Это мой способ ломать чужие css

• проверять каждый элемент через firebug
• попробуй найти фантики
• , поскольку css всегда последовательный, попробуйте выяснить, какой элемент от кого наследует, какой атрибут

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

Редактировать:
и самое главное не обращать внимания на исправление уже написанного CSS, если вы заметили глюки. Это избавит вас от головной боли. Просто продолжайте и найдите обходные пути, если сбой слишком плохой.

Answer 5

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

• Используйте Сброс.
• Комментарий CSS.
• Использование существующих CSS-фреймворков без изобретения рулевое колесо.
• Использование объектно-ориентированного дизайна везде, где это возможно.

Если вы будете следовать этим правилам, любой сможет следовать CSS, используя firebug.

Answer 6

Возможно, потому что CSS это не архитектура, а презентация. Архитектура построена с использованием HTML. Это HTML, который ведет вас к элементу.

Answer 7

Прежде всего, сложнее читать код, чем писать код.

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