W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: [css-background] Order of properties in background shorthand

From: L. David Baron <dbaron@dbaron.org>
Date: Fri, 1 Jun 2012 10:18:26 -0700
To: tony chang <tony@chromium.org>
Cc: www-style@w3.org
Message-ID: <20120601171826.GA12437@crum.dbaron.org>
On Friday 2012-06-01 17:05 +0000, tony chang wrote:
> The example Joe Thomas gave isn't the same one that was originally brought up in 
> a webkit bug.  The problem is that copy/paste won't work between browsers.  For 
> example, if you copy from a trunk version of Chrome (canary) in an older version 
> (stable), the whole declaration will get thrown away since the older version 
> doesn't recognize part of the property.
> The original example is also pretty common.  E.g., suppose you're composing an 
> email in a rich text web mail site.  You could paste some HTML into your email 
> and save a draft on one computer and try to load it on another computer.  The 
> same would happen with a wiki that uses rich text.
> We could always expand the background property into its specific fields when we 
> generate the HTML for the clipboard, but that's really verbose.

This problem should be *mostly* solved by generating the minimal
form, as required by the text:
  # When dealing with CSS "shorthand" properties, the shorthand
  # properties should be decomposed into their component longhand
  # properties as appropriate, and when querying for their value,
  # the form returned should be the shortest form exactly equivalent
  # to the declarations made in the ruleset. However, if there is no
  # shorthand declaration that could be added to the ruleset without
  # changing in any way the rules already declared in the ruleset
  # (i.e., by adding longhand rules that were previously not
  # declared in the ruleset), then the empty string should be
  # returned for the shorthand property.

In other words, when the background-origin, background-clip, and
background-size have their initial values, the "shortest form" text
above says that the background shorthand should not include those

(I think this backwards-compatibility principle should actually be
enshrined as *more* important than the minimal value principle.
That is, when it's possible to serialize in a way that's compatible
with an older level of the standard, that should always be preferred
to a way that is not compatible, even if it's longer.)

That said, if you want to ensure that you have the most
compatibility, you should generally serialize longhands rather than
shorthands when new sub-longhands have been introduced (e.g., always
serialize background as longhands), but shorthands rather than
longhands when a property was split into a shorthand in a later
level (e.g., serialize as overflow rather than as overflow-x/y when


𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Friday, 1 June 2012 17:18:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC