RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

> I read that, and I know that issue, but I can't fathom myself where
> you'd take the extra height from if this rule wasn't there: the parent's
> parent, and if so, how much would you take, and what would the extra
> height be calculated relative to.

The easiest answer to that question is another question: where does the
space come from in HTML? As I understand it, the browser traverses up the
tree until it finds an element whose height it knows. As a result, it's more
complicated to render HTML than CSS. It's my understanding that this is the
reason why the spec doesn't allow for it: to keep rendering simple.

At a fundamental level, I think the folks who made the CSS spec made a bad
decision: I think you should make things easier on the people who use a
computer. The computer is there to serve the people after all. On a
practical level, the time it takes to render even a complex layout of nested
tables is trivial (well, it is in anything other than Netscape 4). Even if
this wasn't the case, Moore's law would have long since made it so.

> Went up to my retreat deep in the Ox Mountains and meditated on a
> solution. Then, just as it came to me in a flash of blinding light, I
> remembered somebody'd already solved this particular problem before:
> 
>  http://www.redmelon.net/tstme/3cols2/

That's a great example. That's far better than any I found (I must of looked
at 50 different examples before sending my last message). Nevertheless, it
still suffers from some of the issues we've been talking about.

Specifically, the widths of the left and right columns are specified in
several locations. They are specified as the border for the outer class
(similar to how margin was used in the example I posted). They are also
specified in negative margin values for the left and right columns
themselves.

The latter doesn't bother me so much because the left column already needs
to know its size. So, specifying the size as a width and negative margin
value isn't too bad. However, having to make other elements cognoscente of
the column's size is a more serious violation of the principle of
orthogonality. Nevertheless, it goes a long way towards mitigating those
issues.

There are also a few extra divs and classes in there (most notably the
separation between inner and outer). That's not a big deal since the tr's
and td's in the table example even that out. The style sheet code makes
their example at least 3 times as long as the one I posted (I actually
rewrote their example with as little code as possible before posting just so
I would better understand it), but it goes a long way towards separating
presentation from content.

All in all, that's a pretty good example. I still think CSS is screwy in
this regard, but at least there are workarounds.

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057


~|
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:188538
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

Ben Rogers wrote:

>>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!
> 
> 
> Sorry about the confusion. I wasn't referring to how the size of a box is
> calculated in either the W3C box model or the pre-Internet Explorer 6 box
> model. Nevertheless, that ASCII art was pretty impressive!
> 
> I'm not sure that there is a specific term for what we're talking about.
> Here's the situation though...
> 
> When you specify a relative size (50%) for a block element in CSS, the size
> is calculated based the total size of the containing block. If the container
> is set to auto, then the size of the container is unknown until the
> container has been completely rendered. In such situations, the relative
> size is ignored, defaulting instead to auto. This means that you have to
> know the size of all the box elements in the hierarchy to specify a relative
> size on one.
> 
> You can read more about this behavior here:
> 
>   http://www.quirksmode.org/css/100percheight.html
> 
>   "The spec says: 'If the height of the containing block is
>not specified explicitly (i.e., it depends on content
>height), the value is interpreted like "auto".'
>
>This means that if you do not define any height at all
>for the containing block, a percentual height of any
>contained block doesn't work: the block becomes once
>again exactly as high as it needs to be.
> 
>Even though this rule may in a few cases save the browser
>work in calculating the correct heights of elements, I
>still think that it is far too restrictive and it's
>caused by bad thinking on the part of the standard makers
>and the browser vendors. Counter-intuitive and
>unnecessary rules like this one make our beautiful CSS
>too hard to work with."
> 
> Anyway, that's problem number one.

I read that, and I know that issue, but I can't fathom myself where
you'd take the extra height from if this rule wasn't there: the parent's
parent, and if so, how much would you take, and what would the extra
height be calculated relative to.

I think, regardless of the solution, somebody've been dissatisfied.

> To further complicate things, relative
> sizes are calculated based on the size of the containing block. This means
> that you have to know the size and width of all the elements within the
> containing block (all of the adjacent blocks) when specifying the relative
> size of an element.
> 
> For example, I've found that trying to approximate the following layout in
> CSS is very difficult.



> In addition, each element has (or can have) it's own background color
> specified at the element level. Mostly, I just included the background
> colors to highlight the fact that each element lines up with one another
> regardless in the different content sizes (which I'm artificially
> controlling with the divs).

Went up to my retreat deep in the Ox Mountains and meditated on a
solution. Then, just as it came to me in a flash of blinding light, I
remembered somebody'd already solved this particular problem before:

 http://www.redmelon.net/tstme/3cols2/

>>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:
> 
> Heh, I thought that's what this entire thread has been about. I'm not sure
> where the IE vs. W3C box model came from, but the whole point I've been
> trying to make is that you can't specify the size of a block relative to the
> available content area.

Because Isaac was complaining about the box model, and I was trying to
tell him that his problems weren't with the box model.

>>
>>Blah!
>>Blah!
>>
> 
> I don't think it should be implemented this way because I want to be able to
> specify percentages of the "remaining" content area. If, in HTML, I
> specified width="50%" on a table, it would take 50% of the "remaining" area
> or what I've been referring to as the "available content area".

Ah, but I was only giving the simplest implementation. In addition, you 
might do something like this:


 Blah!
 Blah!


In this case, the outer div would expand to take up as much of the
remaining height as it could, with the first child taking up 2 units
(2/7) of it's space (the parent having 2 + 5 = 7 units), and the second
taking 5.

"remaining" means the same thing as "remaining(1)", if you haven't 
already guessed.

This isn't as redundant as it sounds. You see, you can consider it a
"softer" version of the percentages. Whereas 100% and 50% are just that,
the "remaining" value just gives you the remaining space if it can.
Example:

  +

~|
Special thanks to the CF Community Suite Silver Sponsor - RUWebby
http://www.ruwebby.com

Message: http://www.houseoff

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

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

Sorry about the confusion. I wasn't referring to how the size of a box is
calculated in either the W3C box model or the pre-Internet Explorer 6 box
model. Nevertheless, that ASCII art was pretty impressive!

I'm not sure that there is a specific term for what we're talking about.
Here's the situation though...

When you specify a relative size (50%) for a block element in CSS, the size
is calculated based the total size of the containing block. If the container
is set to auto, then the size of the container is unknown until the
container has been completely rendered. In such situations, the relative
size is ignored, defaulting instead to auto. This means that you have to
know the size of all the box elements in the hierarchy to specify a relative
size on one.

You can read more about this behavior here:

  http://www.quirksmode.org/css/100percheight.html

  "The spec says: 'If the height of the containing block is
   not specified explicitly (i.e., it depends on content
   height), the value is interpreted like "auto".'
   
   This means that if you do not define any height at all
   for the containing block, a percentual height of any
   contained block doesn't work: the block becomes once
   again exactly as high as it needs to be.

   Even though this rule may in a few cases save the browser
   work in calculating the correct heights of elements, I
   still think that it is far too restrictive and it's
   caused by bad thinking on the part of the standard makers
   and the browser vendors. Counter-intuitive and
   unnecessary rules like this one make our beautiful CSS
   too hard to work with."

Anyway, that's problem number one. To further complicate things, relative
sizes are calculated based on the size of the containing block. This means
that you have to know the size and width of all the elements within the
containing block (all of the adjacent blocks) when specifying the relative
size of an element.

For example, I've found that trying to approximate the following layout in
CSS is very difficult:










header





left column


center column



right column




footer







The layout has the following properties:

  - A header which spans all three columns and has a
liquid height and liquid width
  - A right column with a liquid height and fixed width.
  - A center column with a liquid height and liquid width.
  - A left column with a liquid height and fixed width.
  - A footer which spans all three columns and has a
Liquid height and liquid width.

In addition, each element has (or can have) it's own background color
specified at the element level. Mostly, I just included the background
colors to highlight the fact that each element lines up with one another
regardless in the different content sizes (which I'm artificially
controlling with the divs).

The closest thing I've found is this page:

  http://www.positioniseverything.net/guests/3colcomplex.html

They fudge the center column by giving it margins equal to the width of the
left and right columns. They don't include a liquid footer that expands
across all three columns. In addition, they had to rely on some common
tricks to give the left and right columns a background color. Specifically,
the left column is given a transparent background color, inheriting the
background from the body element. The right most column uses a repeating
background image.

> The box model specifies the elements of a box, and how its dimensions
> should be specified. The W3C box model is:

Here's a link to save you from typing so much in the future. :)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html
/cssenhancements.asp

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

Heh, I thought that's what this entire thread has been ab

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

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:


Blah!
Blah!


And say you want the top child div to fill any remaining space, you
might do:


Blah!
Blah!


But what if you want the heights evenly distributed between both? Do you
say:


Blah!
Blah!


Or:


Blah!
Blah!


And what about the case where there's no height on the outer div, what 
height should the inner divs be?


Blah!
Blah!


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 

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[S . Isaac Dealey]

> I had a similar problem with height not working when
> specified at
> 100%.  Turned out being the dtd definition.  If you
> specify a dtd,
> without the height attribute, it won't work.  Try simply
> excluding the
> dtd definition in your doctype def:

>  Transitional//EN">

> Not:

>  Transitional//EN"
> "http://www.w3.org/TR/html4/loose.dtd";>

Well ... leaving out the URI to the .dtd ont he w3c site causes what
everyone refers to as "quirks mode" meaning essentially that when
given the first DTD each browser will interpret the page in its own
"special" way. Hence the desire to use the latter format for the DTD
which encourages the browser to adhere to the w3c standards for the
given document type (in this case html, but sometimes also xhtml).


s. isaac dealey   954.927.5117
new epoch : isn't it time for a change?

add features without fixtures with
the onTap open source framework

http://macromedia.breezecentral.com/p49777853/
http://www.sys-con.com/story/?storyid=44477&DE=1
http://www.sys-con.com/story/?storyid=45569&DE=1
http://www.fusiontap.com




~|
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:188481
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

Leaving out the URL invokes quirks mode in most modern browsers. That's OK
as long as it solves your problem. However, it doesn't solve the problem in
standards mode because the standard simply doesn't support relative sizing
based on the available content area.

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057

