W3C home > Mailing lists > Public > www-style@w3.org > May 2008

[css3-background] Issues and Proposed Resolutions

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 13 May 2008 23:28:58 -0700
Message-ID: <482A86AA.5090304@inkedblade.net>
To: www-style@w3.org

Bert and I went through all the open CSS3 Backgrounds and Borders issues
on Monday. Here are our conclusions. If there are no objections, we plan
to close the first three categories with the resolutions suggested below
after next week's telecon. (The last category needs further discussion.)

Issues to Close No Change

Rename 'each-box' value of 'background-break' to 'discontinuous'.
   http://www.w3.org/Style/CSS/Tracker/issues/23 ISSUE-23

   No change. Bert and I felt 'each-box' is both clearer and easier to


Make border-image border widths not affect width calculations.

   No change. The current behavior and the proposed behavior address
   different use cases, and you can approximate the proposed behavior
   with multiple backgrounds. (The advantage of the current behavior
   is that you don't lose padding depending on whether border-image
   is used or not. If the outer width needs to be constant, border-box
   sizing can be used.)


Allow 'background-repeat: round' to stretch instead of shrink.
   http://www.w3.org/Style/CSS/Tracker/issues/20 ISSUE-20

   No change. In most cases it is better to shrink than to stretch. We
   didn't see much value in allowing images to stretch here.


Merge 'background-origin' property with something else.
     http://www.w3.org/Style/CSS/Tracker/issues/13 ISSUE-13

   No change. Several different properties depend on the value of this
   property, and it doesn't fit very naturally anywhere else. We plan
   to merge it with 'background-clip' in the shorthand, however:
   see Issue 24.


Change name of 'background-size' to something else.
   http://www.w3.org/Style/CSS/Tracker/issues/18 ISSUE-18

   No change. The name is not ideal, but there were no significantly
   better suggestions.


Feature Requests to Reject

Proposal for a 'text' value for 'background-clip'
   http://www.w3.org/Style/CSS/Tracker/issues/17 ISSUE-17

   Rejected. Or perhaps "retracted" is more accurate here. We're
   not against adding the functionality to CSS, it just doesn't fit
   well as a background.
   See http://lists.w3.org/Archives/Public/www-style/2008Apr/0067.html
   and http://lists.w3.org/Archives/Public/www-style/2008Apr/0066.html


Allow four coordinates on 'background-position'.
   http://www.w3.org/Style/CSS/Tracker/issues/21 ISSUE-21

   Reject. This is very similar to ISSUE-12 (which was also rejected)
   and 'background-size' is a more straightforward syntax for affecting
   the image size.


Add 'transparent' keyword for centerless border images.
   http://www.w3.org/Style/CSS/Tracker/issues/28 ISSUE-28

   Reject. The use case is saving the implementation some effort.
   However, Bert and I don't think anyone is going to bother using
   this keyword, and it complicates the syntax.


Make default 'box-shadow' offsets non-zero.
   http://www.w3.org/Style/CSS/Tracker/issues/40 ISSUE-40

   Reject. There are good use cases for zero offsets, it's an obvious
   default, and it matches 'text-shadow'.


Make 'box-shadow' offsets optional.
   http://www.w3.org/Style/CSS/Tracker/issues/40 ISSUE-40

   Reject. It makes the syntax very confusing once a 'spread' value
   is added, since one length would mean a blur radius only whereas
   two lengths are always interpreted as offsets.


Scale background image relative to its own size
   http://www.w3.org/Style/CSS/Tracker/issues/19 ISSUE-19

   Reject. We didn't come up with any convincing use cases for this


Issues to Close With Changes

Define where background colors are clipped and how this is controlled.
   http://www.w3.org/Style/CSS/Tracker/issues/15 ISSUE-15

   Resolve: Background colors are clipped to the same rectangle as the
   bottommost image.


Positioning of a single tile when 'background-repeat: space'.
   http://www.w3.org/Style/CSS/Tracker/issues/8 ISSUE-8

   Resolve: If only only one tile fits, it is positioned according to


Make non-fallback background color optional.

   Resolve: Accept: 'background-color: / white' should be equivalent to
   'background-color: transparent / white'. Transparent is the most
   common case here, and making the keyword optional saves some typing,
   and avoids typos. (It looks more reasonable in the shorthand:
   'background: url(semitransparent.png) / white'.)


'bounding-box' and 'continuous' should affect blocks differently in multi-col
   http://www.w3.org/Style/CSS/Tracker/issues/43 ISSUE-43

   Resolve: Fix 'bounding-box' definition for block to match the
   definition for inlines.


