«

On 2008-03-13, dorayme <> wrote:
> In article <>,
> Ben C <> wrote:
>
>> On 2008-03-11, dorayme <> wrote:
>> > In article <>,
>> > Ben C <> wrote:
>> >
>> >> On 2008-03-11, dorayme <> wrote:
>> >> [...]
>> >> > Now to matters more curious to me:
>
>> The point of the canvas is this.
>>
>
> I am still looking at your explanation, Ben. Take the delay as a
> compliment. The martian brain is a bit different to the earthling
> one and so please be patient.

The key point to consider is this: if you put a background image
(something anisotropic, like an actual picture, not just a solid colour)
on the body element, and then scroll the page, the image moves as the
page scrolls.

That is what browsers have been doing since before the days of CSS, but
it's actually very weird behaviour and there's no way to get that
behaviour with CSS except on the root element with the special rules for
the root element.

The reason is that the region that that image is tiling is not the
padding box of any particular element: it's the bounding box of the root
element and all its descendents. That's the so-called "canvas". For
every other element, you can only put backgrounds on padding boxes.

Put a background image on a div with overflow: scroll and there's no
way you can make the image move when the div scrolls.

> I am resisting impudently suggesting models I have had in mind
> until I see a bit more what the models have to account for.
>
> Obviously in my practice, I have been able to get by on very
> simple models with the html element as not different to the
> viewport much (at least the bit of it that is not holding the
> head). I have operated on a sort of "Headless Chook" model (body
> being the important bit) to date and it has served me well. But I
> have tastes in the non-practical areas of life and to these I
> will turn my attention as I get time. <g>

The viewport is basically the browser window (or the edge of a
frame/iframe) and it has a size which the user sets.

Behind the viewport, as it were, is the canvas. The canvas is often
bigger than the viewport, but you can move it around behind the viewport
by scrolling, so you can see different bits of it through the viewport.

On top of the canvas is the root element. Inside the root element is
body, and all the other elements are inside body. The root element and
everything below it all get widths and heights according to the proper
CSS rules, with the viewport width as the width of the "initial
containing block".

So since width is auto by default, they all start off the same width as
the viewport, minus the horizontal borders/padding/margin of their
ancestors. Everything flows into the width available to it, usually not
taking up more width, but dropping down if it needs to. Of course
sometimes things will take up more width-- when authors have explicitly
set widths, or written lines that are too long to break into the space,
etc. Often things take up more height.

So often you end up with the root element and all its descendents taking
up a larger-than-viewport-sized region of the canvas. If this has
happened, you get to scroll (usually).

The root element's background is thought of as painted onto the canvas,
not onto the root element's padding box (where it would normally go). It
extends infinitely (or at least as far as you can scroll). This is so
that when you scroll, the root element's background moves with its
contents and doesn't run out.

dorayme schrieb:

Thank you all for the discussion

> <http://netweaver.com.au/floatHouse>

This page is very helpful for that.
another question to your example page 10 fig 3:

Is there a possibility to get a flow around position:absolute elements?
if you add *position:absolute; top:0px; left:10px;* to

<div style="float:right; width: 200px; border-left: 1px solid #000;
background: #cfc; padding: 0 5px 5px 5px;">


Regards Knut

On 2008-03-15, Knut Krueger <> wrote:
> dorayme schrieb:
>
> Thank you all for the discussion
>
>> <http://netweaver.com.au/floatHouse>
>
> This page is very helpful for that.
> another question to your example page 10 fig 3:
>
> Is there a possibility to get a flow around position:absolute elements?
> if you add *position:absolute; top:0px; left:10px;* to
>
><div style="float:right; width: 200px; border-left: 1px solid #000;
> background: #cfc; padding: 0 5px 5px 5px;">

No. As soon as it's position: absolute it's no longer a float and text
won't flow around it any more.

You can give it margin-left: 10px if you want to push it 10px to the
right.

In article <>,
Ben C <> wrote:

