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?

Received on Monday, 23 November 2009 21:02:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:30 UTC