The setting of box-sizing to border-box for all elements rather than the default content-box (as used for twentyten, twentyeleven, and twentytwelve themes) will break the styling of many plugins for Firefox.

Strange that this is only done for firefox and the default setting of content-box is used for other browsers.

Suggest this css property be only used only the elements that need it in conjunction with the CSS3 box-sizing property and other browser equivalents.

Andy Bruin

Oldest firstNewest firstThreaded

Comments only

Change History (39)

Found /wp-content/themes/twentythirteen/style.css entry is actually as follows (Firebug strips all but -moz-box-sizing) so disregard the line "Strange that this is only done for firefox and the default setting of content-box is used for other browsers."

Recognizing that other themes might start using this alternate box model, following Twenty Thirteen's lead or of their own accord, I've already started explicitly defining box-sizing for my plugins' elements.

The trouble with using an alternate box model and the way themes/plugins interact is tricky. It seems unrealistic to have themes only apply border-box to the elements they need it on, because plugin elements could become nested in theme html in a lot of places, so you'd need to avoid universal selectors entirely and basically add a class to every element that needs this (which would make development messy). It's far more realistic to have plugins explicitly declare box-sizing: content-box; for all of their elements; for example:

Thus overriding border-box for plugin elements in case the theme has declared it. PLugins could similarly use border-box if desired. Obviously this means a lot of plugins need updating, but it would be the forward-compatible thing to do for broader theme compatibility, and having it in Twenty Thirteen will make people fix their plugins faster. It'd be cool to tell plugin authors about this ASAP, though, since the issue isn't confined to Twenty Thirteen. And there should be a note in the codex or somewhere about checking this when looking at theme compatibility for plugins that add code to the frontend.

Your fix is exactly what I did. However with the resultant mix of content and border-box in themes (which would happen as you predict with twenty thirteen being left as it) you pretty much have to define each plugin's elements which means theming goes out the door or you have to define elements for both possibilities and use javascript (or maybe some weirdo css???) to switch. It will result in a mess.

I was wondering how this came about. It seems this was an attempt to consolidate the box-sizing of various elements where using box-sizing made sense. Unfortunately this simplification attempt lost sight of the greater picture by applying this change to everything.

I've noticed before parts of WordPress in particular the admin pages use the box-sizing CSS property set to border-box on various elements. However it isn't used overall by utilizing the universal selector which this change implemented.

'border-box' is probably about the only thing that the earlier versions of Internet Explorer got right as it is more intuitive than content-box sizing. If this was the first version of WordPress I be all for it. Unfortunately WordPress is used by many these days and this change would wreck havoc with plugin developers who will have to write css and javascript to cope with both box-sizing methodologies.

I'm not sure if to append this matter to the earlier ticket or to leave it as a separate ticket. However your contribution makes it easy to backtrack on the earlier change as we now have a reference point.

Other themes (public, custom, etc.) are likely setting it on all elements, so Twenty Thirteen might as well do so also; plugin authors are more likely to discover and address this situation moving forward after finding compatibility issues with the default theme.

Notes

Extract from Mozilla's page

The box-sizing CSS property is used to alter the default CSS box model used to calculate widths and heights of elements. It is possible to use this property to emulate the behavior of browsers that do not correctly support the CSS box model specification.

I agree with having box-sizing set to border-box for the input types checkbox and radio as it is actually the default for all browsers except IE8/9 and this makes it consistent.

I completely disagree with applying box-sizing to any of the .sidebar elements as given they don't exist this could create a black hole which may destroy the fabric of the virtual universe ;). Of course they may exist in another universe or exist in this universe under an pseudonym which I need to be enlightened on.

The 'field' class sub selector for the 'searchform' selector no longer exists in twenty thirteen. It did exist in twenty eleven and applied to the searchform input text field. The setting of boxing-sizing to border-box for this text field is a change from past themes that could cause problems for some like me who like to style this in their own widgets. Strangely enough setting box-sizing to border-box for this will probably fix more problems than it causes. Hence I might be just able to be able to live with this. Comments anyone?

