[wp-trac] [WordPress Trac] #24306: Twenty Thirteen: border-box box sizing will break many plugins

[WordPress Trac]

#24306: Twenty Thirteen: border-box box sizing will break many plugins
---------------------------+--------------------
 Reporter:  professor99    |       Owner:
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  3.6
Component:  Bundled Theme  |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  needs-patch    |
---------------------------+--------------------

Comment (by professor99):

 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 seems to 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.

 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?

--
Ticket URL: <http://core.trac.wordpress.org/ticket/24306#comment:12>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software