Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#24306 closed defect (bug) (wontfix)

Twenty Thirteen: border-box box sizing will break many plugins

Reported by: professor99's profile professor99 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.6
Component: Bundled Theme Keywords:
Focuses: Cc:

Description (last modified by SergeyBiryukov)

WordPress 3.6-beta2-24227

/wp-content/themes/twentythirteen/style.css

* {
    -moz-box-sizing: border-box;
}

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

Change History (39)

#1 @SergeyBiryukov
11 years ago

  • Component changed from Themes to Bundled Theme
  • Description modified (diff)

#2 @professor99
11 years ago

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."

* {
	-webkit-box-sizing: border-box;
	-moz-box-sizing:    border-box;
	box-sizing:         border-box;
}
Last edited 11 years ago by SergeyBiryukov (previous) (diff)

#3 @professor99
11 years ago

Forgot to add that given the above correction I also need to correct the statement "will break the styling of many plugins for Firefox" to "will break the styling of many plugins for all browsers".

#4 @professor99
11 years ago

Just one other thing worth noting.

From style.css

/**
 * 1.0 Reset
 *
 * Modified from Normalize.css to provide cross-browser consistency and a smart
 * default styling of HTML elements.
 *
 * @see http://git.io/normalize
 * ----------------------------------------------------------------------------
 */

* {
	-webkit-box-sizing: border-box;
	-moz-box-sizing:    border-box;
	box-sizing:         border-box;
}

article,
aside,
details,
figcaption,
figure,
footer,
header,
nav,
section,
summary {
	display: block;
}

Normalize.css  @ http://git.io/normalize starts from 

article,
aside,
details,
....

The box-sizing isn't part of it.

Last edited 11 years ago by ocean90 (previous) (diff)

#5 @celloexpressions
11 years ago

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:

.plugin-container, .plugin-container * {
box-sizing: content-box;
-moz-box-sizing: content-box;
-webkit-box-sizing: content-box;
}

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.

#6 @professor99
11 years ago

Hi celloexpressions.

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.

#8 @professor99
11 years ago

Thanks obenland,

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.

#9 @lancewillett
11 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 3.6

#10 @aaroncampbell
11 years ago

What's the plan for this one? It seems to me like it's fine to have the box-model set on all elements and allow plugins that need to deal with it to specify it for their elements.

#11 @celloexpressions
11 years ago

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.

#12 @professor99
11 years ago

Done a bit more research on this that is worth sharing.

Background links on box-sizing

Mozilla box-sizing reference: https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing

CSS tricks reference: http://css-tricks.com/box-sizing/

Paul Irish's page on box-sizing: http://www.paulirish.com/2012/box-sizing-border-box-ftw/

The revision of style.css that applied the universal selector to box-sizing is 23520
http://core.trac.wordpress.org/browser/trunk/wp-content/themes/twentythirteen/style.css?rev=23520

The discussion that discussed these changes is
http://core.trac.wordpress.org/ticket/23582#no1

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.

Initial value: content-box
Applies to: all elements that accept width or height
Inherited: no

The important thing to note from above is that if the box-sizing attribute is used on an element it is NOT inherited by children of that element.

The theme elements that previously had the box-sizing property set to border-box were

input[type="checkbox"],
input[type="radio"],
.site-header hgroup,
.site-header .searchform .field,
.site-main .widget-area,
.site-footer .widget-area,
.site-footer .widget,
.sidebar .entry-header,
.sidebar .entry-content,
.sidebar .entry-summary,
.sidebar .entry-meta,
.sidebar .archive-meta,
.sidebar .page-content,
.sidebar .comments-title,
.sidebar .comment-list,
.sidebar .no-comments,
.sidebar #reply-title,
.sidebar .comment-navigation,
.sidebar #respond #commentform,
.sidebar .paging-navigation .nav-links,
.sidebar .post-navigation .nav-links,
.author.sidebar .author-info,
.format-status .entry-content,
.format-status .entry-meta,
.widget .searchform .field,

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?

That just leaves the following elements.

.site-header hgroup,
.site-main .widget-area,
.site-footer .widget-area,
.site-footer .widget,
.format-status .entry-content,
.format-status .entry-meta,

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?

Last edited 11 years ago by professor99 (previous) (diff)

#13 @professor99
11 years ago

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.