Except for ".site-footer .widget" there shouldn't be any problems with the box-sizing being set to border-box for these elements.

The setting of boxing-sizing to border-box for widgets via ".site-footer .widget" is a change from past themes that could cause problems. However I think maybe it could be a good thing as it makes widgets play nice with the footer area and perhaps it needs to to be applied in the 2013 sidebar as well. Thoughts on this anyone?

Slight correction to above. Just noticed in revision 23520 the definition for ".searchform .field" had already been replaced by the following. Therefore my comments on the searchform field selector should apply to this selector instead.

If it is decided to remove border-box box-sizing for this element this definition will have to be restored for browser consistency. Alternatively if the universal selector is removed and it is decided to keep the ticket 23679 fix then border-box sizing will have to be applied to this element.

I have been enlightened! It seems that the universe has conspired to make it's body a sidebar!

On a more serious note the class "sidebar" is added to the body tag to indicate that the page has a sidebar and is set by the function twentythirteen_body_class() in the twentythirteen functions.php file. Unfortunately it's naming makes the CSS rather confusing to read. For example the CSS definition .sidebar .entry-content refers to the content in the main area and not to anything in the sidebar itself.

I'm now testing my beta version of WordPress 3.6 with the universal selector removed and the old box-sizing CSS restored. So far with the change below it seems fine on Firefox and IE8

Besides the '.site-header .home-link' border-box addition mentioned above I have also discovered that a '#content .entry-media' entry needs to be added to the '@media (max-width: 643px)' entries above to prevent scroll bars on Firefox appearing when the sidebar is used. This may need to be updated elsewhere as well.

Note that @media queries do not work on IE8 or older.

Also the sidebar looks terrible, regardless of whether these changes are applied or not, as the content headers and background colors (various post formats) overflow under the somewhat transparent sidebar. Suggest margins be used instead of the padding presently used for this as since the sidebar is floated right this fixes the overflow . I realize this needs a separate ticket but it will impact on the work here. Note that margins are not included in the box model.

This is complicated. :) There's not going to be an easy, or right, answer. We need to decide based on both pragmatic (simpler CSS rules) versus philosophical (universal selectors for something like this means we think *everyone* should use this box model).

I'm leaning towards keeping the universal selector, and taking the chance to educate plugin authors on how to use modern CSS box model(s) -- starting a dialogue to help us all learn better CSS practices. Yes, it could break some things visually, but users won't lose any content, so the severity is minimal.

I did reply comprehensively last week but it seems my reply disappeared into the ether. So here goes again.

Simplifying or making the CSS look tidier is not a good enough reason for this change. Obenland's earlier suggestion of using a block definition for border box sizing is one way of making it tidier though I prefer leaving it with the elements for clarity.

As a plugin author box models are the bane of our existence and having to support both content and border box models for all themes by using javascript or weird CSS plus write CSS for both cases would definitively break the camel's back. As I have mentioned before I would definitely be for the border box model if this was the first release of WordPress but requiring plugin authors to support both models by using border-box sizing for this theme is badly thought out.

The statement 'Yes, it could break some things visually, but users won't lose any content, so the severity is minimal' is incorrect. If any containing elements have the overflow property set to hidden the results could be catastrophic.

I said 'many' as it will affect plugins that define any display elements that use the padding or border property combined with a width property (width, min-width, max-width). If a plugin has a widget, or alters content, that includes such display elements it will be affected although not necessarily in a bad way. At the worst content could go missing as mentioned in my last post.

As to debugging this is a hard one to spot because it took me a day to realize that the standard content-box sizing was being overridden by an universal selector and hence this ticket.

