Говорю из опыта! Разъясните недоразумения, связанные с созданием веб-страниц Div+CSS.

Весенний ветерок «реконструкции» дует по всей стране, и Интернет на какое-то время находится в состоянии хаоса. «div+CSS» стал «модой». Бесчисленные веб-сайты неизменно начали свою собственную «реконструкцию». Однако открытие исходного кода этих различных веб-сайтов часто заставляет людей смеяться——

Мы видим макеты div с 6 или 7 уровнями вложенности, таблицы без таблиц, страницы, состоящие из чистого div+a, и сотни классов слоев представления... В настоящее время появляется все больше и больше книг по стандартам, за исключением нескольких книг, которые рекламируют. «продвинутые методы», мало кто не сделал бы акцент на таком предложении в первых нескольких главах своих книг – «разделение структуры и выражения». Однако сколько читателей этих книг серьезно прочитали первые несколько глав? Или вы предпочитаете пропустить скучные объяснения структуры и погрузиться в, казалось бы, продвинутые методы верстки и хаки?

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

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

1. «Сохранение кода» — маркетинговый инструмент, а не цель

«Использование макета div позволяет сэкономить больше кода, чем макет таблицы», — я видел это предложение во многих книгах и на веб-сайтах. Это предложение само по себе верно. «Экономия кода» действительно является одним из преимуществ стандартизации веб-страниц. Однако помните, что это всего лишь «одно из преимуществ», а не «единственное преимущество», и это не цель. «Сохранить код» — чаще всего маркетинговый ход, который мы используем, чтобы убедить упрямого начальства. Единственная цель стандартизации веб-страниц — «разделение структуры и производительности», и речь никогда не идет о сохранении кода ради сохранения кода. Однажды я использовал унифицированный класс, потому что боковая панель и даже основной контент веб-сайта имеют одинаковую форму представления (есть еще несколько книг, которые учат этому). Это действительно позволяет сэкономить код, чем называть идентификаторы по отдельности. Однако это требует затрат. Причина в том, что код теряет свою качественную структуру. Последствия потери хорошей структуры: 1. Исходный код больше не читается. 2. Увеличиваются неизвестные затраты на обслуживание веб-сайта. Только представьте, когда определенная часть контента меняет свое представление в зависимости от потребностей, например, цвета ссылки и т. д., нам приходится модифицировать исходный файл страницы и добавлять дополнительные классы. Рабочая нагрузка намного больше, чем просто настройка идентификатора. группировка. И если так будет продолжаться, структура будет становиться все хуже и хуже, образуя порочный круг, который трудно повернуть вспять.

Есть еще одна ситуация, которая возникает при именовании идентификаторов, и это тоже моя ошибка. В то время, в целях «сохранения кода», главное меню называлось «мм», вторичное меню — «м2», а меню третьего уровня — «м3». веб-страница была серьезно сокращена, из-за чего другим коллегам было трудно взять на себя ответственность, пытаясь избавить от неприятностей, но утомляя меня. Точно так же не рекомендуется упрощать именование файлов и папок. Например, «Реконструкция веб-сайта» рекомендует хранить все изображения в каталоге «i». Лично я считаю, что это нецелесообразно, если вы не умеете писать для такого. сильно сокращенная структура каталогов. Объясните подробно и убедитесь, что все участники, включая другой производственный персонал, разработчиков и даже знающих начальников... могут понять и реализовать ее, иначе это только добавит вам ненужных хлопот.

2. ID - снайперская винтовка, класс - палка о двух концах

Если вы хотите иметь хорошую структуру веб-страницы, необходимо хорошо владеть идентификатором и классом. Так называемый «хват обеими руками, обе руки должны быть сильными». ID подобен снайперской винтовке, которая может помочь нам точно определить местонахождение элементов, которые мы хотим загрузить в стили; а класс — это рыцарский меч, который легче и гибче у вас под рукой. Сочетание этих двух факторов позволяет получить страницу с хорошей структурой. и богатая производительность. Однако сейчас существует ошибочное мнение, что id можно полностью заменить классом. На самом деле это справедливо для многих исходных кодов веб-страниц. Когда вы открываете весь класс, вы не можете найти id. Причин этого явления много, но коренной причиной является глубоко укоренившаяся концепция «class=CSS», ушедшая из эпохи таблиц. Это правда, что класс более универсален и гибок, чем id, но следует также понимать, что класс гораздо менее эффективен, чем id, при построении хорошей структуры веб-страницы. Обязательная уникальность id позволяет нам легко получить любой нужный нам модуль через id, в то время как класс не имеет этого преимущества. Хотя мы можем определить уникальное имя класса для модуля, предполагается, что только сам производитель может изменить стиль веб-страницы. В противном случае давайте найдем немного ленивого парня. Видя, что стили одинаковы, он напрямую применит предыдущий класс. В результате мы обнаружим, что на веб-странице имеется более десятка модулей под названием «gonggao» или «xinwen». ", так что их трудно отличить. Без добавления большого количества html-комментариев этот результат явно не тот, который нам нужен. Более того, как упоминалось ранее, код, сохраненный с помощью универсальных классов, приходится растрачивать на каждый индивидуально определенный класс.

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

3. Не для всего контента требуется div как «контейнер».

Должен ли я использовать