input[type="search"] {
	-webkit-appearance: textfield;
	-webkit-box-sizing: content-box;
	-moz-box-sizing:    content-box;
	box-sizing:         content-box;
	padding-right: 2px; /* Don't cut off the webkit search cancel button */
}

Note the above is what is given by normalize.css (http://necolas.github.io/normalize.css/2.1.2/normalize.css) to make Safari5 and Chrome consistent with other browsers.

However these box-sizing definitions were removed in revision 23620 to fix ticket 23679 "Search input element breaks padding of container"

http://core.trac.wordpress.org/ticket/23679

diff http://core.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&new=23620%40trunk%2Fwp-content%2Fthemes%2Ftwentythirteen%2Fstyle.css&old=23614%40trunk%2Fwp-content%2Fthemes%2Ftwentythirteen%2Fstyle.css&sfp_email=&sfph_mail=

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.

#14 @professor99
11 years ago

Also just noticed ".site-header hgroup" no longer exists. It was a div wrapper around the site-title and site-description headings in the header.

The box-sizing can be applied instead to the .site-header .home-link wrapper to achieve the same effect

Last edited 11 years ago by professor99 (previous) (diff)

#15 @professor99
11 years ago

Whoops. The diffs cut me short! Missed the following CSS definitions which had border box defined before revision 23520

For @media (max-width: 1069px)

	.navbar-secondary .searchform,
	.archive-header,
	.search .page-header,
	.blog .page-header,
	.error404 .page-content,
	.attachment .entry-header,
	.attachment .entry-content,
	.post-navigation .nav-links,

And for @media (max-width: 643px)

#content .entry-header,
#content .entry-content,
#content .entry-summary,
#content footer.entry-meta,
#content .featured-gallery,
.search.sidebar .page-content,
.blog.sidebar .page-content,
.sidebar .post-navigation .nav-links,
.paging-navigation .nav-links,
.author .author-info,
.comments-area .comments-title,
.comments-area .comment-list,
.comments-area .comment-navigation,
#respond,
.sidebar .site-info,
.sidebar .paging-navigation .nav-links

Version 1, edited 11 years ago by professor99 (previous) (next) (diff)

#16 @professor99
11 years ago

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.

#17 @professor99
11 years ago

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.

#18 follow-up: @lancewillett
11 years ago

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.

#19 follow-up: @obenland
11 years ago

Was there a plugin specifically mentioned as breaking in this thread?

It really is not a black and white decision. Originally I was not too happy with the approach, but more out of aesthetic reasons. It doubt it will break many plugins though. It might break some.

We are in beta3 and plugin authors should have had plenty of time to test their plugins with Twenty Thirteen. So I'm also leaning towards keeping it (for now).

#20 in reply to: ↑ 19 @lancewillett
11 years ago

Replying to obenland:

Was there a plugin specifically mentioned as breaking in this thread?

Joen mentioned the "Gravatar Hovercards" breaking, and that it was difficult to debug.

#21 in reply to: ↑ 18 @professor99
11 years ago

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.

Try this for example with border box sizing.

<div style="width:100px;padding:40px;">
  <div style="overflow:hidden">
    <div style="width:80px;font-size:22px;">$100000</div>
  </div>
</div>

One workaround that could satisfy everybody is to use the universal selector to define border box sizing for most of the theme but set it back to content box sizing for widgets and content as follows.

.widget, .widget * {
	-webkit-box-sizing: content-box;
	-moz-box-sizing:    content-box;
	box-sizing:         content-box;
}

.entry-content, .entry-content * {
	-webkit-box-sizing: content-box;
	-moz-box-sizing:    content-box;
	box-sizing:         content-box;
}
Last edited 11 years ago by SergeyBiryukov (previous) (diff)

#22 @professor99
11 years ago

The plugin I am working on that breaks is WP User Frontend.

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.

#23 @Jayjdk
11 years ago

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.

You would still have to do that. Even if Twenty Thirteen didn't use an universal selector, many other themes will still do.

What kind of 'weird' CSS/JS do you have to use? Can't you use one of of them in your plugin? That way you don't have to write CSS for both cases.

.your-selectors,
[class*="your-plugin-prefix-"] {
   box-sizing: border-box;      or
   box-sizing: content-box;
}

#24 follow-up: @professor99
11 years ago

Hi Jayjdk,

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.

#25 @professor99
11 years ago

I've tested the solution I gave above using content-box sizing for the widget and entry-content classes and it works great.

All you have to do is add the following.

/**
 * 0.0 Box Sizing
 *
 * Universally set to border box.
 * 
 * Set back to standard content-box setting for content and widgets.
 *
 * ----------------------------------------------------------------------------
 */
 
* {
	-webkit-box-sizing: border-box;
	-moz-box-sizing:    border-box;
	box-sizing:         border-box;
}

.entry-content, .entry-content  * {
	-webkit-box-sizing: content-box;
	-moz-box-sizing:    content-box;
	box-sizing:         content-box;
}

.widget, .widget * {
	-webkit-box-sizing: content-box;
	-moz-box-sizing:    content-box;
	box-sizing:         content-box;
}

We also have to make some adjustments to the width settings for .entry-content and .widget and their children.

For widgets we need to adjust the width for the main DIV and it seems this is only defined for the footer widgets which are shortened if there is a sidebar (Why?).

.site-footer .widget {
    background: transparent;
    color: #fff;
    float: left;
    margin-right: 20px;
    width: 205px
}

/* Why do we do this? */
.sidebar .site-footer .widget {
	width: 188px
}

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.

.widget .searchform input[type="text"],
.widget .searchform input[type="search"] {
	-webkit-box-sizing: border-box;
	-moz-box-sizing:    border-box;
	box-sizing:         border-box;
}

For entry-content the only thing I can see that needs to be done is adjust the max-width as follows.

.entry-header,
.entry-content,
.entry-summary,
.entry-meta {
	margin: 0 auto;
	max-width: 604px;
	width: 100%;
}

.sidebar .entry-header,
.sidebar .entry-content,
.sidebar .entry-summary,
.sidebar .entry-meta {
	padding: 0 376px 0 60px;
}

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 :)