No theme I have come across uses the universal selector to set box-sizing to border-box (and I'm always cross checking problems with themes and WPUF). Can you name one?

As to fixing the problems with having to support both box sizing models it really depends on what your plugin is doing.

If it's just adding a box to content given a certain pre-existing width then you will have to define the box model. Unfortunately you will have to use javascript to get the real width as there is no way I know of to ascertain in CSS which box model is in operation.

If your modifying pre-existing content then it's a different ball game. You will have use javascript to assert the box model and act accordingly.

Unfortunately the [class*="your-plugin-prefix-"] selector has a big problem in that box-sizing isn't inherited so any child of that selector will revert to the universal box-sizing.

Seriously though wouldn't the solution be to define content-box sizing for the widget and entry-content classes using the selectors I gave two posts back? That would mean that plugins both past and future would be compatible with this theme.

The only other thing I see that needs to be done for widgets is to adjust the searchform input fields. For searchform input fields border-box is the easiest to deal with so it's best to set it to border-box.

If you want to this this in action check it out here ​http://test4.2rrr.org.au/?preview=1&template=twentythirteenzebra&stylesheet=twentythirteenzebra . Note this is my new variant (codenamed Zebra) of Twenty Thirteen that has working sidebars and includes many fixes. It works superbly on the latest versions of Firefox, Chrome, and Safari, has no problems with IE7 and IE8, and looks great on the IPhone 4. I only have to update the RTL CSS, fix the dropdown menu (it looks terrible), and test a few minor bits and pieces and it will be complete. Once this is done I will start putting the 2013 fixes on Trac. I will post the source link soon once I have tidied a few things up.

I've added some box-sizing notes below that may be good to put in the stylesheet (or something similar) as it would save a lot of people a lot of time and trouble and reduce chatter in the forum.

/*
* Box-sizing notes
* ----------------
*
* A few notes about box-sizing that need to be considered when altering this
* stylesheet.
*
* The latest versions of Firefox, Safari, Chrome, and Internet Explorer all work
* fine with border-box sizing. IE7 and IE8 have problems which makes changing anything
* in the CSS a pain.
*
* The key is to avoid if possible having elements with padding or borders combined
* with a width property (width, min-width, max-width). These elements are subject to
* box-sizing. You can use DIV containers to do this.
*
* IE7's quirks mode is border-box though it's standard mode is content-box.
* Unfortunately it doesn't implement the box-sizing property so we have to amend the
* css/ie.css IE stylesheet to define content-box settings for any affected selectors.
*
* IE8 does implement the box-sizing CSS property but has bugs. In particular min-width
* and max-width are always interpreted as content-box widths.
*
* Keep in mind that any change in the CSS should be reflected in the rtl.css RTL
* stylesheet.
*/

PS. If you take a look at the demo please excuse the mad ramblings of a WordPress plugin author as he talks a walk on the wild side with a Zebra he met in his test blog :)

I also have two themes using it. I've never heard any complaints about it. And I haven't yet seen an example of a plugin breaking. Do you have one?

Unfortunately the [class*="your-plugin-prefix-"] selector has a big problem in that box-sizing isn't inherited so any child of that selector will revert to the universal box-sizing.

[class*="your-plugin-prefix-"] *?

It might be because I don't have a plugin that adds any frontend styling but I don't see why you would have to use Javascript. Plugins like WooCommerce are using box-sizing: border-box in their CSS.

Seriously though wouldn't the solution be to define content-box sizing for the widget and entry-content classes using the selectors I gave two posts back? That would mean that plugins both past and future would be compatible with this theme.

If Twenty Thirteen were to do this I agree your solution seems to be the best. But in my opinion this problem should be fixed on the plugin side.

These are just 4 themes of the 1795 themes available on the WordPress themes page. Though there may be more themes that use the universal selector its a very small minority and certainly not a good enough reason for this change.

Of the themes you have given Montezuma is definitely worth a look as it has 170,000 downloads since first appearing last November (it presents images nicely). I looked on the forums including the author's own forum and a few problems with plugins are mentioned that may be caused by this or otherwise but there are always clashes between themes and plugins so I wouldn't past judgement either way.