> On 2008-03-13, dorayme <> wrote:
> > In article <>,
> > Ben C <> wrote:
> >
> >> On 2008-03-11, dorayme <> wrote:
> >> > In article <>,
> >> > Ben C <> wrote:
> >> >
....
>
> The key point to consider is this: if you put a background image
> (something anisotropic, like an actual picture, not just a solid colour)
> on the body element, and then scroll the page, the image moves as the
> page scrolls.
>
> That is what browsers have been doing since before the days of CSS, but
> it's actually very weird behaviour and there's no way to get that
> behaviour with CSS except on the root element with the special rules for
> the root element.
>
> The reason is that the region that that image is tiling is not the
> padding box of any particular element: it's the bounding box of the root
> element and all its descendents. That's the so-called "canvas". For
> every other element, you can only put backgrounds on padding boxes.
>
> Put a background image on a div with overflow: scroll and there's no
> way you can make the image move when the div scrolls.
>
> > I am resisting impudently suggesting models I have had in mind
> > until I see a bit more what the models have to account for.
> >
....
>
> The viewport is basically the browser window (or the edge of a
> frame/iframe) and it has a size which the user sets.
>
> Behind the viewport, as it were, is the canvas. The canvas is often
> bigger than the viewport, but you can move it around behind the viewport
> by scrolling, so you can see different bits of it through the viewport.
>
> On top of the canvas is the root element. Inside the root element is
> body, and all the other elements are inside body. The root element and
> everything below it all get widths and heights according to the proper
> CSS rules, with the viewport width as the width of the "initial
> containing block".
>
> So since width is auto by default, they all start off the same width as
> the viewport, minus the horizontal borders/padding/margin of their
> ancestors. Everything flows into the width available to it, usually not
> taking up more width, but dropping down if it needs to. Of course
> sometimes things will take up more width-- when authors have explicitly
> set widths, or written lines that are too long to break into the space,
> etc. Often things take up more height.
>
> So often you end up with the root element and all its descendents taking
> up a larger-than-viewport-sized region of the canvas. If this has
> happened, you get to scroll (usually).
>
> The root element's background is thought of as painted onto the canvas,
> not onto the root element's padding box (where it would normally go). It
> extends infinitely (or at least as far as you can scroll). This is so
> that when you scroll, the root element's background moves with its
> contents and doesn't run out.

Ben C, I quote above to remind you. I have decided over Easter to
look into these matters a bit more. Under the general title of
Root Theory. I have read what you have said to me carefully and I
come back to them now and then with new ways of seeing them.

I make the following acceptances unconditionally.

1. I have decided finally to accept the canvas as a working
hypothesis. It makes life easier.

2. I accept the viewport. I am even happy for it to be an object
with special properties in Root Theory.

3. I accept the html element as real.

Up to now, I have never fully believed in the latter. I have just
played along with it as something that one must be seen in public
to have as a container for the body and the head of an html
document. But I always have had my fingers crossed behind my back
when employing it. I still have little clue about its real
function, why the practical website author ever needs to style it
or do anything but mumble the words at the top and bottom of the
docs and otherwise forget about it. I do know that every now and
then you can get a few things done by including some styling for
it but my memory of this is it is usually to address various
oddities about particular browsers.

I now can let your post go from my newsreader. (You have no idea
how hard it is to hold and recover stuff in MT-Newswatcher).

I will advise of my ruminations in Root Theory as I have
something important to show. Please hold your breath.

--
dorayme

On 2008-03-21, dorayme <> wrote:
[...]
> 3. I accept the html element as real.

The html element is definitely real-- try

html { border: 10px solid green }
body { border: 10px solid red }

and you will see they are both block boxes like any other.

In article <>,
Ben C <> wrote:

> On 2008-03-21, dorayme <> wrote:
> [...]
> > 3. I accept the html element as real.
>
> The html element is definitely real-- try
>
> html { border: 10px solid green }
> body { border: 10px solid red }
>
> and you will see they are both block boxes like any other.

Hi Ben, perhaps you don't know that I did not accept it blindly.
Much as I trust you. <g>

As I said, I read you carefully. But I checked out a few things
too and there is a whole world of absurdity to be explored. Not
only does this root element have borders but other things too.
Did you know that it is a victim of crime in certain circumstance?

The html can have a fixed, yes fixed, background image for a
fraction of a second before it is stolen by the canvas.

That is *one* of the reasons I have come to believe in the
reality of the canvas, I need a culprit, a perpetrator for the
crime of stealing. And the canvas is it. As every detective
knows, you can't have a crime, a thief and a victim without these
things being real.

I have captured on film this act with my HTML camera. Here is a
case (in some browsers) of the html being given (yes, I know,
against the recommendations in CSS 2.1) a fixed non repeating
background image which is then grabbed by the canvas and parked
at a coordinate point on the canvas (0,0) determined by the
viewport. Quicker than the eye can see but not quicker than the
camera as slowed down in playback.

Because you are seeing this out of context, please note that the
black dotted bordered object is the html, the red is the body and
the top left of the yellow is the top left corner of the viewport
in my Firefox.

<http://netweaver.com.au/alt/rootStudies/imageTheft.html>

I am sure you will not be too surprised that the view of this
across different browsers is not the same.

This is one of the illustrations in my up and coming tome in Root
Studies. I just know that all of you will be tempted to send me
$10 to to get advanced copies - but please don't. It is not
finished yet and you won't get it that cheap anyway. <g>

--
dorayme