#26 in reply to: ↑ 24 ; follow-ups: @Jayjdk
11 years ago

Replying to professor99:

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?

By only looking at the themes on this page I found:

I also found some on ThemeForest.

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.

#27 @paulwp
11 years ago

This is so that we all could see the CSS used in paulirish site. Comparing soon after that post is published, and a long time after —even after the site's redesign.

* { Box-sizing: Border-box } FTW (but me) back then
http://web.archive.org/web/20120225164658/http://paulirish.com/2012/box-sizing-border-box-ftw/

* { Box-sizing: Border-box } FTW (but me) now
http://web.archive.org/web/20130502125925/http://paulirish.com/2012/box-sizing-border-box-ftw/

Why wouldn't he apply that to his own site ?

Same thing to the rem thingy in Twentytwelve, the link to snook.ca is suggested for "Further reading" in Twentytwelve's style.css

snook.ca up until now is using px for font sizing.
http://snook.ca/css/snook-v10.css

Last edited 11 years ago by paulwp (previous) (diff)

#28 in reply to: ↑ 26 @professor99
11 years ago

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.

#29 @professor99
11 years ago

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.

  1. Border box for non IE and IE9+.
  2. Half border box for IE8 (due to non support of border box for min and max width)
  3. 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.

#30 in reply to: ↑ 26 @professor99
11 years ago

Missed your update to the selector earlier to

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

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).

 .plugin-container, .plugin-container * {
box-sizing: content-box;
-moz-box-sizing: content-box;
-webkit-box-sizing: content-box;
}

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.

Last edited 11 years ago by SergeyBiryukov (previous) (diff)

#31 @lancewillett
11 years ago

  • Keywords needs-patch removed
  • Milestone 3.6 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Discussed this at length in today's Twenty Thirteen office hours, in #wordpress-dev IRC. The consensus was to leave the universal selector in place. Log here: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-06-06&sort=asc#m624176

Closing as wontfix.

#32 follow-up: @professor99
11 years ago

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.

Last edited 11 years ago by professor99 (previous) (diff)

#33 in reply to: ↑ 32 ; follow-up: @aaroncampbell
11 years ago

Replying to professor99:

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.

#34 follow-ups: @nacin
11 years ago

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.
  • Considering targeted 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.

#35 in reply to: ↑ 33 @professor99
11 years ago

Replying to aaroncampbell:

Replying to professor99:

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.

