Почему CSS не допускает однострочные комментарии? [закрыто]

Я понимаю, что CSS поддерживает только многострочные комментарии, такие как

/* foobar */

Почему нет поддержки однострочных комментариев.

// foobar

Они так же распространены в программировании и кажутся особенно полезными для такого языка, как CSS, где каждое правило находится на отдельной строке.

Если для этого решения не было конкретной исторической причины, что мешало браузерам перейти к его поддержке?

Обратная совместимость

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

CSS определяется с очень точными «устойчивыми к ошибкам» правилами синтаксического анализа, что означает, что даже если вы пишете что-то синтаксически недопустимое, существуют точные правила о том, как должен выполняться анализ. Если в объявлении обнаружена недопустимая последовательность символов (например, //), текущее объявление отбрасывается и все до следующей точки с запятой пропускается.

CSS разработан так, чтобы позволить ввод нового синтаксиса, не ломая старые браузеры. Старые браузеры просто пропускают объявление, которое содержит неподдерживаемый синтаксис, и продолжают после.

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

Пример:

P { font: 12px//16px; }
... hundreds of additional lines of CSS...

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

Теперь вы можете сказать, что это моя вина, так как я допустил ошибку, но это не меняет того, что неизвестное количество страниц в Интернете может сломаться или странным образом отобразиться по непонятным причинам.

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

Так что, если у CSS должны быть однострочные комментарии, его, вероятно, следовало бы ввести с самого начала. Но CSS начинался как очень простой язык, и в то время наличие двух разных синтаксисов комментариев казалось бы ненужной сложностью. (Даже ANSI C не имел однострочных комментариев.)

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

Если бы это было важно для языка, то есть сделало жизнь разработчиков намного проще, это можно было бы сделать. Например, отсутствие каких-либо комментариев в CSS было бы отстой, и стоило бы приложить усилия для добавления определенных элементов синтаксиса, которые разделяют комментарии. //с другой стороны, как стиль комментариев? ... Я не вижу смысла. Смотрите /* Hello, World! */: комментарий в одну строку.

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

Аналогично, программист на Python будет утверждать, что CSS также должен иметь #комментарии в стиле; так что теперь, нам нужно поддерживать оба стиля? Тогда парень из мира Haskell попросит включить --и его {- -}, и вы спросите себя, почему вы больше не узнаете код CSS.

Небольшое преимущество //заключается в том, что вам не нужно вводить еще три символа в конце вашего однострочного комментария (на самом деле, если мы начинаем считать символы, CSS должен использовать комментарии в стиле Python). Однако, если вы используете приличный текстовый редактор, вы комментируете / раскомментируете текст, просто нажимая на ярлык.

Они [...] кажутся особенно полезными для такого языка, как CSS, где каждое правило находится в отдельной строке.

Как я объяснил, они мало полезны для небольшой группы программистов, использующих небольшую группу текстовых редакторов. Что касается вашего замечания о каждом правиле в отдельной строке (кстати, я не согласен с вашим замечанием), это заставило меня задуматься над другим моментом: как на самом деле используются комментарии.

Вот использование комментариев CSS, о которых я могу думать:

• В качестве заголовка файла (информация об авторских правах, тщеславие и т. Д.)
• Как разделитель группы стилей.
• Как объяснение взлома.
• Как подробно о конкретном стиле или собственности.

В первых трех случаях вы все равно будете использовать многострочные комментарии. Это очевидно для заголовка файла и объяснения взлома (для большинства взломов требуется хотя бы предложение и гиперссылка на StackOverflow или статью в блоге); Что касается разделителей:

/**
 * Footer and sitemap styles.
 */

Комментарий в стиле C гораздо более заметен, чем:

// Footer and sitemap styles.

похоронен в тексте.

Проблема заключается в том, что большинство языков с комментариями (например, C #, Java) являются скомпилированными языками, и компилятор удаляет ВСЕ комментарии, прежде чем представлять контент потребителю (ЦП). CSS не компилируется; Как правило, файл отправляется без изменений, так как его разработчик разработал, поэтому нет возможности удалить комментарии. Для комментария в стиле // требуется как символ //, так и перевод строки, чтобы сохранить синтаксическую корректность.

Да, минифайеры существуют, и да, javascript допускает комментарии такого типа. Javascript также позволяет eval (), поэтому я не думаю, что мы хотим принять это за модель.