> -Original Message-
> From: Ryan Emerle [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 21, 2004 4:34 PM
> To: CF-Talk
> Subject: Re: css - height 100% - i'd like to kill the crack-addicts who
> wrote the w3c box model
> 
> I had a similar problem with height not working when specified at
> 100%.  Turned out being the dtd definition.  If you specify a dtd,
> without the height attribute, it won't work.  Try simply excluding the
> dtd definition in your doctype def:
> 
> 
> 
> Not:
> 
>  "http://www.w3.org/TR/html4/loose.dtd";>
> 
> HTH
> -Ryan
> 
> 
> On Thu, 16 Dec 2004 00:26:33 -0500, S. Isaac Dealey <[EMAIL PROTECTED]>
> wrote:
> > so after all this time, there's still no standard that allows an
> > adequate means of specifying something as simple as height 100% ...
> > because according to the w3c, 100% of the height of an airplane
> > discludes its canopy and landing gear and 100% of its length discludes
> > its propeller and tail-fins...
> >
> > Before you say it -- yes, I've assigned margin: 0; padding: 0; height:
> > 100% on both the html and the body elements in the style sheet...
> >
> > And in this code there is no way to make the content of the 3rd table
> > row display without specifying a height for the row -- there is also
> > no way to tell the browser that the row should be 100% of the
> > _remaining_ height of the table after accounting for the space taken
> > by the other 3 rows (above and below). So my choices are 80% (so the
> > bottom of the table may or may not match the bottom of the window) or
> > a fixed height (so the bottom of the table definately doesn't match
> > the bottom of the dinwo most of the time). Any attempt to set the
> > height of the 3rd row to 100% results in the table exceeding the
> > height of the browser window.
> >
> > And why use tables at all you ask? Because there's no way to specify
> > the iframes float left and right and fill 100% of the width of the
> > window without one of them being shoved down underneath the other if
> > the browser window is shrunk horizontally.
> >
> > Oh well... frameset it is I guess... Doesn't make me any happier with
> > the box model.
> >
> > 
> > 
> >  > style="height:40px;">onTap Framework
> >  > style="height:20px;">Home
> > 
> > 
> > 
> >  cellspacing="0"
> > style="height:100%; width: 100%;">
> > 
> > 
> >  name="nav_frame_menu" frameborder="1" height="100%"
> > width="250">
> > 
> > 
> >  name="nav_frame_content" frameborder="1" height="100%"
> > width="100%">
> > 
> > 
> > 
> > 
> > 
> > 
> >  > style="height:60px;">
> >  > action="https://www.paypal.com/cgi-bin/webscr";
> method="post"
> > style="margin: 0px;">
> >  />
> >  value="[EMAIL PROTECTED]" />
> >  value="onTap Framework" />
> >  value="ontapframework" />
> > 
> >  value="USD" />
> > 
> >
> >  > type="image" border="0"
> style="border:0px;
> > background-color:transparent; float: left;"
> > alt="Make a donation."
> > src="http://mx/otp/test/_components/docs/_imag

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

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

That said, I'm sure I'm wrong because the rest of the world seems to
disagree with me -- except for maybe Isaac. :)

> Yup, because the problem he wants solved doesn't actually involve
> sizing, but positioning within the viewport.

I guess this depends on how you look at it. If you're switching from HTML to
CSS, CSS seems backwards and overly complex. If you're switching from making
desktop apps to HTML, I'm sure HTML seems awkward.

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

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

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.

> Yup, that being the viewport, making it a positioning issue.

In this case, the available content area happens to be the view port.
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.

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

> Who says that they have to make an official statement to make something
> true? All they have to do is relegate the IE team to making patches for
> security holes in MSHTML. Since IE5.5 and particularly IE6 came out, MS
> have been steadily cutting back the size of the IE dev team back from
> several hundred developers back to just a few tens of them. When gecko
> browsers started to makes inroads into their share, the number of
> developers started to increase quite a bit.
> 
> And I'm only going of what MS devs have told me happened.

I don't personally know anyone at Microsoft, so I'll defer on this. I'm
basing everything off of official announcements and random Microsoft blogs.

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

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

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057


~|
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:188477
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ryan Emerle]

I had a similar problem with height not working when specified at
100%.  Turned out being the dtd definition.  If you specify a dtd,
without the height attribute, it won't work.  Try simply excluding the
dtd definition in your doctype def:



Not:

http://www.w3.org/TR/html4/loose.dtd";>

HTH
-Ryan


On Thu, 16 Dec 2004 00:26:33 -0500, S. Isaac Dealey <[EMAIL PROTECTED]> wrote:
> so after all this time, there's still no standard that allows an
> adequate means of specifying something as simple as height 100% ...
> because according to the w3c, 100% of the height of an airplane
> discludes its canopy and landing gear and 100% of its length discludes
> its propeller and tail-fins...
> 
> Before you say it -- yes, I've assigned margin: 0; padding: 0; height:
> 100% on both the html and the body elements in the style sheet...
> 
> And in this code there is no way to make the content of the 3rd table
> row display without specifying a height for the row -- there is also
> no way to tell the browser that the row should be 100% of the
> _remaining_ height of the table after accounting for the space taken
> by the other 3 rows (above and below). So my choices are 80% (so the
> bottom of the table may or may not match the bottom of the window) or
> a fixed height (so the bottom of the table definately doesn't match
> the bottom of the dinwo most of the time). Any attempt to set the
> height of the 3rd row to 100% results in the table exceeding the
> height of the browser window.
> 
> And why use tables at all you ask? Because there's no way to specify
> the iframes float left and right and fill 100% of the width of the
> window without one of them being shoved down underneath the other if
> the browser window is shrunk horizontally.
> 
> Oh well... frameset it is I guess... Doesn't make me any happier with
> the box model.
> 
> 
> 
>  style="height:40px;">onTap Framework
>  style="height:20px;">Home
> 
> 
> 
>  cellspacing="0"
> style="height:100%; width: 100%;">
> 
> 
>  name="nav_frame_menu" frameborder="1" height="100%"
> width="250">
> 
> 
>  name="nav_frame_content" frameborder="1" height="100%"
> width="100%">
> 
> 
> 
> 
> 
> 
>  style="height:60px;">
>  action="https://www.paypal.com/cgi-bin/webscr"; method="post"
> style="margin: 0px;">
> 
> 
> 
>  value="ontapframework" />
> 
>  />
> 
> 
>  type="image" border="0" style="border:0px;
> background-color:transparent; float: left;"
> alt="Make a donation."
> src="http://mx/otp/test/_components/docs/_images/donations.gif"; />
> 
> 
>  
> href="http://affiliates.macromedia.com/b.asp?id=2549&p=go/dr_home_af
> f1">
>  
> src="http://affiliates.macromedia.com/showb.asp?id=2549&img=mx2004_4
> 68x60_b.gif" />
> 
> 
> 
> s. isaac dealey 954.927.5117
> new epoch : isn't it time for a change?
> 
> add features without fixtures with
> the onTap open source framework
> 
> http://www.sys-con.com/story/?storyid=44477&DE=1
> http://www.sys-con.com/story/?storyid=45569&DE=1
> http://www.fusiontap.com
> 
> 

~|
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:188475
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

Ben Rogers wrote:

>> What I meant by depending is that while such behaviour isn't specified
>> in the spec, it is available in a fair few browsers in their quirks
>> mode, but not in their standards mode.
> 
> I think we're referring to two separate behaviors here. I was referring to
> sizing relative to available area as opposed to the containing block.
> Specifically, I was referring to its absence in standards mode, which I
> think is unfortunate.

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.

>>Well, I was trying to show that he was trying to put in a screw with a
>>hammer rather than a screwdriver: it might kinda work, but it's not the
>>right way, seeing as his problem was really a positioning one rather
>>than
> 
> I see what you're saying. However, I interpreted Isaac's original post as
> blowing off steam. In other words, I think he was lamenting the fact that
> CSS (at any level) does not support sizing relative to the available content
> area. Isaac, let me know if I misunderstood this.
> 
> My question to you is, all other things being equal, do you really think
> that fixed positioning is a better way to solve this problem than relative
> sizing?

Yup, because the problem he wants solved doesn't actually involve
sizing, but positioning within the viewport.

He's got two content frames, both of which have their own

 > One of the great things about HTML is that elements are allowed to
> flow. Users can change their default font and size, disable images, etc.,
> and the page just adapts.
 >
> Fixed positioning in general -- and your proposed solution specifically --
> break this very badly. As a developer, I now have to know the exact pixel
> size of every element on the page and position objects off the
> top/bottom/left/right accordingly. Worse, I have to know these at design
> time as opposed to runtime.

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.

Believe me, I'm a complete nut when it comes this kind of thing. I 
prefer to leave as much up to the client as possible. One of the things
that irks me at work--hi, guys!--is that the other lads go for the whole
I-must-have-complete-control-pixels-pixels-pixels. I don't.

There's not been a layout that I've come across that I haven't been able
to do in a reasonable way with CSS, holly hacks aside for IE, and I'm no
size nazi, far from it.

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.

Don't panic, I wouldn't to anything nasty like that unless I'd a
metaphorical gun to my head.

> I just don't understand how this can be considered an improvement?
> 
>>But what he's trying to do *is* positioning, not sizing.
> 
> Correction, what he's trying to accomplish is sizing relative to the
> available content area.

Yup, that being the viewport, making it a positioning issue.

> The only way to approximate it in CSS 2 compliant
> browsers is to use fixed positioning.

There's two ways of viewing it: you can view the problem as a sizing
issue, but that only leads to pain because he's trying to do sizing
relative to the viewport. But the viewport's never going to overflow
because all the content's in the iframes, so if you look at it from
a positioning point of view, the problem simplifies to almost nothing.

It's a bit like the sorting problem in column one of Programming Pearls:
from one point of view, a problem can seem nigh impossible (doing sizing
being the way this was tackled), but if you know the constraints (that
sizing is being done relative to the size of the viewport, it never
overflows the viewport, and always fills it), the solution becomes
simple (use fixed positioning!).

> To my knowledge, there is no way to
> accomplish it in CSS 1 compliant browsers (sans-html formatting).

Yup, but CSS1 browsers bearly tackly anything more than formatting.

>>I know he's
>>talking about sizing, but what I'm trying to get across is that *his*
>>particular problem isn't with sizing, and not with the differences
>>between the MS and W3C box models.
>>
>>And IE doesn't support fixed positioning, nor has it ever done so.
> 
> Uhg. Yes it does. Internet Explorer 6 supports CSS level 1 fixed
> positioning. Earlier versions of IE also supported it, albeit with the
> broken box model.

