Неплохая ли практика комментировать одиночные строки CSS с помощью//?

Ответ 1

В первую очередь: код с комментариями запах кода и его следует избегать. Я предполагаю, что вы используете VCS, например Git, который обрабатывает вам исторический код.

Но если вы действительно хотите работать таким образом: вы не знаете, как будущие и/или экзотические браузеры будут интерпретировать неофициальные хаки типа //, поэтому лучше придерживаться соответствующих обозначений:

li {
    float:left;
    text-indent:0px;
    /* list-style-type:none; */
}

Ответ 2

Я вижу, что есть/есть много людей, жалующихся на это, и поскольку это старый вопрос, вероятно, многие люди читают его, задаваясь вопросом, действительно ли это так, или если в первом есть стандарт в первом место. Позвольте мне очистить воздух. Ниже приводятся основные причины строгой политики комментариев CSS:

# 1 Он не является стандартным

Стандартизованный, по крайней мере, с css 2.1, комментарии должны быть ТОЛЬКО заключены в /* и */. В то время как некоторые браузеры терпят //, они не должны, и они всего лишь на дюйм от кого-то, говорящего "о да, это нестандартное" или "эй! Это нестандартное, исправить!"; и затем угадайте, что, ваш код css, который работает, теперь не для тысяч людей (и, возможно, уже не работал для сотен других). Я добавлю, что <!-- и --> разрешены, но только (и я имею в виду ТОЛЬКО), когда они появляются в документе HTML, а не в исходном файле .css. Если ваш браузер настолько стар, что не может пропустить теги <style>, это, вероятно, время для нового браузера 10 лет назад. Даже рыси и другие текстовые браузеры знают, что они не читают их, поэтому комментирование это полезно только в очень изолированной ситуации, когда аппаратное и программное обеспечение не имеет выхода к морю в своем текущем рабочем состоянии.

# 2 Это не очень (очень) межплатформенная дружба

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

# 3 Стандарт дружественный и равномерный для всех

Разделители /* и */ ВСЕГДА будут одинаковыми символами на КАЖДОМ компьютере независимо от архитектуры, операционной системы и т.д.

# 4 Новые строки - это пробелы

Последняя причина (да, есть еще одна), символ новой строки (в CSS и многие другие языки) считаются пробелами, а */ не является пробелом? И если вы думаете об этом в этот момент, должно быть довольно ясно, что вы НЕ должны использовать пробел, чтобы прервать комментарий, особенно, поскольку пробелы есть и могут быть удалены многими парсерами HTML/CSS или переформатированы, даже если вы даже не знаете об этом.

# 5 CSS!= C/С++

Теперь, если вы собираетесь вылететь со своего места и кричать на меня о "эй, но С++....", помните, что у тех компиляторов и IDE есть тонны проверки и обнаружения новой строки, встроенные в них, чтобы они могли ее взять. Большинство компиляторов не переформатируют ваш код, если не заданы, и многие IDE обычно спрашивают вас, какие новые строки использует ваш документ, если он не может догадаться об этом. Если бы мы делали это с CSS-страницами для конечного пользователя каждый раз, когда он был загружен, представьте себе, какой кошмар он попытается обойти. Кроме того, код C/С++ не анализируется во время выполнения и скомпилирован, поэтому большую часть времени пользователь никогда не получает этот документ в первую очередь. Исходные файлы не постоянно просматриваются во всем мире на сотнях платформ и многих операционных системах, а также в миллионах браузеров. Комментарии удаляются до того, как они когда-либо доходят до конечного пользователя. Источник CSS поступает прямо в пользовательский браузер и должен быть очень устойчивым, не зная, что находится на другой стороне, поэтому предостережение в том, что оно должно быть готово ко всему, что имеет или делает конечный пользователь, а не что-либо, что делает разработчик или имеет!

# 6 Это неудобно

Нет, очень неприятно набирать этот дополнительный */, но вину за это в основном касается разработчиков программного обеспечения для редактирования CSS, которые не предлагают автоматическое завершение. Если вы используете специализированный редактор, который может это сделать, желательно из коробки, то вы найдете это так же просто, как с помощью //. Получите привычку печатать /**/, а затем backspace 2, это поможет вам не забыть и сделать это немного легче. Еще лучше, вы можете настроить горячую клавишу, чтобы просто сложить их для себя. У Windows и Linux есть мощные инструменты, позволяющие это сделать (KDE очень хорош для этого).

