Centering the background image (wrongly placed in ciwa)

[dorayme]

In article <jp6ljq$brh$1...@dont-email.me>,
"Jonathan N. Little" <lws...@gmail.com> wrote:

...

> the issue at hand was the background image was applied to the
> BODY element. When the BODY element had no height the image was
> vertically centered on the thin line of BODY at the top of the viewport
> as expected. But if you add a FIXED attachment it aligned to the
> viewport of the browser and not the BODY while still being associated
> with the BODY element. That is puzzling.

"If a background image is specified, [the background-attachment]
property specifies whether it is fixed with regard to the viewport
('fixed') or scrolls along with the containing block ('scroll')."

from 14.2.1 of the 2.1 CSS.

I long ago made my peace with the thieving ways of Viewport and the
HTML element. They even steal body background colours without any
fixed context. You can give BODY a background colour and before you
can say "Long Bay Jail", Viewport has pinched it, HTML grabs the image!

<http://dorayme.netweaver.com.au/body.html>

Honestly, it's a disgrace and this has been going on for a long time!

--
dorayme

[Gus Richter]

In this instance the image question is explained by the box model
<http://www.w3.org/TR/CSS2/box.html#box-dimensions>

body = margin + content

The background image is placed 0,0 by default in this demo and because
of the extended margin (200px), the background image sits in the margin
area and is visible because margin is transparent and why the margin's
background color of #cfc shines through.

I am very tired at this point and need sleep, so your second part as to
why html has acquired the same #cfc background color from body is for
someone else, or I will tackle it tomorrow (hopefully).

I have another question: Add background-color:teal; to html
1. See html and body's margin turn to teal. WHY?
2. See body's background image now move to the content area. WHY?

--
Gus

[Swifty]

On Sun, 20 May 2012 15:05:59 +1000, dorayme <dor...@optusnet.com.au>
wrote:

>I long ago made my peace with the thieving ways of Viewport and the
>HTML element.

I wonder if this explains (partly) a minor issue that I see in recent
versions of the Opera browser?

I tend to give my webpages pastel shaded backgrounds (applied to the
BODY).

If I go into "Print Preview" in Opera then I see the page on a white
background (Opera's default is not to print the background colour, and
it accurately simulates this)... so far, so good.

When I come back out of preview mode then I now have the background
colour, but only where there are elements of my page on top of it.
Beyond the bottom of my page, the lower part of my browser window is
now white, where before it was pastel.

So, should I be complaining to Opera that, upon coming out of Preview
Mode, the BODY background colour is no longer applied to the viewport
(or the HTML)?

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[dorayme]

In article <jpa22l$nr6$1...@dont-email.me>,

Yes, when HTML was on trial for theft, the defence did bring this up.
But the prosecutor replied with

<http://dorayme.netweaver.com.au/body1.html>

"There!", said the prosecuting counsel, "see how this thief operates?
He hides his misdeeds in the dark of margins *when* he can. But when
the police laid a trap for him, bang, he was caught with his pants
down".

She went on. "No matter where poor BODY goes, even carefully without
margins hanging off its content edges for scoundrels to hide in,
hugging its background image tightly, thieves of the like of HTML can
swoop and in an instance grab the hapless victim's goods".

--
dorayme

[dorayme]

In article <n07hr718fak6pbshs...@4ax.com>,

Swifty <steve....@gmail.com> wrote:

> On Sun, 20 May 2012 15:05:59 +1000, dorayme <dor...@optusnet.com.au>
> wrote:
>
> >I long ago made my peace with the thieving ways of Viewport and the
> >HTML element.
>
> I wonder if this explains (partly) a minor issue that I see in recent
> versions of the Opera browser?
>
> I tend to give my webpages pastel shaded backgrounds (applied to the
> BODY).
>
> If I go into "Print Preview" in Opera then I see the page on a white
> background (Opera's default is not to print the background colour, and
> it accurately simulates this)... so far, so good.
>
> When I come back out of preview mode then I now have the background
> colour, but only where there are elements of my page on top of it.
> Beyond the bottom of my page, the lower part of my browser window is
> now white, where before it was pastel.
>

Even before coming out of Preview (on a Mac at least), the original
page in an Opera tab shows changes, even dramatic ones like returning
a stolen goods in such as

http://dorayme.netweaver.com.au/body.html

and

http://dorayme.netweaver.com.au/body1.html

