W3C home > Mailing lists > Public > www-style@w3.org > November 2009

Re: [css3-background] last call for comments on "Backgrounds and borders"

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 23 Nov 2009 13:02:13 -0800
Message-ID: <4B0AF855.5030001@inkedblade.net>
To: Zack Weinberg <zweinberg@mozilla.com>
CC: Www-style <www-style@w3.org>
Zack Weinberg wrote:
> fantasai <fantasai.lists@inkedblade.net> wrote:
>> Zack Weinberg wrote:
>>> It seems to me that the border-image shorthand would be more user
>>> friendly if it allowed slashes between any two option groups.
>>> Something like
>>>
>>>     <‘border-image-source’> || /? <‘border-image-slice’>  
>>>         [ / <‘border-image-width’>? [ /
>>> <‘border-image-outset’>  ]? ]? || /? <‘border-image-repeat’>
>>>
>>> I *think* this does not make the grammar ambiguous, and it means
>>> authors don't have to remember which blocks take slashes and which
>>> don't.
>> The CSS Working Group has discussed your proposal and decided not
>> to make this change. You can read the minutes of the discussion
>> here:
>> <http://lists.w3.org/Archives/Public/www-style/2009Nov/0265.html>
> 
> I don't care strongly about this, but I wish to point out that the
> discussion as minuted sounds like people thought I was proposing to
> *require* slashes, which was not my intention.  Rather, I thought it
> would be friendly to *permit* slashes between any two option groups.
> As is, authors have to remember that you *do* put a slash between slice
> and width, width and outset, but *not* between source and slice or
> before repeat.  Which is fine (especially now that I realize what || in
> the syntax actually means) but for people who don't want to remember
> that, allowing a slash would make life simpler.

I didn't get that impression; the arguments presented against are as valid
for an optional slash as for a required one.

   - It's not required for parsing
   - It's inconsistent with syntax elsewhere in CSS

I'll even add one

   - Making it optional may be easier for writing out the rule, since
     mistakes are absorbed, but it makes it more confusing for reading:
     is the slash here significant or not? does it mean something
     different now? is it an error? should I remove it? add them to my
     other rules? do I need to worry about which browsers need or can't
     handle the extra slashes? etc.

I don't care too strongly here, but I suspect making this change is
   a) less than helpful for both authors and implementors
   b) more likely to result in parsing inconsistencies across implementations
Therefore I would rather not make this change.

Is that adequate reasoning for the rejection, or is there something else
you would like us to consider here?

~fantasai
Received on Monday, 23 November 2009 21:02:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:22 GMT