Re: css3-background: grammar issue

On Feb 23, 2010, at 9:32 PM, Yves Lafon wrote:

>>> Replacing '/' by 'as' will indeed help. The second rule was more an example that there were "more restrictive than necessary" rules and just adding one to forbid '/' being first was not out of the line. But the new wording, "must not occur immediately" will make it easier to check anyway, so OK for both.
>> 
>> This does not seem to me like the right thing to do. The arbitrary-seeming rule to disallow a slash+background-size at the beginning seems to me to be "more restrictive than necessary". The slash has been established elsewhere (such as in border-image) as a disambiguating divider, and that seems very clear to me; much more so than "as" as a disambiguating prefix word. When one thinks of 1-2 lengths or percentages as meaning 'background-size' when found anywhere after a slash, and as meaning 'background-position' otherwise, then it is very clear, and no further restrictions are needed. I think all the following should be equally valid, as all seem equally clear:
> 
> The issue comes from the fact that bg-size and bg-position have the same syntax, so one way of fixing this could be to englobe size in a function, like background: size(10% 90%), but it doesn't fly well with background-size: size(10% 90%).

Yes, I well understand that part. Which is why I feel that being on one side or the other of the slash does well to disambiguate, in a way that we are already doing elsewhere.

> But why choosing '/' which is a CSS2 operator ?

border-image: url(img.png) 100 / 50px / 10px;
or...
border-image: url(img.png) 100 / / 10px;

...are CSS3, and not that different in principal from:

background: url(img.png) 10% / 90%;
and...
background: url(img.png) / 90%;
or...
background:  / 90%;

It is also part of the proposed CSS3 gradient property value, where it is used to separate each half of a series of value pairs. 

It is also used in /* comments */, where it does a similarly good job of separating comments from the values around them. 

> Choosing 'as' is a far better choice than '/' for this reason

I disagree. The slash make the separation of groups of values easy to distinguish in a glance, is a bit more compact, and seems completely unambiguous to me. A word, such as "as", does not share those same qualities.  

> (but it could be anything that would be parsed as something else than an operator.

I don't understand your issue against using it as an operator to separate values or groups of values. Why is that a parsing problem? Is it insurmountable, or impose a big performance hit or something?

>> background: url(img.png);
>> background: 10% 90%;  /* bg-position */
>> background: / 10% 90%;  /* bg-size */
>> background: 10% 90% / 10% 90%; /* bg-position, then bg-size */
>> 
>> I think it would be confusing for authors to have to remember that for some reason they could not have just a bg-size as the singleton value for their shorthand just because it still required a slash to its left. And I really do not think it is improved by having "as" instead of "/" as the required text to its left. Of the following four choices, I much prefer the first:
> 
> I think that 'size' is far more readable for authors than '/'.

I am an author, and I don't have any problem at all with the readability of using a slash as a separator. It feels very natural. Whereas having extra text to read and associate with values following the text would be much more cumbersome and overly verbose, especially if we were to make the other parts of the shorthand consistent, as in the following:

background: image url(foo.png) position 10% 90% size 50% repeat no-repeat attachment fixed;

Not very short for a shorthand, but it would be very odd to have this type of hint for just one part of the shorthand:

background: url(foo.png) 10% 90% size 50% no-repeat fixed;

I really don't find any of that as readable as separating the bg-size from the bg-position via a slash.


> Another solution is to forbid size in the background shorthand property.

How is that better than a slash? For me, that falls into the "more restrictive than necessary" category. If I were to chose between allowing a slash to disambiguate or throwing away the capability to include all background properties in the background shorthand, I would choose the former in a heartbeat. 

>> background: / 10% 90%;
>> background: as 10% 90%;
>> background: size 10% 90%;
>> background: some-other-text 10% 90%;
>> 
>> As for this:
>> 
>>> background: url("foo.png") / 10em black 10em
>> 
>> ...it just doesn't make any sense to me. The first 10em must be bg-size, because it is after the slash, but then there is a second 10em (separate, due to the 'black') after the slash too? How can that be interpreted as anything other than a mistake, when slashes are used to separate and group the values of the shorthand, same as in border-image?
> 
> slash is used to identify bg-size, but you are right, slash is an operator used to separate and group values, which is not what it does when it appears first (same with comma).

I disagree. To me, it still separates the bg-position part (even if it is null) from the bg-size part. But even if we disallowed starting the shorthand values with a slash, I still prefer a slash to a keyword. But disallowing it in that spot just seems like an artificial and unnecessary restriction that authors would have to remember, just for the sake of some sort of purity principal of not having an empty set of values to its left.