Nope, it supports relative (albeit in a slightly broken, but hackable
manner

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

Correction on this. I had a mental lapse between fixed and absolute
positioning. CSS level 1 did not support fixed positioning at all.

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057

> -Original Message-
> From: Ben Rogers [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 21, 2004 2:30 PM
> To: CF-Talk
> Subject: RE: css - height 100% - i'd like to kill the crack-addicts who
> wrote the w3c box model
> 
> > What I meant by depending is that while such behaviour isn't specified
> > in the spec, it is available in a fair few browsers in their quirks
> > mode, but not in their standards mode.
> 
> I think we're referring to two separate behaviors here. I was referring to
> sizing relative to available area as opposed to the containing block.
> Specifically, I was referring to its absence in standards mode, which I
> think is unfortunate.
> 
> > Well, I was trying to show that he was trying to put in a screw with a
> > hammer rather than a screwdriver: it might kinda work, but it's not the
> > right way, seeing as his problem was really a positioning one rather
> > than
> 
> I see what you're saying. However, I interpreted Isaac's original post as
> blowing off steam. In other words, I think he was lamenting the fact that
> CSS (at any level) does not support sizing relative to the available
> content
> area. Isaac, let me know if I misunderstood this.
> 
> My question to you is, all other things being equal, do you really think
> that fixed positioning is a better way to solve this problem than relative
> sizing? One of the great things about HTML is that elements are allowed to
> flow. Users can change their default font and size, disable images, etc.,
> and the page just adapts.
> 
> Fixed positioning in general -- and your proposed solution specifically --
> break this very badly. As a developer, I now have to know the exact pixel
> size of every element on the page and position objects off the
> top/bottom/left/right accordingly. Worse, I have to know these at design
> time as opposed to runtime.
> 
> I just don't understand how this can be considered an improvement?
> 
> > But what he's trying to do *is* positioning, not sizing.
> 
> Correction, what he's trying to accomplish is sizing relative to the
> available content area. The only way to approximate it in CSS 2 compliant
> browsers is to use fixed positioning. To my knowledge, there is no way to
> accomplish it in CSS 1 compliant browsers (sans-html formatting).
> 
> > I know he's
> > talking about sizing, but what I'm trying to get across is that *his*
> > particular problem isn't with sizing, and not with the differences
> > between the MS and W3C box models.
> >
> > And IE doesn't support fixed positioning, nor has it ever done so.
> 
> Uhg. Yes it does. Internet Explorer 6 supports CSS level 1 fixed
> positioning. Earlier versions of IE also supported it, albeit with the
> broken box model.
> 
> > Try
> > the code below in IE6, Firefox, Opera, and any other browsers you can
> > lay your hands on if you don't believe me.
> 
> You really need to qualify some of your statements. The code you posted
> uses
> CSS level 2 fixed positioning. Specifically, the "bottom" and "right"
> properties are part of the level 2 spec. Internet Explorer does not
> support
> CSS level 2:
> 
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/dnie60/html
> /cssenhancements.asp
> 
>   "Building on top of the functionality of previous versions,
>Internet Explorer 6 now provides full support for CSS
>Level 1"
> 
> > And there only doing that because another strong contender appeared on
> the
> 
> > scene in their primary market. They *had* let it die, but now they're
> > resurrecting it.
> 
> Really? I've never seen anything official from Microsoft that said they
> were
> discontinuing development of Internet Explorer. All the official stuff
> I've
> seen simply said that they were not going to continue to develop Internet
> Explorer as a separate product.
> 
> That said, the Internet Explorer team has apparently been reformed as an
> entity separate from the Windows team. There is some talk about an
> Internet
> Explorer 7 separate from the operating system. However, I haven't seen
> this
> announced officially. If it's true, I would guess that this is in response
> to competition from Firefox et al.
> 
> > And my argument is that he's attacking the problem with the wrong tools.
> > Positioning is what he want. It'

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

> What I meant by depending is that while such behaviour isn't specified
> in the spec, it is available in a fair few browsers in their quirks
> mode, but not in their standards mode.

I think we're referring to two separate behaviors here. I was referring to
sizing relative to available area as opposed to the containing block.
Specifically, I was referring to its absence in standards mode, which I
think is unfortunate.

> Well, I was trying to show that he was trying to put in a screw with a
> hammer rather than a screwdriver: it might kinda work, but it's not the
> right way, seeing as his problem was really a positioning one rather
> than

I see what you're saying. However, I interpreted Isaac's original post as
blowing off steam. In other words, I think he was lamenting the fact that
CSS (at any level) does not support sizing relative to the available content
area. Isaac, let me know if I misunderstood this.

My question to you is, all other things being equal, do you really think
that fixed positioning is a better way to solve this problem than relative
sizing? One of the great things about HTML is that elements are allowed to
flow. Users can change their default font and size, disable images, etc.,
and the page just adapts.

Fixed positioning in general -- and your proposed solution specifically --
break this very badly. As a developer, I now have to know the exact pixel
size of every element on the page and position objects off the
top/bottom/left/right accordingly. Worse, I have to know these at design
time as opposed to runtime. 

I just don't understand how this can be considered an improvement?

> But what he's trying to do *is* positioning, not sizing.

Correction, what he's trying to accomplish is sizing relative to the
available content area. The only way to approximate it in CSS 2 compliant
browsers is to use fixed positioning. To my knowledge, there is no way to
accomplish it in CSS 1 compliant browsers (sans-html formatting).

> I know he's
> talking about sizing, but what I'm trying to get across is that *his*
> particular problem isn't with sizing, and not with the differences
> between the MS and W3C box models.
> 
> And IE doesn't support fixed positioning, nor has it ever done so.

Uhg. Yes it does. Internet Explorer 6 supports CSS level 1 fixed
positioning. Earlier versions of IE also supported it, albeit with the
broken box model.

> Try
> the code below in IE6, Firefox, Opera, and any other browsers you can
> lay your hands on if you don't believe me.

You really need to qualify some of your statements. The code you posted uses
CSS level 2 fixed positioning. Specifically, the "bottom" and "right"
properties are part of the level 2 spec. Internet Explorer does not support
CSS level 2:

 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html
/cssenhancements.asp

  "Building on top of the functionality of previous versions,
   Internet Explorer 6 now provides full support for CSS
   Level 1"

> And there only doing that because another strong contender appeared on the

> scene in their primary market. They *had* let it die, but now they're 
> resurrecting it.

Really? I've never seen anything official from Microsoft that said they were
discontinuing development of Internet Explorer. All the official stuff I've
seen simply said that they were not going to continue to develop Internet
Explorer as a separate product.

That said, the Internet Explorer team has apparently been reformed as an
entity separate from the Windows team. There is some talk about an Internet
Explorer 7 separate from the operating system. However, I haven't seen this
announced officially. If it's true, I would guess that this is in response
to competition from Firefox et al.

> And my argument is that he's attacking the problem with the wrong tools.
> Positioning is what he want. It's a pity IE just doesn't support it
> completely enough.

Fair enough, and I agree that it's a shame that Internet Explorer 6 does not
support CSS level 2. The standard is old enough that support for it could
have made it into Internet Explorer 6. Nevertheless, since Internet Explorer
is still the dominant browser, your solution isn't really practical.

For what it's worth, I agree that fixed positioning is the way to accomplish
what he's trying to accomplish in CSS 2 compliant browsers. It's
unfortunately, but it's true. 

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057


~|
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:188447
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

Ray Champagne wrote:

> Eudora 6.2 actually.
> 
> I am quite over it now.  A few minutes ago I was annoyed, though.  Popups 
> make me hyper-sensitive.
> 
> What exactly would be a 'smart' client?  Thunderbird?  Write my own in cf?  :)

Thunderbird is neat! I've a friend who swears by The Bat, though I've
never used it myself.

K.

-- 
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 Silver Sponsor - RUWebby
http://www.ruwebby.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188444
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ray Champagne]

Nope, not at all.

I guess I did too.  Water under the bridge my friend.

:)

Ray

At 02:13 PM 12/21/2004, you wrote:
>Ray Champagne wrote:
>
> > As I now know.
> >
> > For the third time, and last time:  I was annoyed, didn't investigate the
> > source of the issue and wrote a response.
>
>I didn't see the other responses, so I'm sorry about that. I hope I
>didn't come across as hostile, 'cause that wasn't my intent. So we'll
>put it down to accidents on both our parts, eh? ;-)
>
>K.
>
>--
>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:188443
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

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

Ben Rogers wrote:

>>Unfortunately it's easier for them that way -- and I suspect it
>>precedes another round of large numbers of heavily IE only,
>>non-standard features for use with the new XML in Longhorne. Doesn't
>>Mozilla do something similar with XUL now tho? The big difference
>>being that Mozilla isn't selling it as the only way to integrate with
>>a monolithic operating system that dominates a good share of the
>>business market. At least as far as I know -- I could be completely
>>off-base, just been my impression from what I've read/heard.
> 
> Yeah, there's been quite a bit of talk about "why didn't Microsoft just use
> XUL". The answer from Microsoft seems to be that XUL/CSS wasn't designed for
> rendering desktop applications. I think it's roughly the same argument for
> MXML.

 Uh, then what are the various Moz apps and Komodo?
Methinks whoever came up with that excuse has been smoking something...

>>Thanks for the links... First one I've read... second one... well...
>>dunno... I'm just not ready to drop $90 for 6 months of access to a
>>site I don't know if I'll use much.
> 
> 
> Sorry about that. I don't think I've subscribed to that site. In fact, I'm
> using an OS I just installed a month ago, so I'm pretty sure that site
> doesn't remember me. Oh well, it was just more of the same.
> 
> 
>>Thanks Ben! Not bad at all! Much better than I was able to
>>accomplish...
> 
> 
> No problem. After a recent argument...errr...ummm...debate on this list,
> I've decided to try and create a fully XHTML/CSS 2.1 compliant design. So,
> to make a long story short, I'm trying to solve some of the same problems.
> :)

Nudge, wink, don't forget to look at that code I posted up. All
XHTML/CSS goodness. But, of course, IE6 requires the IE7 hacks to get
it to work.

K.

-- 
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:188442
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

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

S.Isaac Dealey wrote:

>>I don't think he's "depending" on this behavior. He's
>>lamenting the fact
>>that CSS doesn't support a mechanism for sizing elements
>>relative to the
>>available space. In HTML all heights and widths are based
>>on the available
>>area, not the size of the containing block.
> 
> I dunno -- I was giving him the benefit of the doubt, 'cause I was
> hoping he would prove me wrong. :P The issue of positioning is related
> to it, but only really occurs because of the desire for sizing.

