Re: Overflow and Margins

On Feb 4, 2008, at 1:24 PM, Ben Cotterell wrote:

>
> On Mon, Feb 04, 2008 at 10:00:17AM -0800, Brad Kemper wrote:
>>
>> On Feb 4, 2008, at 8:48 AM, Ben Cotterell wrote:
> [...]
>>>> <div style="width:400px; overflow:auto">
>>>> 	<div style="width:800px; margin:50px;">
>>>> 		<div style="1000px;"></div>
>>>> 	</div>
>>>> </div>
>>>>
>>>> Even in this case, I would prefer to see room for the margin in the
>>>> extent box, as though that were a separate viewport. Even if the
>>>> current rules don't allow it, I think most designers would  
>>>> expect to
>>>> see their specified margins and not understand why they are not
>>>> there. Even with all of your patient explanation, I am still  
>>>> having a
>>>> difficult time fully grasping why they are not all shown,  
>>>> although I
>>>> understand it has something to do with the interpretation of the
>>>> rules for over-constrained blocks.
>>>
>>> The difficulty here is what is the used value of the block's
>>> right margin? (This is the 800px wide box I'm talking about).
>>>
>>> The width available to it is 400px. Its own width is 800px. So it  
>>> ends
>>> up with a used right margin of -450px, not of 50px.
>>
>> By my figuring the used right margin would be -400px (the 50px is
>> ignored, and refigured to allow its used width to be equal to its
>> parent), but maybe I am missing something.
>
> Its left margin is also 50px. So you've got:

Oh, you're right. I wasn't thinking of the left margin.

>
>     50 + 800 + margin-right = 400
>     margin-right            = 400 - 800 - 50
>     margin-right            = -450
>
> That's how I figure it, but I may have made a mistake somewhere.  
> You get
> the idea anyway.
>
>> But the purpose of that huge negative margin is so that it will not
>> impact items outside of the scrollbox. There is no practical reason
>> why that negative margin should similarly impact the size of the
>> extent box. And, it seems to me, it does not impact the size of the
>> extent box.
>>
>> If it did, the extent box would only be 400px wide. In
>> reality, in my testing, the extent box if big enough to fit even the
>> 1000px object.
>
> Correct, but the point is it's not 50px any more. It's negative and
> treated as 0 in this context.

But only because we say so in the spec, and specs can change.

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

> In this case the computed value is 50px, so it's easy to say the  
> browser
> should just use 50px. But what if it's a percentage? Percentage of
> what-- the original containing width or the extent box width?
>
> 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.

>
>>> Now when the browser comes to compute the extent box for  
>>> scrolling the
>>> outermost div, it's got a -450px gap to work with at the right,  
>>> not a
>>> 50px one. It's not obvious how to re-specify this to get the desired
>>> 50px margin. 10.3.* is all based firmly on the idea that you are
>>> working
>>> to some containing width that you know in advance.
>>
>> I would specify it as:
>>
>> If all of the above have a computed value other than 'auto', the
>> values are said to be "over-constrained" and one of the used values
>> will have to be different from its computed value. If the 'direction'
>> property of the containing block has the value 'ltr', the specified
>> value of 'margin-right' is ignored and the value is calculated so as
>> to make the equality true. If the value of 'direction' is 'rtl', this
>> happens to 'margin-left' instead.
>>
>> For the purposes of determining the width of the extent planes within
>> a scrolling box, the equality restriction no longer applies, as the
>> extent box has no restrictions on its width.
>
> If the equality restriction doesn't apply, how do you do centering?

I'm not sure I understand the concern. After the extent plane is  
sized, then the contents are layout out within it as though that was  
the fixed document (body) width and there was nothing else in the  
document but those contents, and you were looking at the document  
through a smaller window.

>
>> In this case, the  original value of the margin applies within (and
>> only within) that  extent box.
>
> 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. Widths  
of "auto" are based on the viewable width of the "window", that is,  
the constraining container box.

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.

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

Received on Tuesday, 5 February 2008 05:07:39 UTC