#36 in reply to: ↑ 34 ; follow-up: @professor99
11 years ago

Replying to nacin:

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.
  • Considering targeted 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.

/*** PART 1 ***/

* {
	-webkit-box-sizing: border-box;
	-moz-box-sizing:    border-box;
	box-sizing:         border-box;
}

.entry-content, .entry-content  * {
	-webkit-box-sizing: content-box;
	-moz-box-sizing:    content-box;
	box-sizing:         content-box;
}

.widget, .widget * {
	-webkit-box-sizing: content-box;
	-moz-box-sizing:    content-box;
	box-sizing:         content-box;
}


/*** PART 2 ***/

.entry-header,
.entry-content,
.entry-summary,
.entry-meta {
	margin: 0 auto;
	max-width: 604px;
	width: 100%;
}

.sidebar .entry-header,
.sidebar .entry-summary,
.sidebar .entry-meta {
	max-width: 1040px;
	padding: 0 376px 0 60px;
}

.sidebar .entry-content {
	padding: 0 376px 0 60px;
}

/*** PART 3 ***/

.widget .searchform [type="text"] {
	width: 100%;
}

.widget .searchform input[type="text"],
.widget .searchform input[type="search"] {
	-webkit-box-sizing: border-box;
	-moz-box-sizing:    border-box;
	box-sizing:         border-box;
}

/*** PART 4 ***/

.site-footer .widget {
    background: transparent;
    color: #fff;
    float: left;
    margin-right: 20px;
    width: 205px
}

/* Why do we do this? */
.sidebar .site-footer .widget {
	width: 188px
}

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.

All of this is implemented on my test site at http://test4.2rrr.org.au/?preview=1&template=twentythirteen&stylesheet=twentythirteen which runs WordPress 3.6-beta3. Ive added sidebars on this as more problems occur with this when sidebars are enabled.

The amended style.css file is http://test4.2rrr.org.au/wp-content/themes/twentythirteen/style.css

The original style file is http://test4.2rrr.org.au/wp-content/themes/twentythirteen/style_orig.css

Note this test website and it's style.css file only have the change for the universal selector applied and no changes related to the issues below.

Another issue mentioned is the default widths for widgets (comment 25). The sidebar doesn't define a widget width. The footer defines two widths. One with sidebar and one without. Don't know why this is done. On my Twelve Thirteen variant Zebra theme http://test4.2rrr.org.au/?preview=1&template=twentythirteenzebra&stylesheet=twentythirteenzebra I have given all widgets the WordPress recommended max size 250px.

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.

#37 in reply to: ↑ 34 ; follow-up: @professor99
11 years ago

Replying to nacin:

I'd be satisfied with:

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

That would be a good start for anybody experiencing problems. I've already done this for my modified version here http://test4.2rrr.org.au/wp-content/themes/twentythirteen/style.css.

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.

I suggest adding this to the codex NOW under the Migrating Plugins and Themes section https://codex.wordpress.org/Migrating_Plugins_and_Themes is the appropriate thing to do. Waiting to release time is too late. It's also should be mentioned in the Beta forum http://wordpress.org/support/forum/alphabeta and in the next Beta post http://wordpress.org/news/2013/05/wordpress-3-6-beta-3/ on WordPress news.

#38 in reply to: ↑ 36 @professor99
11 years ago

Replying to professor99:

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.

#39 in reply to: ↑ 37 @professor99
11 years ago

Replying to professor99:

Replying to nacin:

I'd be satisfied with:

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

That would be a good start for anybody experiencing problems. I've already done this for my modified version here http://test4.2rrr.org.au/wp-content/themes/twentythirteen/style.css.

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.

I suggest adding this to the codex NOW under the Migrating Plugins and Themes section https://codex.wordpress.org/Migrating_Plugins_and_Themes is the appropriate thing to do. Waiting to release time is too late. It's also should be mentioned in the Beta forum http://wordpress.org/support/forum/alphabeta and in the next Beta post http://wordpress.org/news/2013/05/wordpress-3-6-beta-3/ on WordPress news.

@Twenty Thirteen developers

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

http://wordpress.org/support/topic/update-your-plugins-universal-border-box-sizing-and-widget-padding?replies=1#post-4361331

You are more than welcome to modify my forum post and use this to inform plugin authors where appropriate.

Note: See TracTickets for help on using tickets.