Your issue's purely one of positioning. That's why I was saying what I
was. Sizing issues just don't come into your problem.

>>>If IE wasn't so braindead, it'd support fixed
>>>positioning. In this case,
>>>you could position your elements wherever you liked
>>>relative to the four
>>>sides of the screen. This is possible in Firefox, but not
>>>in IE, because
>>>MS have slowly let IE die.
> 
>>Fixed positioning is possible in Internet Explorer. It is
>>even possible in
>>versions of Internet Explorer which pre-date the Mozilla
>>project. Again,
>>this is not about positioning, it's about sizing elements.
> 
> I thought IE supported fixed positioning... I was giving him the
> benefit of the doubt that there was something wrong with MS
> implementation of it and his email was merely worded in a confusing
> manner.

It doesn't support fixed positioning. Full stop. End of story. Elvis may
even have left the building. It supports relative and absolute, but not
fixed. You need JavaScript hacks to support it.


Where did this myth come from, anyway? At best it sounds like a 
confusion between what fixed and absolute positioning do.

Fixed positioning positions things relative to the viewport. Absolute
positions things relative to the whole page. See the code I posted up
in my reply to Ben for two examples, one of which is a solution to your
problem, but won't work on IE without the rather excellent IE7
JavaScript hacks http://dean.edwards.name/IE7/>.


> Doesn't Mozilla do something similar with XUL now tho?

Yup, and it has since before Longhorn for XAML was a glint in MS's eye.

>> However, none of the solutions mentioned in these articles completely
 >> solves Isaac's problem. In fact, Isaac only got as far as he did
>> because he mixed html table tags with divs.
> 
> That was my experience.

Yup, but that's because you appear to be approaching the problem from
the wrong angle. As I said, take a look at that code I put in my reply
to Ben. Much goodness in there. :-)

K.

-- 
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 Silver Sponsor - New Atlanta
http://www.newatlanta.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188440
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

Ray Champagne wrote:

> As I now know.
> 
> For the third time, and last time:  I was annoyed, didn't investigate the 
> source of the issue and wrote a response.

I didn't see the other responses, so I'm sorry about that. I hope I 
didn't come across as hostile, 'cause that wasn't my intent. So we'll
put it down to accidents on both our parts, eh? ;-)

K.

-- 
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:188439
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

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ray Champagne]

As I now know.

For the third time, and last time:  I was annoyed, didn't investigate the 
source of the issue and wrote a response.

Ray

At 01:59 PM 12/21/2004, you wrote:
>Ray Champagne wrote:
>
> > Why put scripts in your email?  This pops up two blank windows when I read
> > itannoying at best dude.
>
>Scripts? There was nothing in that email except text. It was sent as
>plain text too.
>
>If your email client reacts badly to HTML in plain text, I suggest you
>get a new one 'cause your one's acting wrong.
>
>K.
>
>--
>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 Silver Sponsor - CFDynamics
http://www.cfdynamics.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188432
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

Ray Champagne wrote:

> Why put scripts in your email?  This pops up two blank windows when I read 
> itannoying at best dude.

Scripts? There was nothing in that email except text. It was sent as
plain text too.

If your email client reacts badly to HTML in plain text, I suggest you
get a new one 'cause your one's acting wrong.

K.

-- 
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:188428
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

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ray Champagne]

Yea, that was very kind of you.  If you want to insult me, just do 
it.  Saying "kindly' doesn't dress it up any more.  Besides, I won't be 
insulted anyway.

I wasn't following the thread, it opened a window, I didn't bother to 
search out the reason why.  How does that make me 'new' to the internet 
thing?  Oh yea, I am sure everyone here is working with wonderfully perfect 
email clients, too, and this only happened to me and my shitty Eudora client.

Why am I even wasting my time writing this?  I dunno.



At 01:16 PM 12/21/2004, you wrote:
>You're apparently new to this whole Internet thing so I'll kindly suggest
>that you try a different e-mail client.
>
>Ben Rogers
>http://www.c4.net
>v.508.240.0051
>f.508.240.0057
>
> > -Original Message-
> > From: Ray Champagne [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, December 21, 2004 12:03 PM
> > To: CF-Talk
> > Subject: Re: css - height 100% - i'd like to kill the crack-addicts who
> > wrote the w3c box model
> >
> > Why put scripts in your email?  This pops up two blank windows when I read
> > itannoying at best dude.
> >
> > Ray
> >
> > At 11:59 AM 12/21/2004, you wrote:
> > >Ben Rogers wrote:
> > >
> > >  >>Well, your problems are manyfold.
> > >  >>
> > >  >>Firstly, you're depending on behaviour that was never mandated in the
> > >  >>specs, that being that a height of 100% means 100% of the available
> > >  >>window area or available area.
> > >  >
> > >  > I don't think he's "depending" on this behavior. He's lamenting the
> > fact
> > >  > that CSS doesn't support a mechanism for sizing elements relative to
> > the
> > >  > available space. In HTML all heights and widths are based on the
> > >available
> > >  > area, not the size of the containing block.
> > >
> > >What I meant by depending is that while such behaviour isn't specified
> > >in the spec, it is available in a fair few browsers in their quirks
> > >mode, but not in their standards mode.
> > >
> > >And thanks for the article below: I didn't know about the 100% height on
> > >the html element trick.
> > >
> > >  > I also think he's hoping that someone will prove him wrong. :)
> > >
> > >Well, I was trying to show that he was trying to put in a screw with a
> > >hammer rather than a screwdriver: it might kinda work, but it's not the
> > >right way, seeing as his problem was really a positioning one rather
> > >than
> > >
> > > >>If IE wasn't so braindead, it'd support fixed positioning. In this
> > case,
> > > >>you could position your elements wherever you liked relative to the
> > four
> > > >>sides of the screen. This is possible in Firefox, but not in IE,
> > because
> > > >>MS have slowly let IE die.
> > > >
> > > > Fixed positioning is possible in Internet Explorer. It is even
> > possible in
> > > > versions of Internet Explorer which pre-date the Mozilla project.
> > Again,
> > > > this is not about positioning, it's about sizing elements.
> > >
> > >But what he's trying to do *is* positioning, not sizing. I know he's
> > >talking about sizing, but what I'm trying to get across is that *his*
> > >particular problem isn't with sizing, and not with the differences
> > >between the MS and W3C box models.
> > >
> > >And IE doesn't support fixed positioning, nor has it ever done so. Try
> > >the code below in IE6, Firefox, Opera, and any other browsers you can
> > >lay your hands on if you don't believe me.
> > >
> > > > Also, Microsoft has not let Internet Explorer die. They are going to
> > tie
> > > > Internet Explorer upgrades to new releases of the operating system.
> > > > Personally, I wish they hadn't made this decision, but that's their
> > > > currently announced intention.
> > >
> > >And there only doing that because another strong contender appeared on
> > >the scene in their primary market. They *had* let it die, but now
> > >they're resurrecting it.
> > >
> > > > However, none of the solutions mentioned in these articles completely
> > > solves
> > > > Isaac's problem. In fact, Isaac only got as far as he did because 

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

You're apparently new to this whole Internet thing so I'll kindly suggest
that you try a different e-mail client.

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057

> -Original Message-
> From: Ray Champagne [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 21, 2004 12:03 PM
> To: CF-Talk
> Subject: Re: css - height 100% - i'd like to kill the crack-addicts who
> wrote the w3c box model
> 
> Why put scripts in your email?  This pops up two blank windows when I read
> itannoying at best dude.
> 
> Ray
> 
> At 11:59 AM 12/21/2004, you wrote:
> >Ben Rogers wrote:
> >
> >  >>Well, your problems are manyfold.
> >  >>
> >  >>Firstly, you're depending on behaviour that was never mandated in the
> >  >>specs, that being that a height of 100% means 100% of the available
> >  >>window area or available area.
> >  >
> >  > I don't think he's "depending" on this behavior. He's lamenting the
> fact
> >  > that CSS doesn't support a mechanism for sizing elements relative to
> the
> >  > available space. In HTML all heights and widths are based on the
> >available
> >  > area, not the size of the containing block.
> >
> >What I meant by depending is that while such behaviour isn't specified
> >in the spec, it is available in a fair few browsers in their quirks
> >mode, but not in their standards mode.
> >
> >And thanks for the article below: I didn't know about the 100% height on
> >the html element trick.
> >
> >  > I also think he's hoping that someone will prove him wrong. :)
> >
> >Well, I was trying to show that he was trying to put in a screw with a
> >hammer rather than a screwdriver: it might kinda work, but it's not the
> >right way, seeing as his problem was really a positioning one rather
> >than
> >
> > >>If IE wasn't so braindead, it'd support fixed positioning. In this
> case,
> > >>you could position your elements wherever you liked relative to the
> four
> > >>sides of the screen. This is possible in Firefox, but not in IE,
> because
> > >>MS have slowly let IE die.
> > >
> > > Fixed positioning is possible in Internet Explorer. It is even
> possible in
> > > versions of Internet Explorer which pre-date the Mozilla project.
> Again,
> > > this is not about positioning, it's about sizing elements.
> >
> >But what he's trying to do *is* positioning, not sizing. I know he's
> >talking about sizing, but what I'm trying to get across is that *his*
> >particular problem isn't with sizing, and not with the differences
> >between the MS and W3C box models.
> >
> >And IE doesn't support fixed positioning, nor has it ever done so. Try
> >the code below in IE6, Firefox, Opera, and any other browsers you can
> >lay your hands on if you don't believe me.
> >
> > > Also, Microsoft has not let Internet Explorer die. They are going to
> tie
> > > Internet Explorer upgrades to new releases of the operating system.
> > > Personally, I wish they hadn't made this decision, but that's their
> > > currently announced intention.
> >
> >And there only doing that because another strong contender appeared on
> >the scene in their primary market. They *had* let it die, but now
> >they're resurrecting it.
> >
> > > However, none of the solutions mentioned in these articles completely
> > solves
> > > Isaac's problem. In fact, Isaac only got as far as he did because he
> mixed
> > > html table tags with divs.
> >
> >And my argument is that he's attacking the problem with the wrong tools.
> >Positioning is what he want. It's a pity IE just doesn't support it
> >completely enough.
> >
> >Mind you, there's a set of JavaScript hacks called IE7, which you've
> >probably heard of, that fixes a lot of these flaws in IE6.
> >
> > > However, I was unable to eliminate the vertical scroll bar. I'm not
> even
> > > quite sure where this is coming from. My guess is it's the window
> chrome.
> >
> >Yup, it's part of the chrome. That, and the padding at the bottom of the
> >outermost div is going to trigger it anyway.
> >
> >Here's that code:
> >
> > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> >
> >Padding!
> >
> >Padding!
> >
> >Padding!
&g

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ray Champagne]

Eudora 6.2 actually.

I am quite over it now.  A few minutes ago I was annoyed, though.  Popups 
make me hyper-sensitive.

What exactly would be a 'smart' client?  Thunderbird?  Write my own in cf?  :)

