Strawman proposal for tweaking background shorthand syntax to address position/size complexity

I was looking at the background property's syntax recently and noticed that |background: / contain;| is acceptable per the current definition.  This excess bleed-through of disambiguating constructs into unambiguous syntax is a bit unseemly to me (and apparently to others from what I hear).  Here's one idea that gets rid of the extra '/' and otherwise doesn't make much other change.  I have no particular love for this proposal except that it's close to a patch I wrote to Gecko for this, but I figure it's worth throwing out as something to consider assuming more radical syntax changes are undesirable.

The current syntax for a layer (and for the final layer with minor adjustment), with some prose restrictions on where <bg-size> may appear, is:

<bg-layer> = <bg-image> || <bg-position> || / <bg-size> || <repeat> || <attachment> || <bg-origin> || no-clip

Instead, I suggest this:

<bg-layer> = <bg-image> || [ [ <bg-position> [ / <bg-size> ]? ] | <bg-size> ] || <repeat> || <attachment> || <bg-origin> || no-clip

with a note if while parsing the <bg-layer> option an ambiguity between parsing as <bg-position> and as <bg-size> is encountered, the values are treated as <bg-position>.

The advantages are that 1) no random slash need appear in a layer which contains only a <bg-size>, and 2) it's clear that <bg-size> must immediately follow a position rather than simply following "after" it by an uncertain amount (immediately after?  after any number of intervening items?  only the immediately-after case requires disambiguating).  The "disadvantages" are that it's substantially similar to syntax that has unpleasant complexities.

One further complexity of note for further background shorthand syntax discussion: some (but not all) engines in so-called quirks mode interpret an unadorned number as if it were a color when parsing the background shorthand, which adds another ordering dependency between <bg-position> and <'background-color'> for <final-bg-layer>.  I don't know how much this matters in practice if it's not the same in all browsers, and I don't know how much the CSSWG generally cares about such problems.

Jeff

Received on Saturday, 9 May 2009 23:05:38 UTC