In any case problems with plugin layout always get reported to the plugin author (as I can attest) and rarely to the theme developer so such problems will not be immediately apparent on the theme's support forum.

As to clashes with themes most plugin author's tend to ignore them unless the theme is popular and the issue regularly gets reported.

It's obvious that changing the box-sizing universally from the standard default content-box would change the layout of elements affected in the content or the plugin widget. Whether or not this causes a problem or not is another matter but if the plugin is relying on the standard model defaults it could be a big deal or even catastrophic as my example a few posts back shows.

Suggesting that all plugin authors have to upgrade their plugins to support a non default box model is silly. We have standards so everybody can get along famously and reduce the workload of handling infinite possibilities. I remember the bad days of the internet where we had to cope with both IE's non-standard model and W3C's model which multiplied my workload enormously (the pain yet lingers). Let's not add needlessly to plugin authors workload in requiring them to support two box models and let them get on with their work in designing plugins without having to deal with this mess. If the plugin author wants to use border-box let them define it themselves but don't ENFORCE it.

One thing that is worth mentioning in this discussion is that the reason given in Trac for use of the universal selector for border box sizing was to clean up the CSS ​http://core.trac.wordpress.org/ticket/23582 . Whilst it certainly does that it doesn't make the CSS simpler and in fact in does quite the opposite.

Because IE7 and IE8 are supported we have to support three box models as a result.

Border box for non IE and IE9+.

Half border box for IE8 (due to non support of border box for min and max width)

Content box for IE7

Any changes in the CSS have to be updated for all three.