Ray



At 12:25 PM 12/21/2004, you wrote:
> > Why put scripts in your email?  This pops up two blank
> > windows when I read
> > itannoying at best dude.
>
> > Ray
>
>Let me guess, you're using a web-mail client? ... Or possibly Outlook
>or AOL...
>
>That's always bothered me about web-mail clients -- the problem isn't
>with the email, it's with the client. An intelligent web-mail client
>would htmleditformat() the email if it's not being sent as an html
>email. I have yet to see one that does -- they're all stupid. Yahoo's
>might be okay about that now -- I'm not sure, I haven't used it in a
>while -- I think I remember Tiff saying there was a setting for it in
>their preferences.
>
>Though the real problem is that valid email shouldn't ever contain
>HTML, so it should be safe to blanketly htmleditformat() the entire
>email without worrying about losing any formatting... oh well... too
>late now.
>
>
>s. isaac dealey   954.927.5117
>new epoch : isn't it time for a change?
>
>add features without fixtures with
>the onTap open source framework
>
>http://macromedia.breezecentral.com/p49777853/
>http://www.sys-con.com/story/?storyid=44477&DE=1
>http://www.sys-con.com/story/?storyid=45569&DE=1
>http://www.fusiontap.com
>
>
>
>
>

~|
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:188408
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[S . Isaac Dealey]

> Why put scripts in your email?  This pops up two blank
> windows when I read
> itannoying at best dude.

> Ray

Let me guess, you're using a web-mail client? ... Or possibly Outlook
or AOL...

That's always bothered me about web-mail clients -- the problem isn't
with the email, it's with the client. An intelligent web-mail client
would htmleditformat() the email if it's not being sent as an html
email. I have yet to see one that does -- they're all stupid. Yahoo's
might be okay about that now -- I'm not sure, I haven't used it in a
while -- I think I remember Tiff saying there was a setting for it in
their preferences.

Though the real problem is that valid email shouldn't ever contain
HTML, so it should be safe to blanketly htmleditformat() the entire
email without worrying about losing any formatting... oh well... too
late now.


s. isaac dealey   954.927.5117
new epoch : isn't it time for a change?

add features without fixtures with
the onTap open source framework

http://macromedia.breezecentral.com/p49777853/
http://www.sys-con.com/story/?storyid=44477&DE=1
http://www.sys-con.com/story/?storyid=45569&DE=1
http://www.fusiontap.com




~|
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:188402
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ray Champagne]

Why put scripts in your email?  This pops up two blank windows when I read 
itannoying at best dude.

Ray

At 11:59 AM 12/21/2004, you wrote:
>Ben Rogers wrote:
>
>  >>Well, your problems are manyfold.
>  >>
>  >>Firstly, you're depending on behaviour that was never mandated in the
>  >>specs, that being that a height of 100% means 100% of the available
>  >>window area or available area.
>  >
>  > I don't think he's "depending" on this behavior. He's lamenting the fact
>  > that CSS doesn't support a mechanism for sizing elements relative to the
>  > available space. In HTML all heights and widths are based on the
>available
>  > area, not the size of the containing block.
>
>What I meant by depending is that while such behaviour isn't specified
>in the spec, it is available in a fair few browsers in their quirks
>mode, but not in their standards mode.
>
>And thanks for the article below: I didn't know about the 100% height on
>the html element trick.
>
>  > I also think he's hoping that someone will prove him wrong. :)
>
>Well, I was trying to show that he was trying to put in a screw with a
>hammer rather than a screwdriver: it might kinda work, but it's not the
>right way, seeing as his problem was really a positioning one rather
>than
>
> >>If IE wasn't so braindead, it'd support fixed positioning. In this case,
> >>you could position your elements wherever you liked relative to the four
> >>sides of the screen. This is possible in Firefox, but not in IE, because
> >>MS have slowly let IE die.
> >
> > Fixed positioning is possible in Internet Explorer. It is even possible in
> > versions of Internet Explorer which pre-date the Mozilla project. Again,
> > this is not about positioning, it's about sizing elements.
>
>But what he's trying to do *is* positioning, not sizing. I know he's
>talking about sizing, but what I'm trying to get across is that *his*
>particular problem isn't with sizing, and not with the differences
>between the MS and W3C box models.
>
>And IE doesn't support fixed positioning, nor has it ever done so. Try
>the code below in IE6, Firefox, Opera, and any other browsers you can
>lay your hands on if you don't believe me.
>
> > Also, Microsoft has not let Internet Explorer die. They are going to tie
> > Internet Explorer upgrades to new releases of the operating system.
> > Personally, I wish they hadn't made this decision, but that's their
> > currently announced intention.
>
>And there only doing that because another strong contender appeared on
>the scene in their primary market. They *had* let it die, but now
>they're resurrecting it.
>
> > However, none of the solutions mentioned in these articles completely 
> solves
> > Isaac's problem. In fact, Isaac only got as far as he did because he mixed
> > html table tags with divs.
>
>And my argument is that he's attacking the problem with the wrong tools.
>Positioning is what he want. It's a pity IE just doesn't support it
>completely enough.
>
>Mind you, there's a set of JavaScript hacks called IE7, which you've
>probably heard of, that fixes a lot of these flaws in IE6.
>
> > However, I was unable to eliminate the vertical scroll bar. I'm not even
> > quite sure where this is coming from. My guess is it's the window chrome.
>
>Yup, it's part of the chrome. That, and the padding at the bottom of the
>outermost div is going to trigger it anyway.
>
>Here's that code:
>
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>
>Padding!
>I'm here because of fixed positioning!
>
>Using fixed positioning, his problem can be solved as follows:
>
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
>
>onTap Framework
>Home
>
>[]
>
>
>Hence, my point.
>
>--
>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:188392
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

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

Ben Rogers wrote:

 >>Well, your problems are manyfold.
 >>
 >>Firstly, you're depending on behaviour that was never mandated in the
 >>specs, that being that a height of 100% means 100% of the available
 >>window area or available area.
 >
 > I don't think he's "depending" on this behavior. He's lamenting the fact
 > that CSS doesn't support a mechanism for sizing elements relative to the
 > available space. In HTML all heights and widths are based on the 
available
 > area, not the size of the containing block.

What I meant by depending is that while such behaviour isn't specified
in the spec, it is available in a fair few browsers in their quirks
mode, but not in their standards mode.

And thanks for the article below: I didn't know about the 100% height on
the html element trick.

 > I also think he's hoping that someone will prove him wrong. :)

Well, I was trying to show that he was trying to put in a screw with a
hammer rather than a screwdriver: it might kinda work, but it's not the
right way, seeing as his problem was really a positioning one rather
than

>>If IE wasn't so braindead, it'd support fixed positioning. In this case,
>>you could position your elements wherever you liked relative to the four
>>sides of the screen. This is possible in Firefox, but not in IE, because
>>MS have slowly let IE die.
> 
> Fixed positioning is possible in Internet Explorer. It is even possible in
> versions of Internet Explorer which pre-date the Mozilla project. Again,
> this is not about positioning, it's about sizing elements.

But what he's trying to do *is* positioning, not sizing. I know he's 
talking about sizing, but what I'm trying to get across is that *his*
particular problem isn't with sizing, and not with the differences
between the MS and W3C box models.

And IE doesn't support fixed positioning, nor has it ever done so. Try 
the code below in IE6, Firefox, Opera, and any other browsers you can 
lay your hands on if you don't believe me.

> Also, Microsoft has not let Internet Explorer die. They are going to tie
> Internet Explorer upgrades to new releases of the operating system.
> Personally, I wish they hadn't made this decision, but that's their
> currently announced intention.

And there only doing that because another strong contender appeared on
the scene in their primary market. They *had* let it die, but now
they're resurrecting it.

> However, none of the solutions mentioned in these articles completely solves
> Isaac's problem. In fact, Isaac only got as far as he did because he mixed
> html table tags with divs.

And my argument is that he's attacking the problem with the wrong tools.
Positioning is what he want. It's a pity IE just doesn't support it
completely enough.

Mind you, there's a set of JavaScript hacks called IE7, which you've 
probably heard of, that fixes a lot of these flaws in IE6.

> However, I was unable to eliminate the vertical scroll bar. I'm not even
> quite sure where this is coming from. My guess is it's the window chrome.

Yup, it's part of the chrome. That, and the padding at the bottom of the
outermost div is going to trigger it anyway.

Here's that code:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>



Untitled


#fixed-thingy
{
position:   fixed;
right:  60px;
top:80px;
bottom: 60px;

border: 1px solid black;
background: white;
padding:1ex;
}




Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!
Padding!

I’m here because of fixed positioning!



Using fixed positioning, his problem can be solved as follows:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>






body
{
margin: 0;
padding:0;
}

form
{
margin: 0;
}

#doc_type, #doc_ladder, #nav_frame_menu, #nav_frame_content, #doc_bottom
{
position:   fixed;
}

#doc_title
{
left:   3px;
right:  3px;
top:3px;
height: 40px;
}

#doc_ladder
{
left:   3px;
right:  3px;
top:46px;
height: 20px;
}

#nav_frame_menu
{
left:   3px;
top:69px;
bottom:

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

> Unfortunately it's easier for them that way -- and I suspect it
> precedes another round of large numbers of heavily IE only,
> non-standard features for use with the new XML in Longhorne. Doesn't
> Mozilla do something similar with XUL now tho? The big difference
> being that Mozilla isn't selling it as the only way to integrate with
> a monolithic operating system that dominates a good share of the
> business market. At least as far as I know -- I could be completely
> off-base, just been my impression from what I've read/heard.

Yeah, there's been quite a bit of talk about "why didn't Microsoft just use
XUL". The answer from Microsoft seems to be that XUL/CSS wasn't designed for
rendering desktop applications. I think it's roughly the same argument for
MXML.

> Thanks for the links... First one I've read... second one... well...
> dunno... I'm just not ready to drop $90 for 6 months of access to a
> site I don't know if I'll use much.

Sorry about that. I don't think I've subscribed to that site. In fact, I'm
using an OS I just installed a month ago, so I'm pretty sure that site
doesn't remember me. Oh well, it was just more of the same.

> Thanks Ben! Not bad at all! Much better than I was able to
> accomplish...

No problem. After a recent argument...errr...ummm...debate on this list,
I've decided to try and create a fully XHTML/CSS 2.1 compliant design. So,
to make a long story short, I'm trying to solve some of the same problems.
:)

