Рекомендации по проверке кода для CSS, JS и HTML


9

Меня попросили создать руководство по обзору CSS, JS и HTML. Я знаю, что есть правила кодирования для JS, но я не знаю ничего о HTML и CSS. Чтобы проверить JS, я обязательно последую этим указаниям и упомяну их. Но как насчет CSS и HTML? Кроме логических ошибок и проблем с отступами, есть ли какие-то конкретные вещи, которые мне нужно проверить, когда я проверяю разметку и / или CSS?


1
это было только на HN сегодня, может быть, это хорошее место для начала. taitems.github.com/Front-End-Development-Guidelines
agradl

Ответы:


5

Некоторые вещи, чтобы искать:

  • Идентифицируется ли структурированная информация с помощью соответствующих тегов HTML? H1- H6для заголовков, UL/ OLи LIдля списков и т. д.?
  • Нет ни одного устаревшей HTML - тегов ( <b>, <i>, <center>, <font>) используются?
  • Использует ли сайт наименьшую возможную разметку?
  • Выводится ли информация о стиле в файлы CSS?
  • Является ли весь Javascript внешним? в том числе обработчики событий?
  • Имена классов CSS относятся к функции в page ( img-caption), а не к form ( bold-red) или content ( pink-elephant)?
  • Изображения в соответствующем формате (PNG или JPEG, в зависимости от типа)?
  • Были ли использованы свернутые версии библиотек Javascript?
  • Необязательно, все ли локально разработанные файлы Javascript и CSS были минимизированы?
  • HTML / CSS проверяет?
  • Был ли YSlow (или аналогичный) использован для проверки / оптимизации производительности?
  • (в основном) [SEO] Доступен ли сайт с отключенным Javascript?
  • [SEO] Находится ли наиболее релевантный контент в верхней части HTML?

Я только что нашел книгу Стива Сондерса на более быстрых сайтах. Это весьма полезно, и некоторые упомянутые вами пункты хороши.
Кумар,

0

Одним из важных элементов хорошего стиля в HTML является прогрессивное улучшение . Это означает, что макет HTML будет хорошо отображаться даже без CSS или JavaScript. Затем, после обработки JS / CSS, он будет выглядеть лучше (например, <select>выпадающий список HTML в старом стиле станет анимированным).

Это также связано с неинтрузивной разметкой. Вместо того, <font style="color:red;font-size:16pt">Hello</font>чтобы использовать <div class="red-colored-big-fond">Hello</div>.

То же самое с JavaScript. Вместо этого <button onclick="javascript:alert('a');">Clickme</button>можно было бы указать класс кнопки / идентификатор и выбрать его из JavaScript. Это также облегчает поддержку вашего кода разметки.


0

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

Кроме того, Алекс поднимает замечательный вопрос окольным путем. Убедитесь, что никто не использует имена классов, такие как «red-color-big-font», потому что примерно через 20 секунд после его реального развертывания кто-то изменит его на маленький синий шрифт. Я на самом деле видел этот CSS:

.arial12pt { font-family: Verdana; font-size: 8pt; }

Все в вашей разметке должно описывать, что это за страница, а не как она выглядит. Я определенно согласен с прогрессивным улучшением, но опять же окольным путем. На странице нет требований, чтобы выглядело что-то похожее с CSS и без него. Не пытайтесь заставить их выглядеть одинаково, потому что вы снова окажетесь в table-land и spacer.gif.


0

Что касается HTML, я всегда подчеркиваю наличие иерархии и отступов в моих файлах. Например, если у меня есть куча div:

<div id="content">
   <div id="post">
     <div class="title">
       Blah Blah Title
     </div>
   </div>
</div>

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

#whatever{
    background-image: url('blah.gif');
    color: #FFF000;
}

Отступы значительно облегчают чтение, когда вы привыкли к другому языку, смешанному как PHP / Ruby / Wh чем угодно. Опять же, это зависит от того, как вы работаете лучше всего, но когда другие читают мой HTML, мне нравится делать его действительно организованным :).

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


0

Для Javascript я бы всегда хотел, чтобы он проверялся с помощью JSLint, я могу вспомнить так много ошибок, которые JSLint ловит, что неиспользование его просто сумасшествие.


0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.