- 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