> Incidentally -- in case you were curious -- the issue caused by the
> frameset is that the content frame populates a "breadcrumbs" trail in
> the header using DOM. In order to prevent the race condition in which
> the content loads before the header frame and the div containing the
> breadcrumbs is then not available to be populated, I'm loading the
> header first and then using DOM in the header frame to load the
> content frame to make sure the header div is available before the
> content frame loads. I'm not entirely happy with this scenario, but
> it's working -- and it lets the user resize the navigation frame, so
> it has its advantages. 

That sounds reasonable. I was using several more or less global variables
stored in the navigator and window objects in one application (for which we
had several different versions). I was using those to track whether or not a
frame had loaded. Turns out, Windows XP Service Pack 2 didn't like that very
much. Your way sounds much safer than mine. :)

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057


~|
Special thanks to the CF Community Suite Silver Sponsor - New Atlanta
http://www.newatlanta.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188345
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[S . Isaac Dealey]

>> Well, your problems are manyfold.
>>
>> Firstly, you're depending on behaviour that was never
>> mandated in the
>> specs, that being that a height of 100% means 100% of the
>> available
>> window area or available area.

> I don't think he's "depending" on this behavior. He's
> lamenting the fact
> that CSS doesn't support a mechanism for sizing elements
> relative to the
> available space. In HTML all heights and widths are based
> on the available
> area, not the size of the containing block.

I dunno -- I was giving him the benefit of the doubt, 'cause I was
hoping he would prove me wrong. :P The issue of positioning is related
to it, but only really occurs because of the desire for sizing.

> I also think he's hoping that someone will prove him
> wrong. :)

It would be nice. :)

>> You'll get this behaviour *without* the doctype because
>> that's how it
>> was treated by browsers in the past. This is quirks mode,
>> and there be
>> funkiness.

> I think Isaac's aware of this.

Yep, had already covered that front -- and applied the standard-mode
doctype and height & width 100% to both the html and body element in
the style sheet (as seems to be the general recommendation from css
gurus).

>> If IE wasn't so braindead, it'd support fixed
>> positioning. In this case,
>> you could position your elements wherever you liked
>> relative to the four
>> sides of the screen. This is possible in Firefox, but not
>> in IE, because
>> MS have slowly let IE die.

> Fixed positioning is possible in Internet Explorer. It is
> even possible in
> versions of Internet Explorer which pre-date the Mozilla
> project. Again,
> this is not about positioning, it's about sizing elements.

I thought IE supported fixed positioning... I was giving him the
benefit of the doubt that there was something wrong with MS
implementation of it and his email was merely worded in a confusing
manner.

> Also, Microsoft has not let Internet Explorer die. They
> are going to tie
> Internet Explorer upgrades to new releases of the
> operating system.
> Personally, I wish they hadn't made this decision, but
> that's their
> currently announced intention.

Unfortunately it's easier for them that way -- and I suspect it
precedes another round of large numbers of heavily IE only,
non-standard features for use with the new XML in Longhorne. Doesn't
Mozilla do something similar with XUL now tho? The big difference
being that Mozilla isn't selling it as the only way to integrate with
a monolithic operating system that dominates a good share of the
business market. At least as far as I know -- I could be completely
off-base, just been my impression from what I've read/heard.

>> Your problem isn't with the spec--and definitely not with
>> the box model,
>> which doesn't even come up here--but with a lack of
>> implementation of
>> the spec.

> I think you've misunderstood the nature of the problem. It
> is most
> definitely an issue with the spec. Whether or not you
> consider it to be a
> fault of the spec (I do), is up for debate.

> Here's a few links on the subject:

>   http://www.quirksmode.org/css/100percheight.html

>   http://www.webmasterworld.com/forum83/200.htm

Thanks for the links... First one I've read... second one... well...
dunno... I'm just not ready to drop $90 for 6 months of access to a
site I don't know if I'll use much.

> However, none of the solutions mentioned in these articles
> completely solves
> Isaac's problem. In fact, Isaac only got as far as he did
> because he mixed
> html table tags with divs.

That was my experience.

> Isaac, I've included some code below which seems to solve
> at least part of
> the problem I think you were running into. I've added
> height and widths to
> the html and body elements (I think you were already doing
> this). I've also
> added them to each element all the way down.

> The theory is that if you don't specify either height or
> width on one
> element, that element will default to auto. Auto
> translates to the size of
> the content. Since this can't be calculated until after
> the element is
> rendered, any element within it can't use relative sizes.

> However, I was unable to eliminate the vertical scroll
> bar. I'm not even
> quite sure where this is coming from. My guess is it's the
> window chrome.
> Perhaps you could set the height of the body tag onload
> with JavaScript?

Thanks Ben! Not bad at all! Much better than I was able to
accomplish... I think I'm going to stick with the frames for this
particular page (in spite of other issues caused by that solution),
but I'm definately putting this in my queue of important development
notes for reference. IE still has problems when you shrink the window
vertically (it swallows the footer images under the lower edge of the
window), though the scroll bar on the parent document could be
eliminated I think with overflow: hide (?) on the body element -- I
don't remember, I only ever use "auto" to create scrollable div's
anyway. But I

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

> Well, your problems are manyfold.
> 
> Firstly, you're depending on behaviour that was never mandated in the
> specs, that being that a height of 100% means 100% of the available
> window area or available area.

I don't think he's "depending" on this behavior. He's lamenting the fact
that CSS doesn't support a mechanism for sizing elements relative to the
available space. In HTML all heights and widths are based on the available
area, not the size of the containing block.

I also think he's hoping that someone will prove him wrong. :)

> The specs, for better or for worse, don't
> recogise this usage because it's meaningless in the broader context of
> positioning, which is that positioning is done on the basis of the total
> rendering area of the page, not just the current viewport.

I don't think it's positioning we're discussing here: it's sizing. If all
your elements are positioned relative to one another, there's no reason you
can't support sizing based on available heights and widths (as was the case
in HTML). Once you add absolute positioning to the mix, it gets a bit
trickier.

> You'll get this behaviour *without* the doctype because that's how it
> was treated by browsers in the past. This is quirks mode, and there be
> funkiness.

I think Isaac's aware of this.

> If IE wasn't so braindead, it'd support fixed positioning. In this case,
> you could position your elements wherever you liked relative to the four
> sides of the screen. This is possible in Firefox, but not in IE, because
> MS have slowly let IE die.

Fixed positioning is possible in Internet Explorer. It is even possible in
versions of Internet Explorer which pre-date the Mozilla project. Again,
this is not about positioning, it's about sizing elements.

Also, Microsoft has not let Internet Explorer die. They are going to tie
Internet Explorer upgrades to new releases of the operating system.
Personally, I wish they hadn't made this decision, but that's their
currently announced intention.

> Your problem isn't with the spec--and definitely not with the box model,
> which doesn't even come up here--but with a lack of implementation of
> the spec.

I think you've misunderstood the nature of the problem. It is most
definitely an issue with the spec. Whether or not you consider it to be a
fault of the spec (I do), is up for debate.

Here's a few links on the subject:

  http://www.quirksmode.org/css/100percheight.html

  http://www.webmasterworld.com/forum83/200.htm

However, none of the solutions mentioned in these articles completely solves
Isaac's problem. In fact, Isaac only got as far as he did because he mixed
html table tags with divs. 

Isaac, I've included some code below which seems to solve at least part of
the problem I think you were running into. I've added height and widths to
the html and body elements (I think you were already doing this). I've also
added them to each element all the way down.

The theory is that if you don't specify either height or width on one
element, that element will default to auto. Auto translates to the size of
the content. Since this can't be calculated until after the element is
rendered, any element within it can't use relative sizes.

However, I was unable to eliminate the vertical scroll bar. I'm not even
quite sure where this is coming from. My guess is it's the window chrome.
Perhaps you could set the height of the body tag onload with JavaScript?

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057

http://www.w3.org/TR/html4/loose.dtd";>









onTap Framework


Home























https://www.paypal.com/cgi-bin/webscr";
method="post" style="margin: 0px;">




   

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

S.Isaac Dealey wrote:

>>S.Isaac Dealey wrote:
>>
S.Isaac Dealey wrote:
>>>
>>>Except that with the w3c box model there are still a
>>>small number of very simple things which are ...
>>>I hate to say it, but _FLAT_IMPOSSIBLE_ to accomplish.
>>>Whereas this is not the case with the MS box model.
>>
>>An example would be helpful.
> 
> You must have missed the first message in this thread...
> 
> Here's the archive url:
> 
> http://www.houseoffusion.com/cf_lists/messages.cfm/threadid:37168/foru
> mid:4

Ah, either AVG or Thunderbird must've decided to clip that.

>>>What matters is that a viewable page can be formatted
>>>in a consistent manner which allows us full control
>>>over the display -- which we don't have with the
>>>w3c model.
> 
> 
>>Full control, shmull control: there'll always be a
>>browser that screws up in some way. As soon as the
>>page leaves the server, there goes our control over
>>how it's displayed.
> 
> Except I'm not talking about every browser. I'm not talking about
> Konqueror not rendering correctly -- I'm talking about not having
> control even when using a browser which is said to render the box
> model correctly.
> 
>>>My efforts to support the w3c model are based on
>>>the idea that it's better to have a _BROKEN_
>>>standard than no standard.
>>
>>That's fair, but I don't see *how* exactly it's
>>broken? A pain at times, yes, but calling it broken
>>seems a little much.
> 
> Two iframes side by side which together fill the screen horizontally
> having a fixed amount of space between the iframe and the window edge
> and a fixed amount of space between each other and which also fill the
> remainder of the height of the window after a header and footer div
> are placed above and below them, and which don't degenerated into one
> above and one below when the browser is shrunk horizontally.
> 
> If you can accomplish that in Firefox or IE6 with the appropriate
> doctype, I'd be mighty impressed, and I'd amend/retract what I've
> said.

Well, your problems are manyfold.