On 2008-03-21, dorayme <> wrote:
> In article <>,
> Ben C <> wrote:
>
>> On 2008-03-21, dorayme <> wrote:
>> [...]
>> > 3. I accept the html element as real.
>>
>> The html element is definitely real-- try
>>
>> html { border: 10px solid green }
>> body { border: 10px solid red }
>>
>> and you will see they are both block boxes like any other.
>
> Hi Ben, perhaps you don't know that I did not accept it blindly.
> Much as I trust you. <g>
>
> As I said, I read you carefully. But I checked out a few things
> too and there is a whole world of absurdity to be explored. Not
> only does this root element have borders but other things too.
> Did you know that it is a victim of crime in certain circumstance?
>
> The html can have a fixed, yes fixed, background image for a
> fraction of a second before it is stolen by the canvas.
>
> That is *one* of the reasons I have come to believe in the
> reality of the canvas, I need a culprit, a perpetrator for the
> crime of stealing. And the canvas is it. As every detective
> knows, you can't have a crime, a thief and a victim without these
> things being real.
>
> I have captured on film this act with my HTML camera. Here is a
> case (in some browsers) of the html being given (yes, I know,
> against the recommendations in CSS 2.1) a fixed non repeating
> background image which is then grabbed by the canvas and parked
> at a coordinate point on the canvas (0,0) determined by the
> viewport. Quicker than the eye can see but not quicker than the
> camera as slowed down in playback.
>
> Because you are seeing this out of context, please note that the
> black dotted bordered object is the html, the red is the body and
> the top left of the yellow is the top left corner of the viewport
> in my Firefox.
>
><http://netweaver.com.au/alt/rootStudies/imageTheft.html>

You could say that the viewport is stealing the image there, not the
canvas.

Try a background image on a div with background-attachment: fixed, and
you may see the same behaviour. The reason is that all fixed backgrounds
start at the top left of the viewport, not at the top left of the
element. This seems to be related to that rather than to the odd
scrolling behaviour of the root element background which is what gives
rise to the idea of a canvas.

The only reason to say that a background is on the canvas rather than on
the root element is to explain how it scrolls with the root element when
background-attachment is scroll. If it weren't for that behaviour, the
spec could easily do without the idea of a canvas at all, and just say
that the root element background is applied to the viewport.

In article <>,
Ben C <> wrote:

> On 2008-03-21, dorayme <> wrote:
> > In article <>,
> > Ben C <> wrote:
> >
> >> On 2008-03-21, dorayme <> wrote:
....
> >
> > Because you are seeing this out of context, please note that the
> > black dotted bordered object is the html, the red is the body and
> > the top left of the yellow is the top left corner of the viewport
> > in my Firefox.
> >
> ><http://netweaver.com.au/alt/rootStudies/imageTheft.html>
>
> You could say that the viewport is stealing the image there, not the
> canvas.
>

Yes, I was operating on this simple idea but rejected it for certain
reasons, meaning that the viewport would make not the same sense when
other considerations were taken into account.

(I had to tear myself away from these deep and crucial reflections to
nick down the lovely South Coast for a day or two over Easter but am
back on the job now... <g>).

I am thinking of the canvas as infinite, as 2-D, and as having
coordinate points set by the viewport. The coordinates are a reference
that is contributed by the accidental placing of the viewport, "0,0"
being where the viewport's top left corner peers onto it at the start of
any browsing session on the particular webpage concerned.

Infinite is fine by me, but there are ways to navigate this vast land of
a thing and the way is to have the view port mark the 0,0 point. I have
done experiments and devoted huge processing resources to them and have
always been able to manage to get back to 0,0 by scrolling and page ups
and down keys and such. <g>

I will try to have something as soon as I can.

May I be perfectly frank with you? In my own practice I do not dimension
the html, I pretty well ignore the thing. I never even (any more) give
dimensions or borders to body. And I have actually been wondering
something: what practical difference would it make to standards
compliant browsers if the standards never allowed such things in the
first place? You could not touch the html for anything at all, it is
there to be a root and to hold the head and the body but is not css
renderable in any shape or form.

Ditto body in respect to any dimensioning of its size. Not even borders
allowed. What would the practical author ever have lost?

> Try a background image on a div with background-attachment: fixed, and
> you may see the same behaviour. The reason is that all fixed backgrounds
> start at the top left of the viewport, not at the top left of the
> element. This seems to be related to that rather than to the odd
> scrolling behaviour of the root element background which is what gives
> rise to the idea of a canvas.
>
> The only reason to say that a background is on the canvas rather than on
> the root element is to explain how it scrolls with the root element when
> background-attachment is scroll. If it weren't for that behaviour, the
> spec could easily do without the idea of a canvas at all, and just say
> that the root element background is applied to the viewport.


I think this is pretty well the conclusion I have reached and why (I
think you may have said this before and it was just further confirmed in
my head...)

--
dorayme