W3C home > Mailing lists > Public > www-style@w3.org > September 2007

[CSSWG] Resolutions Beijing F2F 2007-09-10 Afternoon

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 13 Sep 2007 03:50:02 -0400
Message-ID: <46E8EBAA.6020407@inkedblade.net>
To: www-style@w3.org

Major topics for Monday morning included:
   CSS3 Borders
   CSS validator

border-radius Shorthand Syntax
------------------------------

   RESOLVED That the 'border-radius' shorthand shall take 1-4 values
           that set the four corners to circular radii as in the
           -moz-border-radius shorthand. That is,
             border-radius: ALL;
             border-radius: TL TR BR BL
             border-radius: TL+BR TR+BL
             border-radius: TL BL+TR BR
           Basically the syntax is TL TR BR BL (clockwise from top-left)
           and missing values are filled in by repeating the pattern,
           just as with 'border-style' et al.

   RATIONALE The WG concludes from comments such as those at
               http://www.css3.info/border-radius-apple-vs-mozilla/
           and from evaluating commonly-used effects that designers are
           more likely to set different circular rounding effects on each
           corner than they are to set a common elliptical effect on all
           four corners. Therefore the border-radius shorthand should
           cater foremost to this usage.

   SEE      http://csswg.inkedblade.net/spec/css3-background#issue-4

   Although we did discuss it, there is no resolution on an extended
   shorthand syntax for setting elliptical curves. (The WG is generally
   hesitant to add more punctuation to values without very strong
   rationale, and also there was no clear agreement on what punctuation
   should be used.)

Overlapping Radii
-----------------

   RESOLVED We agreed that we do not want to have pointy borders, but
            we have not yet resolved how to acheive that.

   RATIONALE Web designer feedback.

   COMMENTS There are many ways of eliminating a pointy intersection.
            Based on Brad Kemper's feedback, the best way would be to
            reduce the affected corners' x and y radii in proportion,
            as this will preserve the shape of the curve. We still
            need to investigate the exact formulation for this solution,
            particularly how multiple overlapping corners interact.

   SEE      http://csswg.inkedblade.net/spec/css3-background#issue-5


Inner Border Radius
-------------------

   RESOLVED The inner border radius is the outer border radius minus the
            border thickness. In the case where this results in a negative
            value, the inner radius is zero and in this case its center may
            not coincide with that of the outer border curve.

Color and Style Transitions
---------------------------

   RESOLVED The center of color and style transitions are at an angle that
            is proportional to the ratio of the border widths. E.g. if the
            two widths are equal, the angle is 45deg, and if one is twice
            the width of the other the angle is 30deg. The line demarcating
            this transition is drawn between the point at that angle on the
            outer curve and the point at that angel on the inner curve.
   There is no resolution on what the transition looks like.

We also discussed whether content should be fitted to the curve, and
concluded that if the curve of the content edge needs to be known, it
should follow the same principle we established for the inner and outer
border edges. However it seems we don't really want content to fit to the
curve as that makes border-radius affect layout and will thus prevent us
from extending border-radius to take percentages in the future. Therefore
some other mechanism for changing the containing block shape would probably
be better.


CSS Validator
-------------

   RESOLVED: Validator should emit warnings, not errors, for profile mismatches.

   RESOLVED (again): The default for validation should be all the properties
             that are in a draft the WG considers stable. Users may ask for
             a specific profile to be used instead.

   RESOLVED: The validator should not offer a CSS2 profile. Features in CSS2
             that are not in CSS2.1 can be validated against the default
             profile, just as if they were in a CR-level draft.

   RESOLVED: The validator should no longer offer a CSS1 profile.

~fantasai
Received on Thursday, 13 September 2007 07:50:23 GMT

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