Firstly, you're depending on behaviour that was never mandated in the
specs, that being that a height of 100% means 100% of the available
window area or available area. The specs, for better or for worse, don't
recogise this usage because it's meaningless in the broader context of
positioning, which is that positioning is done on the basis of the total
rendering area of the page, not just the current viewport.

You'll get this behaviour *without* the doctype because that's how it
was treated by browsers in the past. This is quirks mode, and there be
funkiness.

If IE wasn't so braindead, it'd support fixed positioning. In this case,
you could position your elements wherever you liked relative to the four
sides of the screen. This is possible in Firefox, but not in IE, because
MS have slowly let IE die.

Your problem isn't with the spec--and definitely not with the box model,
which doesn't even come up here--but with a lack of implementation of
the spec.

However, depending on what you're trying to write, frames are probably a
better way of doing this anyway. All you seem to be doing is trying to
emulate them anyway, and iframes in this context are a bit icky anyway.

I'll throw the fixed positioning code your way if you like.

-- 
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.0 - Release Date: 17/12/2004


~|
Special thanks to the CF Community Suite Silver Sponsor - New Atlanta
http://www.newatlanta.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188254
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[S . Isaac Dealey]

> S.Isaac Dealey wrote:
>>>S.Isaac Dealey wrote:
>>
>> Except that with the w3c box model there are still a
>> small number of very simple things which are ...
>> I hate to say it, but _FLAT_IMPOSSIBLE_ to accomplish.
>> Whereas this is not the case with the MS box model.

> An example would be helpful.

You must have missed the first message in this thread...

Here's the archive url:

http://www.houseoffusion.com/cf_lists/messages.cfm/threadid:37168/foru
mid:4

>> What matters is that a viewable page can be formatted
>> in a consistent manner which allows us full control
>> over the display -- which we don't have with the
>> w3c model.

> Full control, shmull control: there'll always be a
> browser that screws up in some way. As soon as the
> page leaves the server, there goes our control over
> how it's displayed.

Except I'm not talking about every browser. I'm not talking about
Konqueror not rendering correctly -- I'm talking about not having
control even when using a browser which is said to render the box
model correctly.

>> My efforts to support the w3c model are based on
>> the idea that it's better to have a _BROKEN_
>> standard than no standard.

> That's fair, but I don't see *how* exactly it's
> broken? A pain at times, yes, but calling it broken
> seems a little much.

Two iframes side by side which together fill the screen horizontally
having a fixed amount of space between the iframe and the window edge
and a fixed amount of space between each other and which also fill the
remainder of the height of the window after a header and footer div
are placed above and below them, and which don't degenerated into one
above and one below when the browser is shrunk horizontally.

If you can accomplish that in Firefox or IE6 with the appropriate
doctype, I'd be mighty impressed, and I'd amend/retract what I've
said.


s. isaac dealey 954.927.5117
new epoch : isn't it time for a change?

add features without fixtures with
the onTap open source framework

http://macromedia.breezecentral.com/p49777853/
http://www.sys-con.com/story/?storyid=44477&DE=1
http://www.sys-con.com/story/?storyid=45569&DE=1
http://www.fusiontap.com


~|
Special thanks to the CF Community Suite Silver Sponsor - RUWebby
http://www.ruwebby.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188235
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

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

S.Isaac Dealey wrote:
>>S.Isaac Dealey wrote:
> 
> Mime-Version: 1.0
> Content-Type: text/plain
> 
> 
>>>so after all this time, there's still no standard that
>>>allows an
>>>adequate means of specifying something as simple as
>>>height 100% ...
>>>because according to the w3c, 100% of the height of an
>>>airplane
>>>discludes its canopy and landing gear and 100% of its
>>>length discludes
>>>its propeller and tail-fins...
> 
> 
>>Things aren't as simple as that. I believe that the W3C
>>box model builds
>>on established norms in typesetting. The real crackheads
>>are the idiots
>>who gave us Microsoft's alternative box model when the W3C
>>one was
>>already around.
> 
> 
> Except that with the w3c box model there are still a small number of
> very simple things which are ... I hate to say it, but
> _FLAT_IMPOSSIBLE_ to accomplish.  Whereas this is not the case with the
 > MS box model.

An example would be helpful.

> Whether the w3c box model is based on typesetting norms
> imo is irrelevant, given that the dominant medium for HTML is _NOT_
> print.

Maybe so, it it has to deal with people who are coming from a print
background.

> What matters is that a viewable page can be formatted in a
> consistent manner which allows us full control over the display --
> which we don't have with the w3c model.

Full control, shmull control: there'll always be a browser that screws
up in some way. As soon as the page leaves the server, there goes our
control over how it's displayed.

> My efforts to support the w3c
> model are based on the idea that it's better to have a _BROKEN_
> standard than no standard.

That's fair, but I don't see *how* exactly it's broken? A pain at times,
yes, but calling it broken seems a little much.

K.

-- 
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.0 - Release Date: 17/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:188230
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

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

My issues with it are that it's not very intuitive, and it's a lot of code
(compared to the same layout using tables). On the other hand, it is fairly
flexible and somewhat backwards compatible. All in all, however, I think CSS
is a step backwards in this area. And despite what Eric Meyer thinks, I
think these types of designs are fairly common.

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057

> -Original Message-
> From: Greg Stewart [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 16, 2004 12:32 PM
> To: CF-Talk
> Subject: Re: css - height 100% - i'd like to kill the crack-addicts who
> wrote the w3c box model
> 
> Hmm it may seem like a lot of trouble, but using Doug's technique you
> can control the number of columns displayed and their order through
> CSS, just by changing the body ID, one template many possible layouts,
> I think it's worth the effort to look more closely at it. I use it all
> the time by merging it with CFML and an XML property file (to control
> widths on the fly).
> 
> My 2 pennies.
> 
> G
> 
> 
> On Thu, 16 Dec 2004 10:42:22 -0500, Ben Rogers <[EMAIL PROTECTED]> wrote:
> > > so after all this time, there's still no standard that allows an
> > > adequate means of specifying something as simple as height 100% ...
> > > because according to the w3c, 100% of the height of an airplane
> > > discludes its canopy and landing gear and 100% of its length discludes
> > > its propeller and tail-fins...
> >
> > Tell me about it. There are several aspects of CSS that just make you
> > scratch your head and wonder what the heck they were thinking. As an
> > example, look at the trouble one has to go through to create a fluid,
> two
> > column layout where the columns are of the same height (from Eric
> Meyer's
> > blog):
> >
> >   http://www.meyerweb.com/eric/thoughts/2004/09/03/sliding-faux-columns/
> >
> > Original source:
> >
> >   http://www.stopdesign.com/log/2004/09/03/liquid-bleach.html
> >
> > Ben Rogers
> > http://www.c4.net
> > v.508.240.0051
> > f.508.240.0057
> >
> > >
> > > Before you say it -- yes, I've assigned margin: 0; padding: 0; height:
> > > 100% on both the html and the body elements in the style sheet...
> > >
> > > And in this code there is no way to make the content of the 3rd table
> > > row display without specifying a height for the row -- there is also
> > > no way to tell the browser that the row should be 100% of the
> > > _remaining_ height of the table after accounting for the space taken
> > > by the other 3 rows (above and below). So my choices are 80% (so the
> > > bottom of the table may or may not match the bottom of the window) or
> > > a fixed height (so the bottom of the table definately doesn't match
> > > the bottom of the dinwo most of the time). Any attempt to set the
> > > height of the 3rd row to 100% results in the table exceeding the
> > > height of the browser window.
> > >
> > > And why use tables at all you ask? Because there's no way to specify
> > > the iframes float left and right and fill 100% of the width of the
> > > window without one of them being shoved down underneath the other if
> > > the browser window is shrunk horizontally.
> > >
> > > Oh well... frameset it is I guess... Doesn't make me any happier with
> > > the box model.
> > >
> > >
> > > 
> > > 
> > >> > style="height:40px;">onTap Framework
> > >> > style="height:20px;">Home
> > >   
> > >   
> > >   
> > >> cellspacing="0"
> > > style="height:100%; width: 100%;">
> > >   
> > >   
> > >> name="nav_frame_menu"
> > > frameborder="1" height="100%"
> > > width="250">
> > >   
> > >   
> > >> name="nav_frame_content"
> > > frameborder="1" height="100%"
> > > width="100%">
> > >   
> > >   

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Greg Stewart]

Hmm it may seem like a lot of trouble, but using Doug's technique you
can control the number of columns displayed and their order through
CSS, just by changing the body ID, one template many possible layouts,
I think it's worth the effort to look more closely at it. I use it all
the time by merging it with CFML and an XML property file (to control
widths on the fly).

My 2 pennies.

G

~|
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:187919
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

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Greg Stewart]

Hmm it may seem like a lot of trouble, but using Doug's technique you
can control the number of columns displayed and their order through
CSS, just by changing the body ID, one template many possible layouts,
I think it's worth the effort to look more closely at it. I use it all
the time by merging it with CFML and an XML property file (to control
widths on the fly).

My 2 pennies.

G 