vertical major writing direction should attach broken backgrounds side-to-side
   http://www.w3.org/Style/CSS/Tracker/issues/47 ISSUE-47

   Resolve: When 'background-break' is 'bounding-box' or 'continuous'
   broken boxes are attached in the direction of the block progression
   of the root element (for page breaking) or nearest ancestor
   multi-column element (for column breaking).


Define behavior of backgrounds when broken across varying page widths.
   http://www.w3.org/Style/CSS/Tracker/issues/22 ISSUE-22

   Resolve: When 'background-break' is 'continuous', each piece draws
   its background honoring its y-position within the chain, but assuming
   that the whole element has the same width as this piece. This ensures
   right-aligned images stay right-aligned, left-aligned images stay
   left-aligned, and centered images stay centered. When
   'background-break' is 'bounding-box', align all boxes by their start
   border edge before drawing the bounding box.


Define what happens when border radii intersect.
   http://www.w3.org/Style/CSS/Tracker/issues/29 ISSUE-29

   Resolve: Reduce all radii in proportion until no radii intersect.
   This avoids sharp points in the borders while preserving the shape
   of the box.


Proposal for 'no-clip' value for 'background-clip'.
   http://www.w3.org/Style/CSS/Tracker/issues/16 ISSUE-16

   Resolve: Add 'no-clip' value to 'background-clip', mark "at risk".


Simplify 'background' shorthand by combining clip and origin.
   http://www.w3.org/Style/CSS/Tracker/issues/24 ISSUE-24

   Resolve: Allow the 'background' shorthand to take the values for
   'background-origin'. Also allow it to take a 'no-clip' keyword,
   which sets 'background-clip' to 'no-clip'. If 'no-clip' is not
   present but one of the 'background-origin' keywords are, set
   'background-clip' to the same value.


'bg-clip' and 'bg-origin' values should match 'box-sizing' keywords.
   http://www.w3.org/Style/CSS/Tracker/issues/42 ISSUE-42

   Resolve: Accept: change 'border' to 'border-box', 'padding' to
   'padding-box', and 'content' to 'content-box'.


Add "spread" value to 'box-shadow'.
   http://www.w3.org/Style/CSS/Tracker/issues/41 ISSUE-41

   Resolve: Add "spread" as optional fourth length value after "blur".


Box shadow grammar errors and suggestions.
   http://www.w3.org/Style/CSS/Tracker/issues/40 ISSUE-40

   Resolve: Fix grammar errors to match 'text-shadow'.


Define whether box-shadows are drawn inside the element.
   http://www.w3.org/Style/CSS/Tracker/issues/32 ISSUE-32

   Resolve: Box-shadows are only drawn outside the element's border-box.


Add 'contain' and 'cover' as keywords for 'background-size'.
   http://www.w3.org/Style/CSS/Tracker/issues/45 ISSUE-45

   Resolve: Accept.


Rename 'background-origin' to 'background-box'
   http://www.w3.org/Style/CSS/Tracker/issues/46 ISSUE-46

   Resolve: Bert and I tentatively accept this suggestion, but are open
   to better names.


Issues For WG Discussion

Positioning from corners other than top left:
   http://www.w3.org/Style/CSS/Tracker/issues/10 ISSUE-10
   http://www.w3.org/Style/CSS/Tracker/issues/11 ISSUE-11

   Positioning fixed distances from the bottom/right edges is a common
   request. Note that it can be done with calc() by subtracting from
   100%, so the question becomes whether an alternative syntax is wanted
   for usability.

   Positioning from the start/end edges can't be done with calc().

Multiple borders:
   http://www.w3.org/Style/CSS/Tracker/issues/25 ISSUE-25

   Bert and I are happy to leave this to XBL, but wanted to check that
   implementors agree.

Percentage border widths:
   http://www.w3.org/Style/CSS/Tracker/issues/26 ISSUE-26

   Margins and padding already allow percentages. On the other hand,
   there would be problems with losing a border due to auto-width
   calculations that result in the percentage defaulting to zero.

Percentage border radii:
   http://www.w3.org/Style/CSS/Tracker/issues/30 ISSUE-30

   A possible snag is whether percentages are relative to a radius's
   corresponding dimension or if they are relative to the shortest
   dimension or something else.

Inner Box Shadow:
   http://www.w3.org/Style/CSS/Tracker/issues/44 ISSUE-44

   There have been quite a few comments about adding such a feature,
   or at least an "inner glow" feature (which this would address).
Received on Wednesday, 14 May 2008 06:29:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:06 GMT