Весенний ветерок «реконструкции» дует по всей стране, и Интернет на какое-то время находится в состоянии хаоса. «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 как «контейнер».
Должен ли я использовать <div id="mainnav"><ul> или <ul id="mainnav"> для главного меню? Это проблема игры. Пока никто не может дать однозначного ответа на этот вопрос, даже я. Это правда, что когда <div id="mainnav"> содержит только один элемент <ul>, этот div кажется немного избыточным, но иногда, чтобы соответствовать великолепному дизайну, один дополнительный уровень тегов означает еще один уровень изменений (. некоторые люди также используют диапазон в теге a). Неотъемлемое преимущество div без каких-либо исходных атрибутов не имеет себе равных среди других тегов. Я просто хочу проиллюстрировать этим предложением одну вещь: мы должны понимать, что помимо <div id="mainnav"><ul> существует еще <ul id="mainnav"> такой способ записи, который также имеет хорошую структуру и семантику и устраняет уровень вложенности. Если нам не нужно беспокоиться о великолепном искусстве, можем ли мы сделать структуру более простой?
Это предложение на самом деле можно расширить до: «Не всему контенту нужны блочные элементы в качестве контейнеров» и «Не всем ссылкам нужны другие элементы в качестве контейнеров», например «больше», которое есть на многих страницах. Некоторые люди пишут «<div class="more"><a>», а другие — <p><a> или <strong><a>. Должны ли они существовать, если эти «контейнеры» содержат только тег <a>? Не нарушит ли прямая запись<a class="more"> структуру? Будет ли ему не хватать семантики? Повлияет ли это на планировку? Если вы думаете иначе, вы можете получить что-то другое.
4. Достичь «разделения структуры и производительности» на работе.
По этому поводу многие специалисты в Интернете предлагают так, то есть сначала открыть редактор, выписать структуру полностью, затем перейти в CSS для написания исполнения и стараться не трогать уже написанную структуру.
Однако людям, которые используют чтение книг в качестве основного метода обучения, трудно понять, потому что большинство книг по стандартам учат шаг за шагом, а это означает, что они должны поэтапно сочетать структуру и выражение. Хотя в некоторых книгах есть предложения на этот счет, несколько коротких предложений намного уступают тонкому воздействию в процессе чтения. Когда производственный персонал может хорошо понимать структуру, одновременное написание структуры и производительности не окажет большого влияния на результаты. Но по моему опыту, рабочий метод разделения структуры и представления гораздо эффективнее, чем одновременное написание структуры и представления. В то же время пропустить элементы на странице непросто.
Конечно, так называемое «разделение структуры и производительности» не означает, что производительность полностью игнорируется. Если вы хотите учитывать производительность, вы должны убедиться, что селектор CSS может выбирать как можно больше контента, не разрушая структуру. . Куда добавлять классы или какие метки использовать для их различения — это вопрос личного мнения. Я считаю, что у каждого свой опыт. Комбинируя разные проекты, иногда приходится вносить соответствующие изменения. Однако все эти изменения должны иметь один и тот же посыл — не разрушать структуру и читаемость кода.
Более того, мы должны понимать, что любой визуальный инструмент — это дьявол. Эффекты, представленные в их визуальных интерфейсах, часто далеки от эффектов реальных браузеров. На самом деле мы хотим быть совместимыми с браузером, а не с визуальным интерфейсом редактора.
5. CSS — не панацея, и жить без CSS невозможно.
По сравнению с эпохой CSS1.0, сегодня CSS может выполнять больше задач. Однако спрос всегда опережает технологии. CSS не может выполнить всю работу на уровне представления веб-страниц. Иногда нам приходится комбинировать JS или другие языки для достижения некоторых эффектов. . В других случаях использовать JS гораздо проще, чем полагаться только на CSS, и код более хорошо структурирован — наиболее типичным примером является раскрывающееся меню. В такие моменты нам приходится убеждать себя или наших начальников и клиентов использовать более простые и разумные методы. Поскольку DOM также является важным компонентом стандартов веб-страниц, это не означает, что использование JS сделает наши веб-страницы менее эффективными или перестанет соответствовать стандартам. Напротив, это самое большое недопонимание JS. Сказав это, я должен отметить, что в сегодняшнюю эпоху от каждой профессии требуется больше соответствующих знаний, чем когда-либо прежде. Те, кто занимается дизайном, должны немного знать о взаимодействии и производстве, а те, кто занимается производством, также должны понимать дизайн и программирование. , особенно с такими интерфейсными технологиями, как JS, только так вы и ваши коллеги сможете лучше работать вместе, а ваши перспективы личного развития будут ярче.
Отсутствие CSS означает, что наш веб-сайт не может загрузить файл CSS по разным неизвестным причинам. Не паникуйте из-за этого. Это лучшее время для проверки качества нашего кода. Если веб-страница по-прежнему сохраняет хорошую читабельность без CSS, это достижение гораздо более достойно нашей гордости, чем прохождение проверки W3C.