On Thu, 16 Dec 2004 10:42:22 -0500, Ben Rogers <[EMAIL PROTECTED]> wrote:
> > so after all this time, there's still no standard that allows an
> > adequate means of specifying something as simple as height 100% ...
> > because according to the w3c, 100% of the height of an airplane
> > discludes its canopy and landing gear and 100% of its length discludes
> > its propeller and tail-fins...
> 
> Tell me about it. There are several aspects of CSS that just make you
> scratch your head and wonder what the heck they were thinking. As an
> example, look at the trouble one has to go through to create a fluid, two
> column layout where the columns are of the same height (from Eric Meyer's
> blog):
> 
>   http://www.meyerweb.com/eric/thoughts/2004/09/03/sliding-faux-columns/
> 
> Original source:
> 
>   http://www.stopdesign.com/log/2004/09/03/liquid-bleach.html
> 
> Ben Rogers
> http://www.c4.net
> v.508.240.0051
> f.508.240.0057
> 
> >
> > Before you say it -- yes, I've assigned margin: 0; padding: 0; height:
> > 100% on both the html and the body elements in the style sheet...
> >
> > And in this code there is no way to make the content of the 3rd table
> > row display without specifying a height for the row -- there is also
> > no way to tell the browser that the row should be 100% of the
> > _remaining_ height of the table after accounting for the space taken
> > by the other 3 rows (above and below). So my choices are 80% (so the
> > bottom of the table may or may not match the bottom of the window) or
> > a fixed height (so the bottom of the table definately doesn't match
> > the bottom of the dinwo most of the time). Any attempt to set the
> > height of the 3rd row to 100% results in the table exceeding the
> > height of the browser window.
> >
> > And why use tables at all you ask? Because there's no way to specify
> > the iframes float left and right and fill 100% of the width of the
> > window without one of them being shoved down underneath the other if
> > the browser window is shrunk horizontally.
> >
> > Oh well... frameset it is I guess... Doesn't make me any happier with
> > the box model.
> >
> >
> > 
> > 
> >> style="height:40px;">onTap Framework
> >> style="height:20px;">Home
> >   
> >   
> >   
> >cellspacing="0"
> > style="height:100%; width: 100%;">
> >   
> >   
> >name="nav_frame_menu"
> > frameborder="1" height="100%"
> > width="250">
> >   
> >   
> >name="nav_frame_content"
> > frameborder="1" height="100%"
> > width="100%">
> >   
> >   
> >   
> >   
> >   
> >   
> >> style="height:60px;">
> >>   action="https://www.paypal.com/cgi-bin/webscr"; method="post"
> > style="margin: 0px;">
> >   
> >> value="[EMAIL PROTECTED]" />
> >   
> >> value="ontapframework" />
> >   
> >value="USD" />
> >   
> >
> >>   type="image" border="0" style="border:0px;
> > background-color:transparent; float: left;"
> >   alt="Make a donation."
> > src="http://mx/otp/test/_components/docs/_images/donations.gif"; />
> >   
> >
> >>
> >   href="http://affiliates.macromedia.com/b.asp?id=2549&p=go/dr_home_af
> > f1">
> >>
> >   src="http://affiliates.macromedia.com/showb.asp?id=2549&img=mx2004_4
> > 68x60_b.gif" />
> >   
> > 
> >
> >
> > s. isaac dealey 954.927.5117
> > new epoch : isn't it time for a change?
> >
> > add features without fixtures with
> > the onTap open source framework
> >
> > http://www.sys-con.com/story/?storyid=44477&DE=1
> > http://www.sys-con.com/story/?storyid=45569&DE=1
> > http://www.fusiontap.com
> >
> >
> >
> 
> 

~|
Special thanks to the CF Community Suite Silver Sponsor - RUWebby
http://www.ruwebby.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:187916
Archives: http://www.houseoffusion.com/cf_lis

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[S . Isaac Dealey]

> S.Isaac Dealey wrote:

>> so after all this time, there's still no standard that
>> allows an
>> adequate means of specifying something as simple as
>> height 100% ...
>> because according to the w3c, 100% of the height of an
>> airplane
>> discludes its canopy and landing gear and 100% of its
>> length discludes
>> its propeller and tail-fins...

> Things aren't as simple as that. I believe that the W3C
> box model builds
> on established norms in typesetting. The real crackheads
> are the idiots
> who gave us Microsoft's alternative box model when the W3C
> one was
> already around.

Except that with the w3c box model there are still a small number of
very simple things which are ... I hate to say it, but
_FLAT_IMPOSSIBLE_ to accomplish. Whereas this is not the case with the
MS box model. Whether the w3c box model is based on typesetting norms
imo is irrelevant, given that the dominant medium for HTML is _NOT_
print. What matters is that a viewable page can be formatted in a
consistent manner which allows us full control over the display --
which we don't have with the w3c model. My efforts to support the w3c
model are based on the idea that it's better to have a _BROKEN_
standard than no standard.

s. isaac dealey 954.927.5117
new epoch : isn't it time for a change?

add features without fixtures with
the onTap open source framework

http://www.sys-con.com/story/?storyid=44477&DE=1
http://www.sys-con.com/story/?storyid=45569&DE=1
http://www.fusiontap.com


~|
Special thanks to the CF Community Suite Silver Sponsor - New Atlanta
http://www.newatlanta.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:187887
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Ben Rogers]

> so after all this time, there's still no standard that allows an
> adequate means of specifying something as simple as height 100% ...
> because according to the w3c, 100% of the height of an airplane
> discludes its canopy and landing gear and 100% of its length discludes
> its propeller and tail-fins...

Tell me about it. There are several aspects of CSS that just make you
scratch your head and wonder what the heck they were thinking. As an
example, look at the trouble one has to go through to create a fluid, two
column layout where the columns are of the same height (from Eric Meyer's
blog):

  http://www.meyerweb.com/eric/thoughts/2004/09/03/sliding-faux-columns/

Original source:

  http://www.stopdesign.com/log/2004/09/03/liquid-bleach.html

Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057

> 
> Before you say it -- yes, I've assigned margin: 0; padding: 0; height:
> 100% on both the html and the body elements in the style sheet...
> 
> And in this code there is no way to make the content of the 3rd table
> row display without specifying a height for the row -- there is also
> no way to tell the browser that the row should be 100% of the
> _remaining_ height of the table after accounting for the space taken
> by the other 3 rows (above and below). So my choices are 80% (so the
> bottom of the table may or may not match the bottom of the window) or
> a fixed height (so the bottom of the table definately doesn't match
> the bottom of the dinwo most of the time). Any attempt to set the
> height of the 3rd row to 100% results in the table exceeding the
> height of the browser window.
> 
> And why use tables at all you ask? Because there's no way to specify
> the iframes float left and right and fill 100% of the width of the
> window without one of them being shoved down underneath the other if
> the browser window is shrunk horizontally.
> 
> Oh well... frameset it is I guess... Doesn't make me any happier with
> the box model.
> 
> 
> 
> 
>style="height:40px;">onTap Framework
>style="height:20px;">Home
>   
>   
>   
>style="height:100%; width: 100%;">
>   
>   
>frameborder="1" height="100%"
> width="250">
>   
>   
>frameborder="1" height="100%"
> width="100%">
>   
>   
>   
>   
>   
>   
>style="height:60px;">
>  action="https://www.paypal.com/cgi-bin/webscr"; method="post"
> style="margin: 0px;">
>   
>value="[EMAIL PROTECTED]" />
>   
>value="ontapframework" />
>   
>   
>   
> 
>  type="image" border="0" style="border:0px;
> background-color:transparent; float: left;"
>   alt="Make a donation."
> src="http://mx/otp/test/_components/docs/_images/donations.gif"; />
>   
> 
>
>   href="http://affiliates.macromedia.com/b.asp?id=2549&p=go/dr_home_af
> f1">
>
>   src="http://affiliates.macromedia.com/showb.asp?id=2549&img=mx2004_4
> 68x60_b.gif" />
>   
> 
> 
> 
> s. isaac dealey 954.927.5117
> new epoch : isn't it time for a change?
> 
> add features without fixtures with
> the onTap open source framework
> 
> http://www.sys-con.com/story/?storyid=44477&DE=1
> http://www.sys-con.com/story/?storyid=45569&DE=1
> http://www.fusiontap.com
> 
> 
> 

~|
Special thanks to the CF Community Suite Silver Sponsor - RUWebby
http://www.ruwebby.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:187890
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

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Keith Gaughan]

S.Isaac Dealey wrote:

> so after all this time, there's still no standard that allows an
> adequate means of specifying something as simple as height 100% ...
> because according to the w3c, 100% of the height of an airplane
> discludes its canopy and landing gear and 100% of its length discludes
> its propeller and tail-fins...

Things aren't as simple as that. I believe that the W3C box model builds 
on established norms in typesetting. The real crackheads are the idiots
who gave us Microsoft's alternative box model when the W3C one was
already around.

K.

-- 
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.5.4 - Release Date: 15/12/2004


~|
Special thanks to the CF Community Suite Silver Sponsor - New Atlanta
http://www.newatlanta.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:187874
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[S . Isaac Dealey]

Yea, I'm still not happy with the standards guys tho...

thanks for suffering my rant. :)

> Think about it this way ... if it was easy, they wouldn't
> need smart
> guys like you and me  - they could get any idiot manager
> to do it
> themselves with a copy of FrontPage.



> Cheers
> Mike Kear
> Windsor, NSW, Australia
> AFP Webworks
> http://afpwebworks.com
> .com,.net,.org domains from AUD$20/Year



> On Thu, 16 Dec 2004 00:26:33 -0500, S. Isaac Dealey
> <[EMAIL PROTECTED]> wrote:
>> so after all this time, there's still no standard that
>> allows an
>> adequate means of specifying something as simple as
>> height 100% ...
>> because according to the w3c, 100% of the height of an
>> airplane
>> discludes its canopy and landing gear and 100% of its
>> length discludes
>> its propeller and tail-fins...
>>
>> Before you say it -- yes, I've assigned margin: 0;
>> padding: 0; height:
>> 100% on both the html and the body elements in the style
>> sheet...
>>

> [snip]



>> s. isaac dealey 954.927.5117
>> new epoch : isn't it time for a change?
>>

> 

~|
Special thanks to the CF Community Suite Silver Sponsor - CFDynamics
http://www.cfdynamics.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:187855
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

RE: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Micha Schopman]

Yes there is, you are able to position it absolute, giving it a
margin-left with the 1st column having a fixed width and the 2nd column
having a variable width. You need a relative positioned wrapper around
it :)

Micha Schopman
Project Manager

Modern Media, Databankweg 12 M, 3821 AL  Amersfoort
Tel 033-4535377, Fax 033-4535388
KvK Amersfoort 39081679, Rabo 39.48.05.380



~|
Special thanks to the CF Community Suite Silver Sponsor - RUWebby
http://www.ruwebby.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:187857
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

Re: css - height 100% - i'd like to kill the crack-addicts who wrote the w3c box model

[Mike Kear]

Think about it this way ... if it was easy, they wouldn't need smart
guys like you and me  - they could get any idiot manager to do it
themselves with a copy of FrontPage.



Cheers
Mike Kear
Windsor, NSW, Australia
AFP Webworks
http://afpwebworks.com
.com,.net,.org domains from AUD$20/Year



On Thu, 16 Dec 2004 00:26:33 -0500, S. Isaac Dealey <[EMAIL PROTECTED]> wrote:
> so after all this time, there's still no standard that allows an
> adequate means of specifying something as simple as height 100% ...
> because according to the w3c, 100% of the height of an airplane
> discludes its canopy and landing gear and 100% of its length discludes
> its propeller and tail-fins...
> 
> Before you say it -- yes, I've assigned margin: 0; padding: 0; height:
> 100% on both the html and the body elements in the style sheet...
>

[snip]


 
> s. isaac dealey 954.927.5117
> new epoch : isn't it time for a change?
>

~|
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:187848
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=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54