Re: Overflow and Margins

On Mon, Feb 04, 2008 at 09:07:24PM -0800, Brad Kemper wrote:
> 
> On Feb 4, 2008, at 1:24 PM, Ben Cotterell wrote:
[...]
> >>Since the contents of the extent box are all self contained, the
> >>original value of the margin should be used in determining its size.
> >
> >But which original value? The browser needs a _used value_ to actually
> >apply and it has to work out that used value with respect to a
> >containing width.
> 
> The value of what would be used if the container's constraint did not  
> exist.

I mean the browser can only work out a used value with reference to
some kind of available width value.

Extent-box width ("hypothetical shrink-to-fit width" is possibly how it
would be worded) or containing block width are theoretically both
options.

But I think the latter (what you always get at the moment) is much more
often preferable.

Suppose someone puts a rather wide banner or image near the top of their
page. Currently what happens is the banner overflows to the side of the
body box if the user's viewport is too narrow, but the main page
contents still flow into the containing width for body, which is based
on the viewport width they are actually using. Centering and percentages
are also relative to the containing block established by body, not to
its extent box.

This is usually better than stretching the whole page sideways just
because a bit of it overflows. It's one thing to scroll to the right a
bit to see the end of an oversized image, another to have to keep
scrolling left and right to read lines of text, or to have things
centered in a box you can't see.

The same goes for percentages. Often authors use percentage widths and
margins to divide the page up into pleasingly proportioned columns.
Those therefore want to be percentages of the bit you can see.

Most things are better fitted into the width you can see, not into the
extent width, and it's generally better to design pages in such a way
that horizontal scrolling is minimized.

Occasionally authors do want things fitted into extent widths, but they
can do that already with an extra shrink-to-fit wrapper.

[...]
> >And what if margin-right and margin-left are both auto? How does the
> >browser decide whether the author wants the border box centered in the
> >real containing width or in the extent width?
> 
> That's a good question. I think it would have to be a percentage of  
> the real containing width, so that it would be constant.

This seems to contradict what you're saying below.

[...]
> >You would also have to explain what the browser is supposed to do  
> >if the
> >original value is a percentage or auto.
> 
> Yes. Oh, you mean me personally? I suppose I could do that, and you  
> could tell me if you think I should change my mind:
> 
> Any percentage values are based on the fully expanded extent box, and  
> not on the original dimensions of the constraining container.

Here you're saying percentages are of the extent box, not of the real
containing width.

> Widths  of "auto" are based on the viewable width of the "window",
> that is,  the constraining container box.

You seem to be going for a kind of hybrid solution, where for some
purposes (auto widths) the containing width is used. For others (auto
margins, and possibly percentage widths and margins, although I may have
misunderstood the details) the extent width is used.

> I'm not married to this last point of view, but I would want it to be  
> as similar to what already exists, aside from the dis-inclusion of  
> the specified margins and padding.

I just don't think a hybrid solution is feasible at all.

> >>or something like that.
> >
> >I think the width calculation rules are complicated enough already
> >without also depending on the container's overflow property.
> 
> >
> You are entitled to your opinion. I do not share it. I would rather  
> it be intuitive to the author, even if it complicates the  
> calculations that the programmer puts into the software.

It's not the programmer I'm concerned about here. Programming
complicated calculations is not too hard. One wants a specification that
authors can understand and that does what they want.

Here there are two different requirements.

In summary, much of 10.3.* is about fitting blocks into the space
available, especially the rules for auto and percentage widths and
margins.

Currently the space available is consistently defined as the containing
block width. If it were defined instead as the extent width, that would
sometimes, but certainly not always, be desirable.

The author needs a choice. Currently he does: he can use extra
shrink-to-fit wrappers when he needs the special fitting-to-extent-box
behaviour.

This does mean using a couple of extra divs. One alternative would be
more CSS properties. Not an alternative I personally favour, but one
could make a case for it.

But changing the rules without any way for the author to say which
containing width he wants and when I don't think is going to be
successful.

Received on Tuesday, 5 February 2008 08:38:43 UTC