At least on my latest Opera on a Mac. Refreshing the window restores
the background image and the colour to the HTML and Viewport
(respectively). It as if the browser is aiding and abetting this
thieving, proclaiming loud and clear that possession is nine-tenths of
the law.

Doing very similar in Firefox does not change the webpage itself in
the browser.

Opera is playing all sorts of fancy tricks, a sort of hire-wire act,
it shows popouts of the tabs as you move the mouse over, it is often
extremely irritating when you know beforehand what is in each tab and
just want to switch, there seems hardly any delay. I am making the
point that this browser, cutting edge and idiosyncratic as it is, is
juggling so many balls at once, it is a wonder it works as well as it
does.

> So, should I be complaining to Opera that, upon coming out of Preview
> Mode, the BODY background colour is no longer applied to the viewport
> (or the HTML)?

I would guess it is some sort of bug. You might draw their attention
to it I suppose.

--
dorayme

[Jonathan N. Little]

Hmmm, interesting however I have issue that that is not a spiral.

<http://www.littleworksstudio.com/temp/usenet/spiral200.png>

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

[dorayme]

In article <jpapm3$d53$1...@dont-email.me>,

"Jonathan N. Little" <lws...@gmail.com> wrote:

> Hmmm, interesting however I have issue that that is not a spiral.

You are right, odd you should be mentioning this when I was just
thinking the very same thing and looking at my vector version of it! I
named it rather too early for demo purposes and then made a figure I
fancied which was just concentric circles. Having posted to the
server, too late to change the words. But I suppose I could substitute
a spiral (like yours is).

I have 4000px versions, 2000, 400, 200 and will sell them in a stall
outside the office here tomorrow. They being wrongly named will draw
publicity and raise their price. The general public hate truth and
accuracy, you just have to look at both America and Australia in
election mode. <g>

--
dorayme

[Jonathan N. Little]

Try this one, and you can use the Jedi-mind-trick on 'em:

<http://www.littleworksstudio.com/temp/usenet/vertigo/gif>

[Jonathan N. Little]

Jonathan N. Little wrote:


> <http://www.littleworksstudio.com/temp/usenet/vertigo/gif>
>

Cannot type today:

<http://www.littleworksstudio.com/temp/usenet/vertigo.gif>

[Gus Richter]

On 5/20/2012 3:56 AM, dorayme wrote:
> <http://dorayme.netweaver.com.au/body1.html>
>
> "There!", said the prosecuting counsel, "see how this thief operates?

> He hides his misdeeds in the dark of margins*when* he can. But when

> the police laid a trap for him, bang, he was caught with his pants
> down".
>
> She went on. "No matter where poor BODY goes, even carefully without
> margins hanging off its content edges for scoundrels to hide in,
> hugging its background image tightly, thieves of the like of HTML can
> swoop and in an instance grab the hapless victim's goods".

Ref: <http://www.w3.org/TR/CSS2/colors.html#background> which explains:

For documents whose html element has computed values of 'transparent'
for 'background-color' and 'none' for 'background-image', user agents
must instead use the computed value of the background properties from
the "body" element child when painting backgrounds for the canvas, and
must not paint a background for that child element. Such backgrounds
must also be anchored at the same point as they would be if they were
painted only for the root element.

That means that in your body1.html example, html does not have
'background-color' and 'background-image' declared, so the spec says
that in such a case html must take the background values from body to
paint onto the canvas and anchor them to the same point that they would
be painted by the html element had the background values been provided
to html directly. Additionally, body must not also paint a background.

This explains this demo and also answers my previous post's question 1.
and 2.

--
Gus

[tlvp]

On Sun, 20 May 2012 23:13:31 +1000, dorayme wrote:

> ... The general public hate truth and

> accuracy, you just have to look at both America and Australia in
> election mode. <g>

