WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#13763 closed defect (bug) (invalid)

margin and padding settings can result in awkward background image handling

Reported by: Denis-de-Bernardy Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Themes Keywords: close dev-feedback
Focuses: Cc:

Description

The attached screenshot should speak for itself.

The gist of the problem is when the body tag is made to have zero margins and paddings, while the #wrapper id has a positive margin and/or the screen's content is way too short to fill the browser.

Using CSS to skin the html tag instead of the body tag should fix the issue.

Attachments (1)

2010-06-07_1433.jpg (211.2 KB) - added by Denis-de-Bernardy 4 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 ocean904 years ago

  • Keywords reporter-feedback added
  • Milestone changed from 3.0 to Unassigned

Can't see a bug here, can you explain it in details? WHich theme is it?
In 2010 the body tag has zero margins and paddings and the wrapper a positive margin and can't see a problem.

Set milestone to unassigned until a bug is found.

comment:2 Denis-de-Bernardy4 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Unassigned to 3.0

Makes me wonder why I bothered to attach a screenshot...

Try my own (www.semiologic.com/software/sem-reloaded/), albeit without the custom background handler I added this afternoon, along with the admin menu plugin (www.semiologic.com/software/admin-menu/).

The fix is simple: s/body {/html {/ in the background callback.

comment:3 ocean904 years ago

  • Keywords close dev-feedback added

Okay, with you theme I get this issue too, but I don't know why. In Twentyten it's the same and it works:

<html> => margin: 0

<body> => margin: 0

<div class="wrapper"> => margin-top: 20px
I also tried some themes on wp.com and they works too.
It must be a problem with your theme.
So if someone has such a problem they can define a custom callback, like yours in sem-reloaded, and use html instead of body.
Also it's very unusual to clarify the background image for the html tag.

So I would say wontfix.

comment:4 nacin4 years ago

You have the margin of your wrapper messing with the position of the body element.

I've very rarely seen the html element in use for background images, and usually that is only when a technique is used to use both tags together. Importantly, I'd think we need to make sure we're definitely replacing existing background declaration, which in 99.5% of themes will be on the body element.

Food for thought, this is from the CSS1 spec. http://www.w3.org/TR/REC-CSS1/#the-canvas


HTML extensions have set a precedent for the second question: attributes on the 'BODY' element set the background of the whole canvas. To support designers' expectations, CSS1 introduces a special rule to find the canvas background:

If the 'background' value of the 'HTML' element is different from 'transparent' then use it, else use the 'background' value of the 'BODY' element. If the resulting value is 'transparent', the rendering is undefined.
This rule allows:

<HTML STYLE="background: url(http://style.com/marble.png)">
<BODY STYLE="background: red">
In the example above, the canvas will be covered with "marble". The background of the 'BODY' element (which may or may not fully cover the canvas) will be red.

Until other means of addressing the canvas become available, it is recommended that canvas properties are set on the 'BODY' element.

comment:5 ryan4 years ago

  • Milestone 3.0 deleted
  • Resolution set to invalid
  • Status changed from new to closed

I think the custom callback is the right solution for these situations.

Note: See TracTickets for help on using tickets.