Add RTL to that and the result is CSS hell (I've just been there and all I got for my efforts was a Zebra).

What to do about it? Well we can live with it and provide the warning I mentioned earlier in the CSS so at least we can say you were warned that these are dangerous waters to be swimming in.

That would mostly work and is certainly useful if you have elements all over the place. Otherwise if your plugin uses a container as me and cello expressions are using the following also mostly works (as mentioned in an earlier post).

However both methods are problematic when applied to the top level widget box as it appends the widget class for which twelve thirteen has defined both width and padding.

Note that twelve thirteen by adding padding and width to the widget class is breaking tradition as well leading to unfortunate styling consequences as most current plugins assume they have access to the full width of the widget container. Instead to achieve the plugin surround I suggest we provide a parent container to do this. This is the easy way to solve this problem and the problem above and provide consistent behavior between plugins and themes. Note the surround is really only useful for sidebar widgets. For footer widgets masonry can be used to provide the desired separation.

Pity, my fixes was quite easy to implement and well and truly satisfied the original aim of cleaning up the CSS whilst keeping plugin developers happy. Also quite noticeable is that nobody mentioned my proposed fixes in the discussion.

So the real outcome of this discussion is that you have decided to make it mandatory for plugins to detect both box-sizing and padding of widgets and act accordingly. This should be mentioned in the codex.

Also quite noticeable is that nobody mentioned my proposed fixes in the discussion.

Those of us in the discussion have all read the ticket here.

So the real outcome of this discussion is that you have decided to make it mandatory for plugins to detect both box-sizing and padding of widgets and act accordingly.

I think the outcome was that plugins generally shouldn't be doing that much styling, but that when they do we'd like to push (challenge?) them to use specific selectors and to not make assumptions on existing styles.

Also quite noticeable is that nobody mentioned my proposed fixes in the discussion.

Those of us in the discussion have all read the ticket here.
t

Maybe I should of been clearer. I wasn't saying nobody looked at it. I was merely trying to point out the discussion was more about leaving twelvethirteen as is and whether it's potential in breaking plugins was a good thing or not. It was decided that this was a good thing. A fix (even a simple one) wasn't on the cards.

So the real outcome of this discussion is that you have decided to make it mandatory for plugins to detect both box-sizing and padding of widgets and act accordingly.

I think the outcome was that plugins generally shouldn't be doing that much styling, but that when they do we'd like to push (challenge?) them to use specific selectors and to not make assumptions on existing styles.

I not sure what you mean by styling as this problem is immediately apparent at the top level widget class (as mentioned 5 posts back) as twelve thirteen applies padding to the widget. Combined with border-box these are two large differences from past official themes which have to be accounted for by all plugins that have widgets.

I'll be honest, I weighed in on the discussion thinking it was all-or-nothing. I had not dived deeply into the ticket.

I'd be satisfied with:

Adding a comment to the file explaining box-sizing: border-box.

Consideringtargeted content-box changes.

There is a lot of code pasted onto this ticket — if they can be turned into an SVN patch, that would be very useful in evaluating it.

Hi Nacin,

For just the universal box selector amending style.css as given in comment 25 is all that is needed. I considered doing a svn (though I haven't done this before) but since this file is constantly changing I thought just posting the amended bits as follows was a better option. Each part to be substituted is separated by /* PART n */. Alternatively see further down for a link to an amended style.css.

But if you want to save yourself some time I have already tested it and it works fine. Also it's really very simple as all it does is leave everything as border box except for anything in the widget (.widget) and the content (.entry-content) which are set to the default content box with widths of these elements and their children adjusted accordingly. An exception is made for the searchform box which I universally defined as border-box.

The issue of padding for the widget class (comment 30) is another related issue. It can be addressed by providing a container for each widget with the necessary padding. This also means you have to add this to the widget declaration in functions.php and amend the masonry call in functions.js. All of this is done here ​http://test4.2rrr.org.au/?preview=1&template=twentythirteenzebra&stylesheet=twentythirteenzebra. I willing to share the code if anyone is interested. Note with this change Zebra is fully backwards compatible with all plugins unlike twelvethirteen.

The final issue of handling CSS for three different box models due to IE7 and IE8 (which plugins will inherit) is also a separate but related issue (comment 29). Use of a compatibility library such as ie9.js or other javascript to conform min-width, max-width, and box-sizing could be a solution. Of course you could always just live with the mess or toss it for a pad with content-box layout.

However plugin developers need to know of this now to avoid problems caused by this change before WordPress 3.6 is released. Without this knowledge it took me a day to figure out and I am super experienced.

The final issue of handling CSS for three different box models due to IE7 and IE8 (which plugins will inherit) is also a separate but related issue (comment 29). Use of a compatibility library such as ie9.js or other javascript to conform min-width, max-width, and box-sizing could be a solution. Of course you could always just live with the mess or toss it for a pad with content-box layout.

Had a look at ie9.js and it has too many bugs to be usable. Coding javascript to parse and fix css in this regard isn't easy and isn't worth the trouble. Seems we are stuck with separate stylesheets if we use universal border-box.

One thing I found out while testing ie9.js is that IE7 and IE8 ignore the universal selector. Results as follows. Note the class 'ie8' is added to the 'html' tag for Internet Explorer 8.

* { ... } /* IGNORED BY IE */
*, .ie8 * { ... } /* ALL IGNORED BY IE */
.ie8 *, * { ... } /* WORKS FOR IE8 BUT NOT FOR FIREFOX */
If you want to use this for IE8 the following works
.ie8 * { ... } /* WORKS FOR IE8 */

So given there is no easy way out of having to deal with three different box models due to support of IE7 and IE8 I think the use of universal border-box here was a silly decision to start with. Furthermore forcing it on everyone else by not constraining it to this theme is an appalling decision.

However plugin developers need to know of this now to avoid problems caused by this change before WordPress 3.6 is released. Without this knowledge it took me a day to figure out and I am super experienced.

Two weeks have past since I posted that and there has been NO response or action. On one hand you say that you want plugin authors to update their plugins for WordPress 3.6 but on the other hand it seems you are not willing to publicize this. What goes?

Waiting for plugin authors to find this problem by spending hours debugging is definitely uncool and needless and will be looked on unfavorably by the community.

Since nothing has been done in regards to publicizing these changes as requested by myself and celloexpressions I have taken the step of adding a post to the alphabeta forum