A Margin for Error - in CSS
-
First off, I'm a web developer. Whilst I'm aware of my lowly position in the food chain I have to point out that I started my career writing ANSI C and assembler, so I've clawed my way up a couple of links. And I'm old... But I use Macs. There's just no helping some people. Anyway, I'm refactoring a web app I wrote a couple of years back, standard PHP / MySQL fare with a liberal sprinkling of JS on the front end. I'm condensing a load of pages down to a single page and squirting a blob of AJAX in there to grease the wheels. There are no frameworks of monolithic libraries, I prefer to roll my own. If you are still reading I'll assume you know roughly what I'm talking about and get to the point. I've laid out my page in a cascading information kind of styley. You click a pretty broad subject in box 'a' and this displays relevant options in box 'b'. Clicking an option then shows specific details in box 'c'. Noddy stuff. I need the content to scale with the page, so I use percentages, and I need a definable and consistent 'gutter' between the boxes, so I'm using absolute positioning. Here's a link to my page mockup[^]. If you resize this window you'll notice (unless you are using Safari of course) that everything goes a bit Pete Tong in the bottom left corner! To position this (red in my example) div, I use a 40% top margin. In a "logical world" (which is obviously latin for "Cupertino") this would mean that I want the gap above this box to be 40% of the page height. In reality however, this equates to 40% of page's 'width'! If you make the page taller, the top margin, set to 40%, stays the same. Make it wider and the margin gets bigger, narrower - smaller! I originally assumed this was a browser error and reported my "Bug" to the "Masters of Such Things" (Latin for "Redmond"...), but the guys at Micro$oft informed me that this is the official spec as handed down from on high by the W3C. Sure enough[^], the powers that be state that:
Quote:
"Note that in a horizontal flow, percentages on ‘margin-top’ and ‘margin-bottom’ are relative to the width of the containing block, not the height (and in vertical flow, ‘margin-left’ and ‘margin-right’ are relative to the height, not the width)."
-
First off, I'm a web developer. Whilst I'm aware of my lowly position in the food chain I have to point out that I started my career writing ANSI C and assembler, so I've clawed my way up a couple of links. And I'm old... But I use Macs. There's just no helping some people. Anyway, I'm refactoring a web app I wrote a couple of years back, standard PHP / MySQL fare with a liberal sprinkling of JS on the front end. I'm condensing a load of pages down to a single page and squirting a blob of AJAX in there to grease the wheels. There are no frameworks of monolithic libraries, I prefer to roll my own. If you are still reading I'll assume you know roughly what I'm talking about and get to the point. I've laid out my page in a cascading information kind of styley. You click a pretty broad subject in box 'a' and this displays relevant options in box 'b'. Clicking an option then shows specific details in box 'c'. Noddy stuff. I need the content to scale with the page, so I use percentages, and I need a definable and consistent 'gutter' between the boxes, so I'm using absolute positioning. Here's a link to my page mockup[^]. If you resize this window you'll notice (unless you are using Safari of course) that everything goes a bit Pete Tong in the bottom left corner! To position this (red in my example) div, I use a 40% top margin. In a "logical world" (which is obviously latin for "Cupertino") this would mean that I want the gap above this box to be 40% of the page height. In reality however, this equates to 40% of page's 'width'! If you make the page taller, the top margin, set to 40%, stays the same. Make it wider and the margin gets bigger, narrower - smaller! I originally assumed this was a browser error and reported my "Bug" to the "Masters of Such Things" (Latin for "Redmond"...), but the guys at Micro$oft informed me that this is the official spec as handed down from on high by the W3C. Sure enough[^], the powers that be state that:
Quote:
"Note that in a horizontal flow, percentages on ‘margin-top’ and ‘margin-bottom’ are relative to the width of the containing block, not the height (and in vertical flow, ‘margin-left’ and ‘margin-right’ are relative to the height, not the width)."
-
Nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!!!!!!!!!!!!!!!! [Edit] de-broke the formatting.
“Education is not the piling on of learning, information, data, facts, skills, or abilities - that's training or instruction - but is rather making visible what is hidden as a seed”
“One of the greatest problems of our time is that many are schooled but few are educated”Sir Thomas More (1478 – 1535)
-
First off, I'm a web developer. Whilst I'm aware of my lowly position in the food chain I have to point out that I started my career writing ANSI C and assembler, so I've clawed my way up a couple of links. And I'm old... But I use Macs. There's just no helping some people. Anyway, I'm refactoring a web app I wrote a couple of years back, standard PHP / MySQL fare with a liberal sprinkling of JS on the front end. I'm condensing a load of pages down to a single page and squirting a blob of AJAX in there to grease the wheels. There are no frameworks of monolithic libraries, I prefer to roll my own. If you are still reading I'll assume you know roughly what I'm talking about and get to the point. I've laid out my page in a cascading information kind of styley. You click a pretty broad subject in box 'a' and this displays relevant options in box 'b'. Clicking an option then shows specific details in box 'c'. Noddy stuff. I need the content to scale with the page, so I use percentages, and I need a definable and consistent 'gutter' between the boxes, so I'm using absolute positioning. Here's a link to my page mockup[^]. If you resize this window you'll notice (unless you are using Safari of course) that everything goes a bit Pete Tong in the bottom left corner! To position this (red in my example) div, I use a 40% top margin. In a "logical world" (which is obviously latin for "Cupertino") this would mean that I want the gap above this box to be 40% of the page height. In reality however, this equates to 40% of page's 'width'! If you make the page taller, the top margin, set to 40%, stays the same. Make it wider and the margin gets bigger, narrower - smaller! I originally assumed this was a browser error and reported my "Bug" to the "Masters of Such Things" (Latin for "Redmond"...), but the guys at Micro$oft informed me that this is the official spec as handed down from on high by the W3C. Sure enough[^], the powers that be state that:
Quote:
"Note that in a horizontal flow, percentages on ‘margin-top’ and ‘margin-bottom’ are relative to the width of the containing block, not the height (and in vertical flow, ‘margin-left’ and ‘margin-right’ are relative to the height, not the width)."
Apple fails to conform to a web standard. Personally I'd rather they conformed even if it doesn't make sense, but I've been at this game since 2001 and know what the result of browser non-conformity can be. Don't think this is an anti-Apple rant, they conform about as well as the other major browsers, it just seems a bit of a first-world problem.
“Education is not the piling on of learning, information, data, facts, skills, or abilities - that's training or instruction - but is rather making visible what is hidden as a seed”
“One of the greatest problems of our time is that many are schooled but few are educated”Sir Thomas More (1478 – 1535)
-
First off, I'm a web developer. Whilst I'm aware of my lowly position in the food chain I have to point out that I started my career writing ANSI C and assembler, so I've clawed my way up a couple of links. And I'm old... But I use Macs. There's just no helping some people. Anyway, I'm refactoring a web app I wrote a couple of years back, standard PHP / MySQL fare with a liberal sprinkling of JS on the front end. I'm condensing a load of pages down to a single page and squirting a blob of AJAX in there to grease the wheels. There are no frameworks of monolithic libraries, I prefer to roll my own. If you are still reading I'll assume you know roughly what I'm talking about and get to the point. I've laid out my page in a cascading information kind of styley. You click a pretty broad subject in box 'a' and this displays relevant options in box 'b'. Clicking an option then shows specific details in box 'c'. Noddy stuff. I need the content to scale with the page, so I use percentages, and I need a definable and consistent 'gutter' between the boxes, so I'm using absolute positioning. Here's a link to my page mockup[^]. If you resize this window you'll notice (unless you are using Safari of course) that everything goes a bit Pete Tong in the bottom left corner! To position this (red in my example) div, I use a 40% top margin. In a "logical world" (which is obviously latin for "Cupertino") this would mean that I want the gap above this box to be 40% of the page height. In reality however, this equates to 40% of page's 'width'! If you make the page taller, the top margin, set to 40%, stays the same. Make it wider and the margin gets bigger, narrower - smaller! I originally assumed this was a browser error and reported my "Bug" to the "Masters of Such Things" (Latin for "Redmond"...), but the guys at Micro$oft informed me that this is the official spec as handed down from on high by the W3C. Sure enough[^], the powers that be state that:
Quote:
"Note that in a horizontal flow, percentages on ‘margin-top’ and ‘margin-bottom’ are relative to the width of the containing block, not the height (and in vertical flow, ‘margin-left’ and ‘margin-right’ are relative to the height, not the width)."
Ok, yes. But if you had a margin-top that was 10% of the height, then what is the height? Solve height = height * 1.1? Admittedly that problem still exists, if you combine two percentual margins that are not both the same orientation, and I have no idea what happens.
-
The one who has never used a table shall throw the first stone. Even the hamsters acknowledged using tables from time to time on this very site a few months ago.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Do not feed the troll ! - Common proverb
-
Nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!!!!!!!!!!!!!!!! [Edit] de-broke the formatting.
“Education is not the piling on of learning, information, data, facts, skills, or abilities - that's training or instruction - but is rather making visible what is hidden as a seed”
“One of the greatest problems of our time is that many are schooled but few are educated”Sir Thomas More (1478 – 1535)
In a discussion about using tables for formatting you should've left the formatting broken!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!11111!!!!111!oneoneonene11eleventyone11111111111111111111!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!111111111111111!!!!!!!!!!!!!!!!!!!11111111111111111isthisenoughtobreakityet1111111111111111111111111111111111111111111111111!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!elventyelventyeleventyone111111!!!!!!!!!!!bettermakesuresomepeoplehavereallybigscreens11111111111111111111111111111111111!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
In a discussion about using tables for formatting you should've left the formatting broken!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!11111!!!!111!oneoneonene11eleventyone11111111111111111111!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!111111111111111!!!!!!!!!!!!!!!!!!!11111111111111111isthisenoughtobreakityet1111111111111111111111111111111111111111111111111!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!elventyelventyeleventyone111111!!!!!!!!!!!bettermakesuresomepeoplehavereallybigscreens11111111111111111111111111111111111!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
PS Does anyone know why the message edit box only started stretching about 40 or 50 characters after my deliberate breakage "word" line wrapped.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
First off, I'm a web developer. Whilst I'm aware of my lowly position in the food chain I have to point out that I started my career writing ANSI C and assembler, so I've clawed my way up a couple of links. And I'm old... But I use Macs. There's just no helping some people. Anyway, I'm refactoring a web app I wrote a couple of years back, standard PHP / MySQL fare with a liberal sprinkling of JS on the front end. I'm condensing a load of pages down to a single page and squirting a blob of AJAX in there to grease the wheels. There are no frameworks of monolithic libraries, I prefer to roll my own. If you are still reading I'll assume you know roughly what I'm talking about and get to the point. I've laid out my page in a cascading information kind of styley. You click a pretty broad subject in box 'a' and this displays relevant options in box 'b'. Clicking an option then shows specific details in box 'c'. Noddy stuff. I need the content to scale with the page, so I use percentages, and I need a definable and consistent 'gutter' between the boxes, so I'm using absolute positioning. Here's a link to my page mockup[^]. If you resize this window you'll notice (unless you are using Safari of course) that everything goes a bit Pete Tong in the bottom left corner! To position this (red in my example) div, I use a 40% top margin. In a "logical world" (which is obviously latin for "Cupertino") this would mean that I want the gap above this box to be 40% of the page height. In reality however, this equates to 40% of page's 'width'! If you make the page taller, the top margin, set to 40%, stays the same. Make it wider and the margin gets bigger, narrower - smaller! I originally assumed this was a browser error and reported my "Bug" to the "Masters of Such Things" (Latin for "Redmond"...), but the guys at Micro$oft informed me that this is the official spec as handed down from on high by the W3C. Sure enough[^], the powers that be state that:
Quote:
"Note that in a horizontal flow, percentages on ‘margin-top’ and ‘margin-bottom’ are relative to the width of the containing block, not the height (and in vertical flow, ‘margin-left’ and ‘margin-right’ are relative to the height, not the width)."
-
Ok, yes. But if you had a margin-top that was 10% of the height, then what is the height? Solve height = height * 1.1? Admittedly that problem still exists, if you combine two percentual margins that are not both the same orientation, and I have no idea what happens.
But if you have an outer box of fixed height, say the client are of the browser window itself, then height = .1 * parentHeight. I think that would be better and is probably what is desired.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
The one who has never used a table shall throw the first stone. Even the hamsters acknowledged using tables from time to time on this very site a few months ago.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus Do not feed the troll ! - Common proverb
-
But if you have an outer box of fixed height, say the client are of the browser window itself, then height = .1 * parentHeight. I think that would be better and is probably what is desired.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert EinsteinExcept a fixed size container means you either have a scroll bar or wasted space. Fixing the size of something is almost never the correct answer in a browser environment, because you never know what size the user will have his window, and your layout should adapt intelligently to different choices.
-
Except a fixed size container means you either have a scroll bar or wasted space. Fixing the size of something is almost never the correct answer in a browser environment, because you never know what size the user will have his window, and your layout should adapt intelligently to different choices.
Hence the 40% varies with the size of the parent container.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
First off, I'm a web developer. Whilst I'm aware of my lowly position in the food chain I have to point out that I started my career writing ANSI C and assembler, so I've clawed my way up a couple of links. And I'm old... But I use Macs. There's just no helping some people. Anyway, I'm refactoring a web app I wrote a couple of years back, standard PHP / MySQL fare with a liberal sprinkling of JS on the front end. I'm condensing a load of pages down to a single page and squirting a blob of AJAX in there to grease the wheels. There are no frameworks of monolithic libraries, I prefer to roll my own. If you are still reading I'll assume you know roughly what I'm talking about and get to the point. I've laid out my page in a cascading information kind of styley. You click a pretty broad subject in box 'a' and this displays relevant options in box 'b'. Clicking an option then shows specific details in box 'c'. Noddy stuff. I need the content to scale with the page, so I use percentages, and I need a definable and consistent 'gutter' between the boxes, so I'm using absolute positioning. Here's a link to my page mockup[^]. If you resize this window you'll notice (unless you are using Safari of course) that everything goes a bit Pete Tong in the bottom left corner! To position this (red in my example) div, I use a 40% top margin. In a "logical world" (which is obviously latin for "Cupertino") this would mean that I want the gap above this box to be 40% of the page height. In reality however, this equates to 40% of page's 'width'! If you make the page taller, the top margin, set to 40%, stays the same. Make it wider and the margin gets bigger, narrower - smaller! I originally assumed this was a browser error and reported my "Bug" to the "Masters of Such Things" (Latin for "Redmond"...), but the guys at Micro$oft informed me that this is the official spec as handed down from on high by the W3C. Sure enough[^], the powers that be state that:
Quote:
"Note that in a horizontal flow, percentages on ‘margin-top’ and ‘margin-bottom’ are relative to the width of the containing block, not the height (and in vertical flow, ‘margin-left’ and ‘margin-right’ are relative to the height, not the width)."
Actually what is means by horizontal flow is describing a situation when dealing with elements that are taken out of the natural vertical flow having been given the display value
inline, absolute position, or are floated. They do not have a block height somargin-topandmargin-bottomis not easily calculable. Your issues are brought about because you have no calculated height to work from since there are no vertically flowing elements on the page. I'm actually having trouble finding a reason why you are using absolute position for rendering a layout like this. The guttering can be defined using a transparent border and the only thing I have found is that you have a specific gap set between the top-left and bottom-left panes so I would use absolute position for that if required (You could also use a spacer div). I've knocked up a quick demo of how I would go about rendering your layout. Demo http://jsfiddle.net/nLmBy/2/[^] Fullscreen http://jsfiddle.net/nLmBy/2/embedded/result/[^] I was able to test it in Chrome, Firefox and IE9/IE10 It should work for IE8 and IE7 once you add a html5 shiv since they wont render your nav. You may need to tweak it though. There are a few html changes but one is correcting your nav layout and the other is a div just acting as a wrapper. On your note of monolithic libraries, I actually believe that you are incorrect in your premise. The latest jQuery libraries minified and gzipped are only around 30kb in size. A single image would be bigger and you would have normalized countless cross browser issues by including it. If you are insistent on rolling your own code though at least follow best practise and use event handlers rather than peppering your html with inline JavaScript. Continuing the way you have will present a maintenance nightmare. Anyway I hope this helps and clears things up a bit :)JimBob SquarePants ******************************************************************* "He took everything personally, including our royalties!" David St.Hubbins, Spinal Tap about Ian Faith, their ex-manager *******************************************************************
-
Actually what is means by horizontal flow is describing a situation when dealing with elements that are taken out of the natural vertical flow having been given the display value
inline, absolute position, or are floated. They do not have a block height somargin-topandmargin-bottomis not easily calculable. Your issues are brought about because you have no calculated height to work from since there are no vertically flowing elements on the page. I'm actually having trouble finding a reason why you are using absolute position for rendering a layout like this. The guttering can be defined using a transparent border and the only thing I have found is that you have a specific gap set between the top-left and bottom-left panes so I would use absolute position for that if required (You could also use a spacer div). I've knocked up a quick demo of how I would go about rendering your layout. Demo http://jsfiddle.net/nLmBy/2/[^] Fullscreen http://jsfiddle.net/nLmBy/2/embedded/result/[^] I was able to test it in Chrome, Firefox and IE9/IE10 It should work for IE8 and IE7 once you add a html5 shiv since they wont render your nav. You may need to tweak it though. There are a few html changes but one is correcting your nav layout and the other is a div just acting as a wrapper. On your note of monolithic libraries, I actually believe that you are incorrect in your premise. The latest jQuery libraries minified and gzipped are only around 30kb in size. A single image would be bigger and you would have normalized countless cross browser issues by including it. If you are insistent on rolling your own code though at least follow best practise and use event handlers rather than peppering your html with inline JavaScript. Continuing the way you have will present a maintenance nightmare. Anyway I hope this helps and clears things up a bit :)JimBob SquarePants ******************************************************************* "He took everything personally, including our royalties!" David St.Hubbins, Spinal Tap about Ian Faith, their ex-manager *******************************************************************
Cheers for the reply JimBob, Thanks for the comments, and I'll address them in order. Surely an absolutely positioned element would be more likely to have block height than a relatively positioned one. My placement of the divs was pretty specific, giving top, left, right and bottom coordinates (in most cases). The only dimensions to be calculated by the browser, specifically for the bottom left (red) element, were its overall height (set to auto) and the amount of space above it - the dreaded percentage. Given that the browser knows, and is the only thing that can know, the overall height of the user's window, calculating these two fundamental values should be a snip... Either way, if it can't get the height of "something or other", for whatever reason, grabbing some other unrelated value and using that instead just seems ludicrous to me - and hence my post. I use absolute positioning in this page because I needed three boxes to grow and shrink with the content area, and to have constant and definable gaps between them. As the main elements fill the page completely and do not overlap, it was by far the easiest way to go in this instance. Apart from tables, obviously! :laugh: Thanks for the Demo, but it doesn't work correctly in Safari, Chrome or Firefox. I didn't test it in IE. All divs should expand and contract to fill the content area (minus the tabs), but your code doesn't scale vertically in any browser I tested it in. jQuery... I appreciate what you say, but it seems to be the vogue these days to throw jQuery in to every project you create. 30k is admittedly less than many web graphics, but how much of that 30k is actually used by the average page? Primarily, jQuery provides shortcuts for low level DOM manipulation. I would rather handle that manipulation myself in a way that is specific to my particular needs at the time, cutting about 29.8k out of my page size into the bargain! It does provide some built in browser hacks and other niceties, but I prefer to take the KISS approach to layout. The simplest way is generally the best in the long run, and sticking to standards compliant, concise code normally does the trick. Unless you want to use percentages of course... Your point about the inline JS is a good one, but this was just a page mockup to test the layout, and not production code. I'll pretty it up before I ship ;)
-
Cheers for the reply JimBob, Thanks for the comments, and I'll address them in order. Surely an absolutely positioned element would be more likely to have block height than a relatively positioned one. My placement of the divs was pretty specific, giving top, left, right and bottom coordinates (in most cases). The only dimensions to be calculated by the browser, specifically for the bottom left (red) element, were its overall height (set to auto) and the amount of space above it - the dreaded percentage. Given that the browser knows, and is the only thing that can know, the overall height of the user's window, calculating these two fundamental values should be a snip... Either way, if it can't get the height of "something or other", for whatever reason, grabbing some other unrelated value and using that instead just seems ludicrous to me - and hence my post. I use absolute positioning in this page because I needed three boxes to grow and shrink with the content area, and to have constant and definable gaps between them. As the main elements fill the page completely and do not overlap, it was by far the easiest way to go in this instance. Apart from tables, obviously! :laugh: Thanks for the Demo, but it doesn't work correctly in Safari, Chrome or Firefox. I didn't test it in IE. All divs should expand and contract to fill the content area (minus the tabs), but your code doesn't scale vertically in any browser I tested it in. jQuery... I appreciate what you say, but it seems to be the vogue these days to throw jQuery in to every project you create. 30k is admittedly less than many web graphics, but how much of that 30k is actually used by the average page? Primarily, jQuery provides shortcuts for low level DOM manipulation. I would rather handle that manipulation myself in a way that is specific to my particular needs at the time, cutting about 29.8k out of my page size into the bargain! It does provide some built in browser hacks and other niceties, but I prefer to take the KISS approach to layout. The simplest way is generally the best in the long run, and sticking to standards compliant, concise code normally does the trick. Unless you want to use percentages of course... Your point about the inline JS is a good one, but this was just a page mockup to test the layout, and not production code. I'll pretty it up before I ship ;)
Greetings from another old web developer :) I started out in realtime concurrent :-D Good luck getting this sorted out. I do have to admit I have occasionally punted and thrown a table in to make a deadline :-D
-
First off, I'm a web developer. Whilst I'm aware of my lowly position in the food chain I have to point out that I started my career writing ANSI C and assembler, so I've clawed my way up a couple of links. And I'm old... But I use Macs. There's just no helping some people. Anyway, I'm refactoring a web app I wrote a couple of years back, standard PHP / MySQL fare with a liberal sprinkling of JS on the front end. I'm condensing a load of pages down to a single page and squirting a blob of AJAX in there to grease the wheels. There are no frameworks of monolithic libraries, I prefer to roll my own. If you are still reading I'll assume you know roughly what I'm talking about and get to the point. I've laid out my page in a cascading information kind of styley. You click a pretty broad subject in box 'a' and this displays relevant options in box 'b'. Clicking an option then shows specific details in box 'c'. Noddy stuff. I need the content to scale with the page, so I use percentages, and I need a definable and consistent 'gutter' between the boxes, so I'm using absolute positioning. Here's a link to my page mockup[^]. If you resize this window you'll notice (unless you are using Safari of course) that everything goes a bit Pete Tong in the bottom left corner! To position this (red in my example) div, I use a 40% top margin. In a "logical world" (which is obviously latin for "Cupertino") this would mean that I want the gap above this box to be 40% of the page height. In reality however, this equates to 40% of page's 'width'! If you make the page taller, the top margin, set to 40%, stays the same. Make it wider and the margin gets bigger, narrower - smaller! I originally assumed this was a browser error and reported my "Bug" to the "Masters of Such Things" (Latin for "Redmond"...), but the guys at Micro$oft informed me that this is the official spec as handed down from on high by the W3C. Sure enough[^], the powers that be state that:
Quote:
"Note that in a horizontal flow, percentages on ‘margin-top’ and ‘margin-bottom’ are relative to the width of the containing block, not the height (and in vertical flow, ‘margin-left’ and ‘margin-right’ are relative to the height, not the width)."
Add min-width and min-height. See bold elements.
#bl {
position: absolute;
height: auto;
min-height:10%;
width: 40%;
** min-width:10%;**
left: 42px;
top: 4px;
right: auto;
bottom: 2px;
background-color: #900;
padding: 0px;
margin: 40% 0px 0px;
float: left;
z-index: 150;
} -
First off, I'm a web developer. Whilst I'm aware of my lowly position in the food chain I have to point out that I started my career writing ANSI C and assembler, so I've clawed my way up a couple of links. And I'm old... But I use Macs. There's just no helping some people. Anyway, I'm refactoring a web app I wrote a couple of years back, standard PHP / MySQL fare with a liberal sprinkling of JS on the front end. I'm condensing a load of pages down to a single page and squirting a blob of AJAX in there to grease the wheels. There are no frameworks of monolithic libraries, I prefer to roll my own. If you are still reading I'll assume you know roughly what I'm talking about and get to the point. I've laid out my page in a cascading information kind of styley. You click a pretty broad subject in box 'a' and this displays relevant options in box 'b'. Clicking an option then shows specific details in box 'c'. Noddy stuff. I need the content to scale with the page, so I use percentages, and I need a definable and consistent 'gutter' between the boxes, so I'm using absolute positioning. Here's a link to my page mockup[^]. If you resize this window you'll notice (unless you are using Safari of course) that everything goes a bit Pete Tong in the bottom left corner! To position this (red in my example) div, I use a 40% top margin. In a "logical world" (which is obviously latin for "Cupertino") this would mean that I want the gap above this box to be 40% of the page height. In reality however, this equates to 40% of page's 'width'! If you make the page taller, the top margin, set to 40%, stays the same. Make it wider and the margin gets bigger, narrower - smaller! I originally assumed this was a browser error and reported my "Bug" to the "Masters of Such Things" (Latin for "Redmond"...), but the guys at Micro$oft informed me that this is the official spec as handed down from on high by the W3C. Sure enough[^], the powers that be state that:
Quote:
"Note that in a horizontal flow, percentages on ‘margin-top’ and ‘margin-bottom’ are relative to the width of the containing block, not the height (and in vertical flow, ‘margin-left’ and ‘margin-right’ are relative to the height, not the width)."
If the standard says so (even if it's crazy), then Apple is the culprit for no following it, this remembers me the much hated "Best Viewed on Internet Explorer" badge...
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Cheers for the reply JimBob, Thanks for the comments, and I'll address them in order. Surely an absolutely positioned element would be more likely to have block height than a relatively positioned one. My placement of the divs was pretty specific, giving top, left, right and bottom coordinates (in most cases). The only dimensions to be calculated by the browser, specifically for the bottom left (red) element, were its overall height (set to auto) and the amount of space above it - the dreaded percentage. Given that the browser knows, and is the only thing that can know, the overall height of the user's window, calculating these two fundamental values should be a snip... Either way, if it can't get the height of "something or other", for whatever reason, grabbing some other unrelated value and using that instead just seems ludicrous to me - and hence my post. I use absolute positioning in this page because I needed three boxes to grow and shrink with the content area, and to have constant and definable gaps between them. As the main elements fill the page completely and do not overlap, it was by far the easiest way to go in this instance. Apart from tables, obviously! :laugh: Thanks for the Demo, but it doesn't work correctly in Safari, Chrome or Firefox. I didn't test it in IE. All divs should expand and contract to fill the content area (minus the tabs), but your code doesn't scale vertically in any browser I tested it in. jQuery... I appreciate what you say, but it seems to be the vogue these days to throw jQuery in to every project you create. 30k is admittedly less than many web graphics, but how much of that 30k is actually used by the average page? Primarily, jQuery provides shortcuts for low level DOM manipulation. I would rather handle that manipulation myself in a way that is specific to my particular needs at the time, cutting about 29.8k out of my page size into the bargain! It does provide some built in browser hacks and other niceties, but I prefer to take the KISS approach to layout. The simplest way is generally the best in the long run, and sticking to standards compliant, concise code normally does the trick. Unless you want to use percentages of course... Your point about the inline JS is a good one, but this was just a page mockup to test the layout, and not production code. I'll pretty it up before I ship ;)
Hi Danny, Ah right, I missed that it was supposed to resize vertically. Setting a max-height:100%; on the body will fix that. Updated Demo: http://jsfiddle.net/nLmBy/4/[^] The fullscreen demo doesn't work as jsfiddle insists on fixing the height on the parent iframe. You can see the effect though by resizing the pane in the working version. Yeah... You'd think it should be easy enough but as far as I can figure (and reading that spec is a challenge) some of the values reset to 0 in certain circumstances under absolute positioning. The box model has historically been a mess for browser interpretation anyway. I do see where you are coming from with regards to the KISS approach and if you can ensure that your JavaScript is cross browser compatible then go for it. I prefer not to spend my time testing that though, especially if thousands of developers have already tested something like jQuery for oddities in Ajax requests etc. Anyhoo, I hope you're making good progress. :)
JimBob SquarePants ******************************************************************* "He took everything personally, including our royalties!" David St.Hubbins, Spinal Tap about Ian Faith, their ex-manager *******************************************************************
-
Hi Danny, Ah right, I missed that it was supposed to resize vertically. Setting a max-height:100%; on the body will fix that. Updated Demo: http://jsfiddle.net/nLmBy/4/[^] The fullscreen demo doesn't work as jsfiddle insists on fixing the height on the parent iframe. You can see the effect though by resizing the pane in the working version. Yeah... You'd think it should be easy enough but as far as I can figure (and reading that spec is a challenge) some of the values reset to 0 in certain circumstances under absolute positioning. The box model has historically been a mess for browser interpretation anyway. I do see where you are coming from with regards to the KISS approach and if you can ensure that your JavaScript is cross browser compatible then go for it. I prefer not to spend my time testing that though, especially if thousands of developers have already tested something like jQuery for oddities in Ajax requests etc. Anyhoo, I hope you're making good progress. :)
JimBob SquarePants ******************************************************************* "He took everything personally, including our royalties!" David St.Hubbins, Spinal Tap about Ian Faith, their ex-manager *******************************************************************
That's better JimBob, but see how the gutter between the two divs to the left changes? My intention is to make this 'gap' a toolbar, so it needs to be consistent. It's virtually impossible to achieve this in pure CSS3 without the use of margin-top. Trust me, I've tried... You can do it with a table (as has been suggested elsewhere on this post), and that's got to be the easiest approach. You can also do it in JS. Attaching a resizing handler and setting the size of margin-top for the red div to the current height of the top left div (which is what my original code should have done) would give the required result, at the expense of a bit of lag / flicker. By setting the margin of the lower div to the height of the top one, then offsetting 'top' by the height of the toolbar space provides the consistency. The whole CSS model seems to be a bit up in the air to be fair. I'm just hoping that with the renewed interest in the web as an application environment we will (eventually) see a unified, cross the board standard. I won't be holding my breath just yet though...