The age-old problem of having to use the conventional Level 2.1 box model in conjunction with padding and/or border values is solved using CSS3. Up until now, this problem was a major stumbling block for developers, particularly in the instance of specifying a border/padding value in relation to a fluid length element, but the new ‘box-sizing’ property answers this problem.
Firstly though, I’m going to quickly skim over an alternative to this box model addition which comes in the form of the ‘calc()’ function. Unlike the new (although the same model is implemented in versions of IE up to 6) box sizing concept where it’s the user agent’s responsibility to calculate any border and padding value (minimizing input from the author) , ‘calc()’ requires the author to hard-code any border or padding values directly into the function itself. I also feel the ‘calc()’ function is overly complex (complicated syntax (multiple arithmetic operators etc)) for the purpose this article looks at, and for that reason I’ll be focusing my attention on ‘box-sizing’.
CSS3 introduces the Basic UI module (currently a CR) – ‘box-sizing’ property is a proposal that brings with it the opportunity for the user to choose between several box models.
There are currently two values in the official spec- ‘content-box’ and ‘border-box’:-
- ‘content-box’ – “This is the behavior of width and height as specified by CSS2.1. The specified width and height (and respective min/max properties) apply to the width and height respectively of the content box of the element. The padding and border of the element are laid out and drawn outside the specified width and height.”
- ‘border-box’ – “The specified width and height (and respective min/max properties) on this element determine the border box of the element. That is, any padding or border specified on the element is laid out and drawn inside this specified width and height. The content width and height are calculated by subtracting the border and padding widths of the respective sides from the specified ‘width’ and ‘height’ properties.”
The Mozilla team have implemented the proprietary ‘padding-box’ value, where the width and height of the box includes any padding value but not a border value.
Current Support
- Opera 8.5+ : ‘
box-sizing‘
- Firefox 1+ : ‘
-moz-box-sizing;’
- Safari 3 : ‘
-webkit-box-sizing‘
- IE8 : ‘
box-sizing‘
Commenting on in which I call for Webkit to drop it’s prefix for this property, that the team did in fact remove the need for the ‘-webkit prefix for a while but they apparently broke on some prominent websites, which he puts the reason down to site authors targeting specifically Mac IE (which implemented the property without the need for a prefix – nice work Tantek); I’m still unclear as to how this would affect any current or future implementation from any vendor, let alone Apple, as Opera have managed it fine. After an email asking for some clarification, Dave informed me that they shipped the initial version of the phone browser without the prefix, but had to revert due to the breakage issues; he doesn’t mention however when we can expect the ‘-webkit‘ prefix to be dropped.
Properties the ‘box-sizing’ concept can be applied to
heightwidthmin-widthmax-widthmin-heightmax-height
Keyword values that the ‘box-sizing’ concept can’t be applied to
These include some proposed keyword values.
autonone (max-width/max-height only)fit-content (proposal)min-content (proposal)max-content (proposal)
Related Module Implementation
The Values and Units Level 3 module has been a WD since Sep ‘07, whilst Basic UI has been a CR since May 04. With that in mind you could argue that Basic UI is a fairly mature module however, at time of writing it has no official owner which one could deem a reason why progress has been slow. Not surprisingly then does the spec look fairly unpolished; the W3C have placed a CR exit criteria on the module requiring two or more interoperable implementations to be found for each feature. Similarly there are multiple features that are at risk from being removed from the module- the same criteria applies but with the addition that ‘at-risk’ feature implementations need to be found by the end of the CR period. However, the fundamental issue that is holding progress up is that, as of yet, a test suite doesn’t exist – without a suitable test suite in place, we can’t prove to the WG that implementations exist, which means the module won’t move out of CR. For the time being, it looks to me that the CR period will be extended indefinitely until ownership of the module is sorted out and an adequate test suite is implemented.
It would be great for a vendor such as Opera (who is already supporting part of the module) to create their own test suite for inclusion in an official W3C version, much like the way the IE guys have recently proposed – this would help speed up the process of taking the module out of CR.
Where to go from here?
Recently I’ve been exchanging emails with fantasai regarding the ongoing status of Basic UI; we’re both in agreement that the concept of providing an alternative box model to developers is likely to become an integral solution looking forward, because as mentioned before, this additional box model specificity overcomes the ‘flaws’ of the current Level 2.1 version. However, unlike various ‘typographical’ CSS3 features in other modules which can be used in a progressive enhancement context, ‘box-sizing’ is of course a fundamental layout property thus, making it currently unsuitable to implement from a cross-browser point of view. However, fantasai has elaborated on the current spec and proposed a solution that solves the cascading issue that exists with both ‘box-sizing’ and ‘calc()’ – my feedback on her proposal. Her solution involves adding optional ‘content-box’ and ‘border-box’ keyword values to width and/or height declarations. Her solution was discussed at the recent (March 08) WG F2F in San Diego and members were strongly in favour – only 1/2 of one company’s representation was opposed. It was noted in the April ‘08 CSSWG minutes that her proposal should be adopted; I have however, given my own feedback opposing this move.
Conclusion
Moving forward, it is critical that we find a new owner for Basic UI (that’s if Tantek doesn’t want to be reinstated). Also, I feel we should take heed to fantasai’s concept and I would urge developers to come forward and critique it on www-style, so that one day either fantasai’s proposal or a similar solution can be adopted. As I’ve mentioned before, a sufficient test suite needs to be produced (either by a vendor and incorporated into an official version, or by the W3C directly), so that the WG can be provided with evidence of interoperable implementations. This means we could hopefully see the module featured in the ‘08 Snapshot, and wider browser support should follow, with or without vendor-specific prefixes.