• 201012 May

    A recent editors draft of the CSS3 Background and Borders module (published on 5th may) indicates that the box-shadow property could be set to make a reappearance before the specification is released as a Proposed Recommendation.

    The specification also features several other updates including the addition of a ‘content-box’ value to the background-clip property, changes to the background shorthand syntax for background-clip and background-origin, and the removal of a recommendation to use gradients for color transitions when border-radius produces a curve, further details below.

    Last week also saw the release of an updated working draft of the CSS3 Template Layout module, read on for further details.

    Box-Shadow

    The box-shadow property, which allows for the creation of drop shadows on box elements, was removed from the Backgrounds and Borders specification prior to it entering the Candidate Recommendation phase of development last December, as the working group felt that the property needed more work, however the property makes a reappearance in a recent editors draft of the specification (published on 5th May).

    The overall syntax and functionality remains the same as in previous versions, however the specification now offers further clarification with regard to the blur radius and spread radius functionality as follows.

    Blur Radius

    Previous specification:

    “The third length is a blur radius. Negative values are not allowed. If it is 0, the shadow is sharp, otherwise the larger the value, the more the shadow is blurred. The exact algorithm is not specified.”

    Editors draft (5th May):

    “The blur radius is perpendicular to and centered on the shadow’s edge and defines a gradient color transition from the full shadow color at the radius endpoint inside the shadow to fully transparent at the endpoint outside it: if the blur radius is 0, the shadow’s edge is sharp, otherwise the larger the value, the more the shadow is blurred. The exact algorith for the blur transition is not specified.”

    Spread Radius

    Previous specification:

    “Positive values cause the shadow to grow in all directions by the specified radius. Negative values cause the shadow to shrink. The shadow should not change shape when a spread radius is applied: sharp corners should remain sharp.”

    Editors draft (5th May):

    “Positive values cause the shadow shape to exapand in all directions by the specified radius. Negative values cause the shadow shape to contract. For corners with a zero border-radius, the corner remains sharp. Otherwise the spread radius outsets the edge of the shadow by the amount of the spread radius in the direction perpendicular to the shadow’s edge. (Note that for inner shadows, expanding the shadow means shrinking the shadow’s perimeter.) The UA may approximate the spread shape by outsetting (insetting, for inner shadows) the shadow’s straight edges by the spread radius and increasing (decreasing, for inner shadows) and flooring at zero the corner radii by the same amount. If both a blur radius and a spread radius are defined, the blur is applied to the resulting shape after the spread is applied.”

    Interactions

    The updated specification also offers further definition as to how the box-shadow property interacts with other backgrounds and borders properties, particularly in relation to the border-image property, with the updated specification stating clearly that the border-image property has no effect on the shape of box shadows.

    The specification also further clarifies how the box-shadow property interacts with tables and pseudo-elements:

    “The ‘box-shadow’ property applies to the ‘::first-letter’ pseudo-element, but not the ‘::first-line’ pseudo-element. Outer shadows have no effect on internal table elements in the collapsing border model. If a shadow is defined for single border edge in the collapsing border model that has multiple border thicknesses (e.g. an outer shadow on a table where one row has thicker borders than the others, or an inner shadow on a rowspanning table cell that adjoins cells with different border thicknesses), the exact position and rendering of its shadows are undefined.”

    Box-Shadow Examples

    The draft also includes a number of examples (see the diagram below) as to how the property should behave in certain circumstances:

    Box-Shadow Examples, W3C

    Box-Shadow Examples, W3C

    Additional Updates to CSS3 Backgrounds and Borders

    In addition to the reinclusion of the box-shadow property, the specification introduces a ‘content-box’ value to the background-clip property allowing the background to be clipped to the content box (previously border box and padding box were the only clipping options), a change to the background shorthand syntax in relation to background-clip and background-origin, the removal of the recommendation to use gradients for color transitions  when border-radius produces a curve, and various other clarifications.

    You can view the editors draft here.

    New Working Draft of CSS3 Template Layout Module Released

    Last week also saw the release of an updated working draft specification of the CSS3 Template Layout module. The updated release contains a small number of minor updates, but according to the working group minutes was published more to “show it is still active.” The updated draft can be viewed here and I’ll provide further details when I’ve had a chance to take a closer look it.

    You can skip to the end and leave a response.


  • Comments

    • 01.

      Glad to see this stuff moving forward. Box-Shadow and Border-Radius are going to be big time savers when designing a site. The additional example should help browser makers also figure out what to do in the case when both are used together. At the moment, Webkit screws this up pretty good >> http://goo.gl/0eu3 

    • 02.

      Why did the W3C in their infinite combined wisdom decide that in order to have rounded corners on a container, that container had to have a border with a width greater than 0. Infuriatingly stupid. Like nobody in the history of the internet will ever want a background image in a container with rounded corners that DOESN’T have a border.

    • 03.

      I completely agree with Jeffrey Gilbert, and I’m glad all the current implementations don’t respect the “If either length is zero, the corner is square, not rounded” clause. This needs to change.

      Also, I’d like to see the outline respect border-radius. -moz-outline-radius was a good try, but having the outline and border follow separate radii is cumbersome.

    • 04.

       Agreed on both of the above points: (1) I’m VERY glad to see progress, and (2) At the same time, rounded corners ≠ borders with a width!

      Is there a place where We The People™ who are eagerly watching CSS3′s development can voice our objections to the the appropriate Working Group?

    • 05.

      “Why did the W3C in their infinite combined wisdom decide that in order to have rounded corners on a container, that container had to have a border with a width greater than 0. Infuriatingly stupid.”

      As far as I understand it, the spec does allow for rounded borders on boxes without borders, as do all the major browsers currently, example:

      http://www.css3.info/demos/1.html

      “I completely agree with Jeffrey Gilbert, and I’m glad all the current implementations don’t respect the ‘If either length is zero, the corner is square, not rounded’ clause.”

      This clause in the spec relates to the border-radius values, not the border-width values.

    • 06.

      There is nothing in the draft that says in order to have rounded corners you must also have a border. That would be silly, and I really don’t see how anyone could possibly interpret the language of the draft that way, unless you are intentionally trying to get it wrong in order to goad others.

      The widths in the passage you quoted refer to the radius lengths of the ellipse (one horizontal, one vertical, or just write one length for a perfect quarter circle). An ellipse described with large radius lengths create large rounding of the corners, small radii create small rounding of the corners, and zero lengths create no rounding (sharp corners). It is very clearly worded in that regard. Border width is not mentioned at all there.

    • 07.

       ”Is there a place where We The People™ who are eagerly watching CSS3’s development can voice our objections to the the appropriate Working Group?”

      Absolutely. There is a public mailing list for discussing the CSS specifications: “[email protected]”. It is mentioned, along with a link on how to join, in the first few paragraphs of that editors draft you wish to object to (here: ).

    • 08.

       The comment system ate the URL. Here:

      http://dev.w3.org/csswg/css3-background

    • 09.

      Best Reference CSS Same place

    • 10.

       “Why did the W3C in their infinite combined wisdom decide that in order to have rounded corners on a container, that container had to have a border with a width greater than 0. Infuriatingly stupid.”

      I believe this to be incorrect as has been mentioned here, the spec details the border radius property but does not expect elements this applies to, to have a border defined. Images for example can be rounded in many browser implementations without borders.
      The term probably is just to avoid calling it ’roundedness’ like in fireworks for example!

    • 11.

       Played with them layout.
      and find out that the ‘inset’ is a very nice addition to box-shadow.

      I am able to get rid of images.. so nice shadows

    • 12.
    • 13.

      I think it makes more sense if that box-shadow was more like a gradient … between 2 colors specified or one and transparency.

    • 14.

       @Ahmad, but it is. SelectedColor–Transparency gradient. Because that’s what the shadow is. If you want a background gradient there’s a -moz-transform for that. And the thing I would like to see is a border which can be a gradient. That would be awesome.

    • 15.

       >> and I really don’t see how anyone could possibly interpret the language of the draft that way

      To be honest, checking the updates against previous versions, they became completely unreadable to me. The former definitions were clear, understandable and concise, I didn’t even try to finish the new definitions.

      I’m sure these new definitions are more complete and somewhat useful to implementors, but completely obsolete for most front-end developers.

    • 16.

      @Neils So the exact changes are here: http://dev.w3.org/cvsweb/csswg/css3-background/Overview.src.html.diff?r1=1.224&r2=1.225&f=h The text that was there before hasn’t changed, it’s just been expanded. Do you have any specific suggestions for making it easier to understand?

    • 17.

      I think we need big campaign for deny Internet Explorer because it make limit for web designers progress

    • 18.

      I just tried out box-shadow property on a live site. It works nice. However, the term box shadow is somewhat misleading.

      In order to have a very soft ‘shadow’ over a bright background, it is required that the color value is high (towards the #ffffff).

      I have this applied on rotating background images. When the background image is bright, the ‘shadow’ appears fine. But when the background is dark, the ‘shadow’ is actually a glow. This isn’t normal behavior for a shadow and in this particular case, is undesirable.

      An opacity parameter would make this much more flexible, but the term ‘shadow’ would still not be precise. Then again, box-glow wouldn’t be any better.

    • 19.

      Primat: use rgba() to set the colour of the shadow, that’ll give you control over the opacity.

    • 20.

      I think what Primat is asking for is a way to have box-shadows use a blending model that actually approximates shadows so that they are _always_ darker than the background, i.e. using lerp(a, shadowcolour*backgroundcolour, backgroundcolour) instead of lerp(a, shadowcolour, backgroundcolour).

      Personally, I’m ok with the way blending works now (it’s good enough for most situations) but what I’d really like is to be able to specify a purely-vertical or purely-horizontal blur and spread.

    • 21.

      box-shadow:
      0 0 0 10px rgba(255,0,0,0.5)
      ,
      0 0 0 20px rgba(0,255,0,0.5)
      ;

      inner shadow (red) is mixed with the outer shadow color (green)

      so my red is now a “yellow”

      i think box shadow should provide a way to set the “blending mode” of the shadows

      box-shadow-blending:true || false

      or something

    • 22.

      Martin Hintzmann has a useful solution for box shadows in Internet Explorer here:
      http://www.hintzmann.dk/testcenter/js/jquery/boxshadow/

      I modified the script to accept an alpha value as well – here:
      http://www.yapura.co.uk/dev/jquery.boxshadow.alpha.js

    • 23.

      I really love how it gives me the posibility to create nice and cute border and shadow without any desgined img, i’m really thank to this new property, thx 

    • 24.

      Curious, just mucking around with this. I notice that box-shadow inset only works correctly when a border is applied if a border-radius is used. Does not create the proper inset shadow. I wonder if this is something that they may change???

    • 25.

       Just been mucking around with this as well, the shadow’s are showing up in safari, but not firefox, any idea’s why?

    • 26.

      Muchos Gracias for your blog.Much thanks again. Much obliged.

    • 27.

       nice effects thanks for posting

Hosting by: