- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 23 Nov 2009 13:02:13 -0800
- 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 UTC