Bugzilla – Bug 16316
Resolved value for "width" underspecified when box-sizing: border-box
Last modified: 2013-08-08 13:26:50 UTC
Resolved value doesn't really account for what should happen when you try to get the "width" value of an element that has box-sizing: border-box using getComputedStyle.
The question of what should happen had been discussed with the previous editor: http://lists.w3.org/Archives/Public/www-style/2011Jun/0420.html
However, I believe the correct behavior is that getComputedStyle should return the round-trippable value for width and should be special cased. Currently, Webkit and Internet Explorer return the round trippable value, while Firefox returns the used value.
When the value is not round-trippable, people view it as a bug, as is evidenced by this bug report in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=520992
Furthermore, without the round-trippable value, you are forced to augment it by the border-width and padding values in order to get the correct round-trippable value. It has surfaced as a hurdle to completing this ticket and making border box save to use in jQuery as well: http://bugs.jquery.com/ticket/11004 .
Also, Mozilla has stated they aren't prepared to drop the box-sizing prefix until they do the same in regards to getComputedStyle the same as Webkit and IE. Having the spec. specify what to do will help move this along.
The previous editor believed that special-casing this wasn't worth the effort, but it appears that special casing is already the behavior in all major browsers besides for Firefox.
Here's the discussion about it on www-style: http://lists.w3.org/Archives/Public/www-style/2012Mar/0325.html
There are a few solutions here:
1. special-case the resolved value of width to include text about box-sizing
2. add language to resolved value about the round-trippable nature of resolved value, as called out in Tab's response, which is basically something like "the used value of a css property should remain unchanged if the value is set to the resolved value of the property". Of course, that's just a suggestion.
I think #2 is a better solution, as it future proofs against other special cases where the semantic value of a property changes based on a different property's value.