Ben Rogers wrote:
>>Yup, it is, but that's not a problem with the box model--that is, the
>>way the width, height, padding areas, borders, and margins interact with
>>one another--but how the spec says heights should be calculated.
>
> Here's where we disagree. I think that sizing in the box model is
> fundamentally flawed when using relative positioning. Specifically, I would
> have preferred to see relatively positioned elements sized based on the
> space available -- as is the case with HTML.
No, I think we actually agree, it's just that we're misunderstanding one
another. I'd better explain what I'm talking about. Roll on ASCII art!
The box model specifies the elements of a box, and how its dimensions
should be specified. The W3C box model is:
/|\
m
\|/
+---------------------------------------+
|################# /|\ #################|
|################## b ##################|
|################# \|/ #################|
|#######+-----------------------+#######|
|#######| /|\ |#######|
|#######| p |#######|
|#######| \|/ |#######|
|#######| +-------+ ---------------------------
| ##### | | | | ##### | /|\
<- m ->|<- b ->|<- p ->|<- w ->|<- p ->|<- b ->|<- m -> h
| ##### | | | | ##### | \|/
|#######| +-------+ ---------------------------
|#######| /|\ |#######|
|#######| p |#######|
|#######| \|/ |#######|
|#######+-----------------------+#######|
|################# /|\ #################|
|################## b ##################|
|################# \|/ #################|
+---------------------------------------+
/|\
m
\|/
Whereas the MS box model is:
/|\
m
\|/
+---------------------------------------+ -----------
|################# /|\ #################| /|\
|################## b ##################| |
|################# \|/ #################| |
|#######+-----------------------+#######| |
|#######| /|\ |#######| |
|#######| p |#######| |
|#######| \|/ |#######| |
|#######| +-------+ |#######| |
| ##### | | | | ##### | |
<- m ->|<- b ->|<- p ->| |<- p ->|<- b ->|<- m -> h
| ##### | | | | ##### | |
|#######| +-------+ |#######| |
|#######| /|\ |#######| |
|#######| p |#######| |
|#######| \|/ |#######| |
|#######+-----------------------+#######| |
|################# /|\ #################| |
|################## b ##################| |
|################# \|/ #################| \|/
+---------------------------------------+ -----------
| /|\ |
| m |
| \|/ |
| |
|<----------------- w ----------------->|
Abbreviations:
m = margin
b = border
p = padding
w = width
h = height
And that's it. It specifies nothing else. The only difference between
the W3C box model and the MS one is that in the MS one, the border and
padding are taken as part of the width/height whereas they're not in the
W3C one. Both are not competely equivalent, and sometimes one is more
convenient than the other, but that's why there's a CSS-3 attribute that
lets you select which you want the element in question to use.
Now, the matter of whether a height of 100% should specify that the box
should take up the remaining space in an element is a different matter.
That's to do with reflow. Though the way it works might suck, the spec's
not competely wrong in what it says. Examples are in order I think.
Say you've a set of divs as follows:
<div style="height:100px">
<div>Blah!</div>
<div>Blah!</div>
</div>
And say you want the top child div to fill any remaining space, you
might do:
<div style="height:100px">
<div style="height:100%">Blah!</div>
<div>Blah!</div>
</div>
But what if you want the heights evenly distributed between both? Do you
say:
<div style="height:100px">
<div style="height:100%">Blah!</div>
<div style="height:100%">Blah!</div>
</div>
Or:
<div style="height:100px">
<div style="height:50%">Blah!</div>
<div style="height:50%">Blah!</div>
</div>
And what about the case where there's no height on the outer div, what
height should the inner divs be?
<div>
<div style="height:100%">Blah!</div>
<div style="height:100%">Blah!</div>
</div>
The real problem is that CSS needs a way of saying "if my parent has any
free space, give that to me". "auto" means "give me just what I mean",
"100%" means "make me fill my parent", but what we need is a "remaining"
height, so if you specified:
<div style="height:100px">
<div style="height:remaining">Blah!</div>
<div style="height:remaining">Blah!</div>
</div>
The height would be distributed evenly across both. A way to specify the
proportion of the remaining space would be nice too.
BTW, this addition to CSS would solve Isaac's problem as regards sizing.
You see, it's not that the spec is bad, just lacking.
I think I'll turn this into a blog post some time over Christmas!
Cheers!
>>Nah, this doesn't break it, though it might give the impression that it
>>does through my use of pixels. I only did this because the HTML he
>>originally posted up did that.
>
> Really? I'd be interested in seeing an example. It's my understanding that,
> if an element has a size of auto, the height is not calculated until after
> the element is rendered. This means that elements within that element cannot
> be sized relative to the parent. So, I don't understand how you'd accomplish
> this in CSS.
I'd like to see an example of what you mean, using tables if need be to
demonstrate it. I think I might be misunderstanding you.
>>But his problem is perfect for this kind of fixed positioning. I just
>>wish you could specify sizes like 2em+3px, which would help with
>>accessability in a lot of cases. He wants to place things up at the top
>>and bottom of the viewport, with content in two iframes, so positioning
>>everything off the borders of the viewport doesn't actually cause any
>>problems here. The contents of the view ports can still expand, and the
>>content iframe resizes with the containing iframe.
>
> The problem, as I see it, occurs with the second row. What happens to the
> content in that row if the font size were doubled by the client browser?
> Better yet, what happens if the content is dynamic and has to wrap?
If you're using ems, it's height will expand. However, and this applies
to any kind of layout system that doesn't allow you to specify
constraints based on the interrelationship between adjacent elements, if
the line wraps, you're screwed. Ems will take care of size increases for
the most part, but not, unfortunately, linewrapping.
> You can clip it or scroll it using CSS. However, I don't believe there's a
> way to dynamically size it so that the row with iframes will always start
> immediately below the second row, regardless of how large the second row is.
>
> I'd love to be proven wrong.
Nope, with positioning, you can't do that. There's no way to specify the
constraints.
>>Yup, that being the viewport, making it a positioning issue.
>
> In this case, the available content area happens to be the view port.
No, the viewport's just that: a view of the page. The only aspect of the
viewport that ought to impact on the page is its width. The available
content area is the page itself.
[Sidenote: Yes, I know if taken literally, that would mean that
backgrounds and borders on the body would only apply to the section
displayed with content on it, but just take that as a special case;
the body element's a bit odd anyway.]
> However, in most cases, I don't believe it is. For instance, I'm working on
> a design right now in which I'm floating the logo to the left and would like
> to center the company name between the logo and the right hand side of the
> page. Fixed positioning does not solve the problem in this context.
No, but there's ways of doing it. If you show me what you're trying to
do, I could probably come up with a solution.
>>Nope, it supports relative (albeit in a slightly broken, but hackable
>>manner) and absolute positioning.
>
> Yeah, I misspoke on this. I reversed fixed and absolute as I was looking
> through your code.
'sok.
>> With the IE7 JS hacks it is: http://dean.edwards.name/IE7/
>
> I had ignored the IE7 project because I thought it was a collection of
> hacks. Looking at it now, I see that it's using JavaScript to parse and
> render the CSS. I'm not as adverse to this as some of the hacks I've seen
> out there. I might have to look into it more.
A set of hacks it is, but quite neatly seperated from the HTML it
operates on. These kinds of hacks are a Good Thing, and a fine example
of how JS *should* be used. It's worth a look even if you never use it
yourself.
>>I don't think it's unfortunate really, I think that's just what the
>>solution calls for, and that's part of what fixed positioning is there
>>for in the first place.
>
> Well, assuming that you can accomplish the same effect as your earlier code
> without the use of exact pixel sizes, content clipping or scrolling, then
> I'd have to agree. Short of this, I think it's a bloody shame.
Almost. It does everything except expand the height of the "ladder" (a
breadcrumb trail?) if it breaks onto two or more lines. Other than that,
it works perfectly.
--
Keith Gaughan, Developer
Digital Crew Ltd., Pembroke House, Pembroke Street, Cork, Ireland
http://digital-crew.com/
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.2 - Release Date: 20/12/2004
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net
http://www.cfhosting.net
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188488
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
