Tại sao CSS không cho phép nhận xét một dòng? [đóng cửa]

Tôi hiểu rằng CSS chỉ hỗ trợ nhận xét nhiều dòng như vậy

/* foobar */

Tại sao không có hỗ trợ cho các bình luận dòng đơn.

// foobar

Chúng chỉ phổ biến trong lập trình và có vẻ đặc biệt hữu ích cho một ngôn ngữ như CSS trong đó mỗi quy tắc nằm trên dòng riêng của nó.

Nếu không có lý do lịch sử cụ thể cho quyết định này, điều gì đã ngăn các trình duyệt chuyển sang hỗ trợ nó?

Khả năng tương thích ngược

Giới thiệu các nhận xét một dòng cho cú pháp CSS có thể thay đổi ý nghĩa của các tệp hiện đang sử dụng mã thông báo //. Các nhà cung cấp trình duyệt rất miễn cưỡng giới thiệu các thay đổi có khả năng phá vỡ các trang hiện có.

CSS được định nghĩa với các quy tắc phân tích cú pháp "chịu lỗi" rất chính xác, điều đó có nghĩa là ngay cả khi bạn viết một cái gì đó bất hợp pháp về mặt cú pháp, vẫn có các quy tắc chính xác về cách tiến hành phân tích cú pháp. Nếu một chuỗi ký tự bất hợp pháp (như //) được phát hiện bên trong một khai báo, thì khai báo hiện tại sẽ bị loại bỏ và mọi thứ cho đến khi dấu chấm phẩy tiếp theo bị bỏ qua.

CSS được thiết kế như thế này để cho phép giới thiệu cú pháp mới mà không phá vỡ các trình duyệt cũ. Các trình duyệt cũ sẽ chỉ bỏ qua khai báo có chứa cú pháp không được hỗ trợ và tiếp tục sau đó.

Nhưng logic này giả sử "đơn vị" được xử lý hoặc bỏ qua là khai báo. Nếu các bình luận một dòng được đưa ra, điều đó có nghĩa là phân tích cú pháp sau đó //nên bỏ qua cho đến khi ngắt dòng tiếp theo thay vì cho đến dấu chấm phẩy tiếp theo, thay đổi quy tắc nào được phân tích cú pháp và bỏ qua. Điều này có khả năng thay đổi ý nghĩa của các tệp CSS hiện tại theo những cách đáng ngạc nhiên.

Một ví dụ:

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

Ở đây tôi nhầm gấp đôi dấu gạch chéo. Hậu quả là khai báo phông chữ bị bỏ qua, nhưng tất cả phần còn lại hoạt động tốt. Nếu hỗ trợ cho các sự //cố được giới thiệu, đột nhiên dấu ngoặc kép sẽ được nhận xét, có khả năng phá vỡ tất cả phần còn lại của biểu định kiểu.

Bây giờ bạn có thể nói đó là lỗi của riêng tôi kể từ khi tôi mắc lỗi, nhưng điều này không thay đổi rằng một số lượng trang không xác định trên internet có thể bị hỏng hoặc hiển thị kỳ lạ vì những lý do mơ hồ.

Bất kỳ thay đổi nào phá vỡ tính tương thích ngược nên được xem xét rất cẩn thận và các nhận xét một dòng có lẽ không đủ sức thuyết phục cho rủi ro, vì lợi ích duy nhất là nó giúp bạn tiết kiệm một vài lần nhấn phím.

Vì vậy, nếu CSS nên có các bình luận đơn lẻ thì có lẽ nó đã được giới thiệu ngay từ đầu. Nhưng CSS khởi đầu là một ngôn ngữ rất đơn giản và có hai cú pháp nhận xét khác nhau sẽ được coi là phức tạp không cần thiết vào thời điểm đó. (Ngay cả ANSI C cũng không có nhận xét một dòng.)

Hỗ trợ một yếu tố cú pháp khác không dễ dàng như vậy: có rất nhiều công cụ có thể xử lý kiểu nhận xét bổ sung. Trên thực tế, tôi sẽ không ngạc nhiên khi thấy rằng hầu hết các mã thông báo / trình phân tích cú pháp chỉ đơn giản bỏ qua các dòng mới, có thể thay thế chúng bằng ;.

Nếu nó là điều cần thiết cho ngôn ngữ, tức là làm cho cuộc sống của các nhà phát triển dễ dàng hơn nhiều , điều này có thể được thực hiện. Ví dụ, không có bất kỳ loại bình luận nào trong CSS sẽ bị thu hút và sẽ rất đáng để nỗ lực thêm các yếu tố cú pháp cụ thể để phân định các bình luận. //Mặt khác, bình luận kiểu gì? ... Tôi không thấy vấn đề. Xem , /* Hello, World! */: một bình luận một dòng.

Trên thực tế, bạn có thể mong đợi các //nhận xét kiểu vì bạn đã quen với chúng trong C ++ hoặc các ngôn ngữ tương tự. Tuy nhiên, CSS không kế thừa từ C ++, do đó, việc mong đợi các tính năng cú pháp tương tự là khá lạ.

Tương tự, một lập trình viên Python sẽ tuyên bố rằng CSS cũng nên có các #nhận xét kiểu; Vậy bây giờ, chúng ta có cần hỗ trợ cả hai phong cách không? Sau đó, một anh chàng từ Haskell thế giới sẽ yêu cầu bao gồm --và {- -}là tốt, và bạn sẽ tự hỏi mình tại sao bạn không nhận ra mã CSS nữa.

Lợi ích nhỏ bé //là bạn không phải nhập thêm ba ký tự vào cuối nhận xét một dòng của mình (thực ra, nếu chúng ta bắt đầu đếm các ký tự, CSS nên sử dụng các nhận xét kiểu Python). Tuy nhiên, nếu bạn sử dụng một trình soạn thảo văn bản đàng hoàng, bạn bình luận / bỏ ghi chú văn bản chỉ bằng cách nhấn một phím tắt.

Chúng [...] có vẻ đặc biệt hữu ích cho một ngôn ngữ như CSS trong đó mỗi quy tắc nằm trên dòng riêng của nó.

Như tôi đã giải thích, chúng chỉ hơi hữu ích, đối với một tập hợp nhỏ các lập trình viên, sử dụng một tập hợp nhỏ các trình soạn thảo văn bản. Đối với nhận xét của bạn về mỗi quy tắc trên dòng riêng của nó (tôi không đồng ý với nhận xét của bạn), điều này khiến tôi suy nghĩ về một điểm khác: cách các bình luận thực sự được sử dụng.

Đây là cách sử dụng các bình luận CSS mà tôi có thể nghĩ ra:

• Là một tiêu đề tệp (thông tin bản quyền, công cụ phù phiếm, v.v.)
• Là một dấu phân cách của một nhóm các phong cách.
• Như một lời giải thích về một hack.
• Như một chi tiết về một phong cách hoặc tài sản cụ thể.

Trong ba trường hợp đầu tiên, bạn sẽ sử dụng các nhận xét theo kiểu đa dòng. Điều này là rõ ràng đối với tiêu đề tệp và giải thích về hack (hầu hết các bản hack yêu cầu ít nhất một câu và siêu liên kết đến StackOverflow hoặc một bài viết trên blog); đối với các dấu phân cách:

/**
 * Footer and sitemap styles.
 */

Nhận xét kiểu C hiển thị rõ hơn nhiều so với:

// Footer and sitemap styles.

chôn cất trong văn bản.

Vấn đề là hầu hết các ngôn ngữ có ý kiến ​​(ví dụ C #, Java) là ngôn ngữ được biên dịch và trình biên dịch loại bỏ TẤT CẢ các bình luận trước khi trình bày nội dung cho người tiêu dùng (CPU). CSS không được biên dịch; nói chung, tệp được gửi không thay đổi khi người thiết kế phát triển nó, vì vậy không có cơ hội để loại bỏ các bình luận. Nhận xét kiểu // sau đó yêu cầu cả ký hiệu // VÀ nguồn cấp dữ liệu để giữ đúng tính cú pháp.

Có, công cụ khai thác tồn tại và có, javascript cho phép loại nhận xét này. Javascript cũng cho phép eval () vì vậy tôi không nghĩ chúng ta muốn lấy nó làm mô hình.