Re: Comment syntax

(12/08/22 14:22), Jens O. Meiert wrote:
> an older subject for which I don’t recall any recent discussions—are
> there any plans to extend CSS’s comment syntax? Like, allowing
> one-line comments via e.g. “//”?

These threads are relevant: [1][2][3], and there was also this meeting
minutes[4]. I collected them because I am curious if this is the second
most frequent request, after parent selectors :p

So the concrete proposal for "//" comment would be:

A. In CSS 2.1, change

  # COMMENT  \/\*[^*]*\*+([^/*][^*]*\*+)*\/

to

  | COMMENT  \/\*[^*]*\*+([^/*][^*]*\*+)*\/
  |            |\/\/[^\n\r\f]*

. In [2], Anne and Bert pointed out that a prefix, say, "x-" would solve
the use case of commenting out a declaration. For example,

  div {
    width: 5em;
    x-color: red; /* this is commented out*/
    margin: 0 auto;
  }

However, this "x-" scheme isn't standardized and browsers throw errors
to console when seeing properties like that. Therefore,

B. Standardize a prefix for properties commented out.

would be an option. Nonetheless, I honestly don't believe this is the
way to go. Besides aesthetic reasons (which I have no doubt to be the
major ones), having different one-line comment syntax for JS and CSS is
just making the Web platform difficult to learn. Also, this solution
doesn't really cover side comments like

  div {
     //...
     width: 5em;
  }

. There is of course the no change proposal C.

(12/08/22 14:58), Tab Atkins Jr. wrote:
> There are currently no such plans.  It would mean a change to the core
> grammar.  It would also mean that the // combinator we're using for
> table columns wouldn't work. ^_^

Besides the future, "//" is actually used in CSS3 B&G as in

  div {
    border-image: 20% // 1; /* 'border-image-width: initial;' */
  }

, though I don't think this is a common case nor do I like the decision
to allow omitting the middle value (see [5]). I don't think it's too bad
to ask authors to type "/ /" instead of "//" in this situation.

(12/08/22 23:31), Jens O. Meiert wrote:
> What case would need to be built to have this considered? I’d deem
> the“//” comment syntax a useful and otherwise straight-forward
> “feature.”

The biggest problem to the adoption of A. is of course compatibility
risks. Therefore, to prove or disprove that there's no serious
compatibility problems there are two things that can be done here.

1. Use an experimental build that implements A. for a while and see if
you can survive.

2. Do compatibility research with a Web corpus, say, running grep on
dotnetdotcom's web200904[6].

You can also do other things that produce new data (say, do a poll and
prove that very few people can accept B.). I don't guarantee that doing
any of these would change browser implementor' willingness to adopt this
feature though.

[1] http://lists.w3.org/Archives/Public/www-style/2002Sep/thread#msg160
[2] http://lists.w3.org/Archives/Public/www-style/2005Dec/thread#msg9
[3] http://lists.w3.org/Archives/Public/www-style/2010Mar/thread#msg311
    http://lists.w3.org/Archives/Public/www-style/2010Apr/thread#msg19
[4] http://lists.w3.org/Archives/Public/www-style/2010Mar/0539
[5] http://lists.w3.org/Archives/Public/www-style/2012Mar/0179
[6] http://dotnetdotcom.org/#inde


Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/

Received on Friday, 24 August 2012 10:55:44 UTC