Чому 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 (), тому я не думаю, що ми хочемо сприймати це як модель.