Speaking at least for America, there's no need to wait for "election mode"
before looking, alas :-{ . Feel free to look just about any time.

Cheers, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.

[dorayme]

In article <jpc2jp$9ef$1...@dont-email.me>,

Gus Richter <gusri...@netscape.net> wrote:

> On 5/20/2012 3:56 AM, dorayme wrote:
> > <http://dorayme.netweaver.com.au/body1.html>
> >

...

> > She went on. "No matter where poor BODY goes, even carefully without
> > margins hanging off its content edges for scoundrels to hide in,
> > hugging its background image tightly, thieves of the like of HTML can
> > swoop and in an instance grab the hapless victim's goods".
>
> Ref: <http://www.w3.org/TR/CSS2/colors.html#background> which explains:
>

...

>
> That means that in your body1.html example, html does not have
> 'background-color' and 'background-image' declared, so the spec says
> that in such a case html must take the background values from body to
> paint onto the canvas and anchor them to the same point that they would
> be painted by the html element had the background values been provided
> to html directly. Additionally, body must not also paint a background.
>
> This explains this demo and also answers my previous post's question 1.
> and 2.

Yes, most things in these matters can be explained in the sense of
finding specifications that decree it. But for the most part, people
look for intuitiveness, making some sort of good sense, commonsense.

Different people will be satisfied by different levels of explanation.
For example when Jonathan Little rightly found something about fixed
background-attachment puzzling in this thread, and I quoted a bit of
the relevant bible on this, he quite rightly showed no interest and
instead wanted to talk about the more intriguing subject of spirals.

Some people will be sated by seeing it decreed in some bible, others
will regard it as a mystery and spin hopeful fairy tales about it and
make their peace with the mysteries.

The intuitive thing to happen when putting a background image on BODY,
on the natural assumption (gained from the ability to style it in
various ways), is that it keeps the image. But under various
conditions, as we have all noted, it does not. The concepts of the
HTML, BODY elements along with the idea of the viewport (and in latest
CSS), CANVAS probably need to be understood in the context of the
constraints and perhaps difficult decisions of early HTML development.

--
dorayme

[Gus Richter]

In this instance it would be nice to know why they had to do it this way
in the spec. Perhaps Ben will make an appearance?

--
Gus

[dorayme]

In article <jpeit5$qe3$1...@dont-email.me>,

At

<http://www.w3.org/TR/html401/struct/global.html#edef-BODY>

they say:

"The body of a document contains the document's content. The content
may be presented by a user agent in a variety of ways. For example,
for visual browsers, you can think of the body as a canvas where the
content appears: text, images, colors, graphics, etc."

I don't think they thought of BODY as just an ordinary box element.
Now and then, when in a mood to be minimalist about the markup, I use
it as an ordinary element, and even the HTML element for purposes of
styling. Reducing its size drastically, bordering it, etc.

There are things to watch out for in this approach as we have seen.
The point is that without fancy CSS thinking, BODY was and still is
mainly to be thought of as the box where all the stuff of the website
goes, most browsers give a small default margin (technically to the
HTML element but think viewport) for a bit of grace (authors could
bang away with their sentences and get thoughts across and they would
not be jammed up against the edges).

The quirks of styling it and its relations with the viewport and the
HTML element are not any really big impediment because it is probably
still pretty sensible to not be too fancy with styling BODY, to leave
it as default or mostly better to remove its margins altogether and
simply to use a child DIV wrapper or other DIVS (or more semantic
elements) for most purposes. Background images happily go with these
less mighty creatures.

When HTML was developed, all the ramifications of styling were not
taken into account, understandably enough.

--
dorayme

[Gus Richter]

On 5/21/2012 8:31 PM, dorayme wrote:
> <http://www.w3.org/TR/html401/struct/global.html#edef-BODY>
>
> they say:
>
> "The body of a document contains the document's content. The content
> may be presented by a user agent in a variety of ways. For example,
> for visual browsers, you can think of the body as a canvas where the
> content appears: text, images, colors, graphics, etc."

HTML is the cornerstone, but CSS adds, modifies and expands upon it.

You are into Mac, but try Firefox with Firebug, Webdeveloper and Tilt
Add-ons. Once you have them installed, go to your body1.html (or any
doc), but with the body1.html select tools/Web Developer/Tilt and on
the bar below click on div.code and it will show you the div viewport,
likewise selecting body will show the body viewport and selecting
html shows the html viewport. Outside of it is the Canvas. Each
viewport will show right down to the canvas, if all layers in between
are transparent.

If you have done so successfully so far, select 3D View on the right.
Now click, hold and drag your cursor up and around. You should see it
all rotating (tilting) at your will. You will see all the layers. Note
that your background image is clearly on the html layer. One layer is
your #cfc background color. No other transparency is in your
html1.html but you can arrange to create one for yourself in another
demo if you want. Note that what you are rotating is the html layer
and all the other layers on top of it. Outside of html is the nether
world of Canvas.

Interesting, eh?

--
Gus

[dorayme]

In article <jpeqd8$vc4$1...@dont-email.me>,

Gus Richter <gusri...@netscape.net> wrote:

> On 5/21/2012 8:31 PM, dorayme wrote:
> > <http://www.w3.org/TR/html401/struct/global.html#edef-BODY>
> >
> > they say:
> >
> > "The body of a document contains the document's content. The content
> > may be presented by a user agent in a variety of ways. For example,
> > for visual browsers, you can think of the body as a canvas where the
> > content appears: text, images, colors, graphics, etc."
>
> HTML is the cornerstone, but CSS adds, modifies and expands upon it.

Adding class and inline-style attributes, and maybe some specialised
things to do with pseudo classes and elements, add and modify, true.
But, in a very abstract sort of a way, html in itself does not look or
sound any particular way, it is only because it has default styles
that it can take on .... well... you know, that terrific and rather
nice basic look, the sort of look that saves us from those garish and
too often centred text pages that are around. To take the simplest
thing, telling the browser to colour the text red is not really adding
or subtracting or modifying the html. But, yes, it changes, and
sometimes radically, what it would otherwise look like without
styling.

--
dorayme

[dorayme]

In article <jpeqd8$vc4$1...@dont-email.me>,

Gus Richter <gusri...@netscape.net> wrote:

> You are into Mac, but try Firefox with Firebug, Webdeveloper and Tilt
> Add-ons. Once you have them installed, go to your body1.html (or any
> doc), but with the body1.html select tools/Web Developer/Tilt and on
> the bar below click on div.code and it will show you the div viewport,
> likewise selecting body will show the body viewport and selecting
> html shows the html viewport. Outside of it is the Canvas. Each
> viewport will show right down to the canvas, if all layers in between
> are transparent.
>
> If you have done so successfully so far, select 3D View on the right.
> Now click, hold and drag your cursor up and around. You should see it
> all rotating (tilting) at your will. You will see all the layers. Note
> that your background image is clearly on the html layer. One layer is
> your #cfc background color. No other transparency is in your
> html1.html but you can arrange to create one for yourself in another
> demo if you want. Note that what you are rotating is the html layer
> and all the other layers on top of it. Outside of html is the nether
> world of Canvas.
>
> Interesting, eh?

Yes, it is. Thanks for this.

--
dorayme

[Gus Richter]

YVW. I'm glad you liked it.

--
Gus

[Ben C]

On 2012-05-21, dorayme <dor...@optusnet.com.au> wrote:
[...]

> Yes, most things in these matters can be explained in the sense of
> finding specifications that decree it. But for the most part, people
> look for intuitiveness, making some sort of good sense, commonsense.
> Different people will be satisfied by different levels of explanation.

It's often helpful when trying to understand these things to think about
what the motivation might have been (and that counts as a level of
explanation).

In this case the basic problem is that there is no element for the
viewport. They start at HTML. But certain styles, like overflow and
background, are things you sometimes want to apply to the viewport.

So the arrangement is they get sort of forwarded from HTML and BODY
under certain circumstances. The exact details of how it works are
probably muddied by the usual "historical reasons" etc.

[...]

> The concepts of the HTML, BODY elements along with the idea of the
> viewport (and in latest CSS), CANVAS probably need to be understood in
> the context of the constraints and perhaps difficult decisions of
> early HTML development.

A few things have ended up a bit strange. If you put a background image
on a div with overflow: scroll you would think that
background-attachment: scroll would mean the picture moved with the
contents as you scrolled it, and background-attachment: fixed that it
wouldn't.

But it never moves with the contents, and "fixed" fixes it to the
_viewport_, which is just a weird effect that I can't imagine anyone
would ever want. background-attachment as defined only really makes any
sense on the viewport.

[Ben C]

On 2012-05-21, Gus Richter <gusri...@netscape.net> wrote:
[...]

> In this instance it would be nice to know why they had to do it this way
> in the spec. Perhaps Ben will make an appearance?

It's only a guess but perhaps part of the reason is the problem of there
being no element for the viewport.

But there is history to it too. Background images, especially fixed
ones, were all the rage in the early days of the www. People used to
go in for a sort of textured blotting-paper look.

[Gus Richter]

On 5/23/2012 4:43 PM, Ben C wrote:
> It's only a guess but perhaps part of the reason is the problem of there
> being no element for the viewport.

Ref:

<http://dev.opera.com/articles/view/an-introduction-to-meta-viewport-and-viewport/>
<http://dev.w3.org/csswg/css-device-adapt/#the-viewport-rule>

There are two kinds of viewport for handheld - initial and actual and
there apparently is a meta element and an @viewport CSS rule to
describe the viewport.

--
Gus