Re: Comment syntax

On Fri, Aug 24, 2012 at 3:54 AM, Kang-Hao (Kenny) Lu
<kanghaol@oupeng.com> wrote:
> (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]*

Yeah, the grammar change is easy (and just as trivial in Syntax).

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

Agreed.  (I already use a / prefix to comment out properties when I need to...)

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

This actually is part of the reason not to add it at this point.
There's a minor risk that making the above into a valid comment
followed by a property (rather than an invalid property name) may
break sites, as they end up accidentally depending on the following
property not working.

> (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. ^_^

In response to myself, there was suggestion at the last f2f that we
should use || or something for the column combinator instead, which
has a certain interesting logic to it.

> 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.

Yes, I think requiring a space there is an adequate solution to the
grammar problem.  Nothing would need to change in B&B - it would just
be a consequence of the core grammar that you need the space to make
it parse as two DELIM(/) tokens rather than a single comment token.

> (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.

Yeah, making a decent argument against the compat risk would be
helpful.  A well-constructed regex against web200904 should make it
easy to spot-check things.

~TJ

Received on Friday, 24 August 2012 17:21:01 UTC