Надеюсь, это поможет всем понять "почему" за "как" и помнить только потому, что что-то работает для вас, не означает, что это стандарт, и подвести итог:

ДА ЭТО ПЛОЩАДЬ ПРАКТИКА, чтобы использовать его, просто скажите "НЕТ" с двойной косой чертой!Если вам нужна наглядная помощь, чтобы напомнить вам об этом важном факте, просто сожгите это изображение в своем уме (спасибо тем, кто не имеет ничего лучшего, кроме как сделать такие снимки):

PS: Если вы действительно хотите, чтобы что-то жаловалось тем, кто создает/нарушает стандарты CSS (w3c, elbow), кто-то начинает обсуждение о том, как неоправданно длинное и неправильное ключевое слово "! important"! Но это не является частью этого вопроса, поэтому я не буду вдаваться в него.

Ссылки

• w3c: рабочий код CSS 2.1: символы комментариев.
• w3c: модуль синтаксиса CSS 3-го уровня: диаграммы железных дорог интерпретаторов от парсер к символу.
• so: различные статьи SO с практически тем же предметом, что и этот.
• w3schools: стандарт синтаксиса CSS 3 (который, в свою очередь, ссылается на w3c).
• sitepoint: синтаксическая аннотация CSS-синтаксиса на тему "не использовать двойную косую черту".
• mozilla | mdn: расслабленная обработка css3 допускает двойную косую черту во входных файлах.

Ответ 3

Недавно я прочитал эту статью, которая проливает много света на однострочную комментирующую практику в CSS.

CSS позволяет использовать // после мода. Это не совсем комментарий строки, но следующий комментарий к конструкции. То есть всякий раз, когда вы используете //, следующая конструкция CSS - декларация или блок - будет "прокомментирована".

Итак, в вашем фрагменте кода list-style-type:none является следующей конструкцией CSS и она закомментируется.

li {
    float:left;
    //list-style-type:none;
    text-indent:0px;
}

Аналогично, в приведенном ниже фрагменте кода

//@keyframes foo {
  from, to { width: 500px; }
  50% { width: 400px; }
}
@keyframes bar {
  from, to { height: 500px; }
  50% { height: 400px; }
}

// будет комментировать первое объявление @keyframes.

Если вы пытаетесь использовать // только для написания комментариев в своей таблице стилей, вы должны быть осторожны - необработанный текст не является конструкцией CSS, поэтому он будет выглядеть мимо и комментировать следующую конструкцию на вашей странице, Итак, в нижеприведенном фрагменте

// Do some stuff.
.foo { animation: bar 1s infinite; }

Это закомментирует блок .foo.

Вы можете получить дополнительную информацию через связанную статью, упомянутую в начале.

Ответ 4

В соответствии с рабочим проектом ничего похожего на однострочный комментарий.

Ответ 5

Да, я думаю, что использование однострочных комментариев в их текущем состоянии - это плохая практика.

Для начала, если вы работаете в командной среде, то удобство обслуживания/удобочитаемость кода имеет первостепенное значение, и даже если вы работаете в одиночку, написание поддерживаемого кода по-прежнему является хорошей практикой, иначе произойдет безумие.

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

Кроме того, одиночные и многострочные комментарии не являются взаимозаменяемыми, например, вы не можете использовать сырые текстовые комментарии, не используя хак, а вы можете только комментировать конструкции //.foo {...} или rules .foo {//height:10px}.

Необязательный экземпляр:

ul.images {
    padding: 0;
    //static height value
    height: 270px;
    margin: 0 auto;
}
ul.images {
    padding: 0;
    /*static height value
    height: 270px;*/
    margin: 0 auto;
}

Теперь взаимозаменяемый (из-за взлома конструктора):

ul.images {
    padding: 0;
    //static height value{};
    height: 270px;
    margin: 0 auto;
}
ul.images {
    padding: 0;
    /*static height value*/
    height: 270px;
    margin: 0 auto;
}

При использовании конструктора {};, поскольку постфикс будет работать, IMO побеждает цель его использования, потому что вы будете использовать больше символов; многострочный комментарий использует четыре символа, /**/, тогда как однострочный комментарий с хаком использует пять символов, //{};

Последнее предупреждение однострочных комментариев, которое еще не было упомянуто, заключается в том, что Chrome инструменты разработчика скроют комментарий - а не позволяет вам переключаться между ними.

Инструменты разработчика Chrome (многострочный комментарий):

Инструменты разработчика Chrome (однострочный комментарий):

Хороший вариант использования IMO для однострочных комментариев будет заключаться в том, когда вам нужно прокомментировать весь конструктор, который действительно длинный (пример не будет).

Комментирование всего конструктора

//ul.images {
    padding: 0;
    height: 270px;
    margin: 0 auto;
}

/*ul.images {
    padding: 0;
    height: 270px;
    margin: 0 auto;
}*/

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

Ответ 6

Я бы рекомендовал не комментировать CSS, как это, когда это не нужно. Удалите материал, который вам не нужен, и передайте его в репозиторий SVN или GIT. Пусть он выполняет свою работу и отслеживает историю для вас. Накопленные комментарии, подобные этому, становятся жесткими, что затрудняет чтение и понимание вашего кода.

Ответ 7

Я использую // для "прокомментировать" строки в .css файлах все время. Потому что он связан с ярлыком в Vim, и я всегда забываю, что редактирую. В JavaScript очень удобно комментировать блоки кода, проверять код и "комментировать" блок кода снова (ярлыки, да).

Но когда я аккуратно копирую свой .css файл, я использую следующие конструкции для более легкого перемещения объявлений внутри и вне области видимости:

.pin {
    /*
    position: absolute;
    background: url(buttons-3x3.png);
    background-color: red;
    */
    height:50px;
    width:150px;
    position: relative;
}


.shadow {
    margin-top: 25px;
    margin-left: 25px;
    margin-left: 60px;
    width:50px;
    height:50px;
    background: url(playground.png) -400px -100px;
    position: relative;
    position: absolute;
}

В .pin я могу удалить строку и добавить ее в область комментариев и наоборот. В .shadow я просто переопределяю одно и то же свойство с другим значением.

Это боль.

! important

Ответ 8

Как говорили другие, использование двойной косой черты не соответствует стандартам, но если вы действительно хотите ее использовать И хотите быть совместимыми со стандартами И у вас установлена ​​gcc, вы можете запустить свой CSS через cpp -P, чтобы вырезать все двойной слэш и /*... */комментарии из CSS. В качестве бонуса вы можете использовать макросы, включения и условные обозначения, а комментарии не загружаются браузером (незначительное повышение производительности).

Единственная серьезная проблема заключается в использовании автономных тегов id (т.е. #para { ... }), где cpp barfs. Решение есть double # (to ##) и передать результат через sed, например:

cpp -P site.cssin | sed -e 's/^##/#/' >site.css

Я уверен, что есть препроцессоры, ориентированные на CSS, но это сработало для меня.

Ответ 9

Для встроенных комментариев CSS я использую:

.myDiv {
    @width:750px;  
}

или любой желаемый символ (т.е. *@!ZZ) Таким образом, свойство становится неизвестным и не читается css.

Ответ 10

Комментарий в HTML:

<!--........................-->
<!--  <input type="text" name="lastname">-->

Комментарий в JavaScript:

Однострочный комментарий:

Две косые черты "//" перед кодом:

//document.write("Try this");

Многострочный комментарий:

<script type="text/javascript">
    <!--

    /* document.write("try this!");

    document.write("try this"); */
    //-->

</script>

Код комментария в CSS:

/*
.tblemp {
color:red; }

*/

Подробнее

Ответ 11

Просто добавьте дополнительную информацию и подтвердите правило "только использовать /* комментарии". Клиент, у которого есть доступ к папке веб-сайта, просто выбирает сам, чтобы прокомментировать одну строку, используя это:

//*  comment here   *//

Фактически Chrome и Safari будет игнорировать НИЧЕГО, что следует за этой строкой; Я бы назвал это "убийцей CSS".