Hi
I'm learning to use the DIV tag and am having some problems dividing a
page into two horizontal sections.
I want a div area that goes across the top of the page (which I can
get to work), then two sections that sit next to each other and go all
the way to the bottom of the page.
How do I get two div sections to sit next to each other horizontally?
Thanks
On Sep 25, 3:05 am, ben_camero...@hotmail.com wrote:
> Hi
>
> I'm learning to use the DIV tag and am having some problems dividing a
> page into two horizontal sections.
>
> I want a div area that goes across the top of the page (which I can
> get to work), then two sections that sit next to each other and go all
> the way to the bottom of the page.
>
> How do I get two div sections to sit next to each other horizontally?
>
> Thanks
Using cascading Style Sheets (CSS) the divs can be positioned
absolute...
We can also fix the height and width of the div using CSS..
On 24 Sep, 23:05, ben_camero...@hotmail.com wrote:
> How do I get two div sections to sit next to each other horizontally?
Use the CSS property "float"
This is harder to use correctly and well than you might imagine. In
particular, "floating" is easy, but tidying things up afterwards can
be surprising. It's not hard, but you do need to learn some background
first. The tutorial at http://brainjar.com/css/positioning/ is good,
accurate and readable.
Design your pages with a good and accurate browser such as Firefox
first, because IE has many bugs in this area. You can make IE-
compatible and cross-browser pages easily enough, but start from the
"correct" case and make it work for IE. Hacking it up to look right
for IE first, and then trying to fix it, is harder.
Don't believe anything you read on w3schools - much is wrong, bad
practice, obsolete, or at best poorly written.
Don't use absolue positioning. Avoid pixel dimensions. Either of these
make for pages that are inflexible and non-fluid. You might use either
technique at times, but beginners especially should avoid them as
being the technique of first choice.
Well bust mah britches and call me cheeky, on Mon, 24 Sep 2007 22:05:21 GMT
scribed:
> Hi
>
> I'm learning to use the DIV tag and am having some problems dividing a
> page into two horizontal sections.
>
> I want a div area that goes across the top of the page (which I can
> get to work), then two sections that sit next to each other and go all
> the way to the bottom of the page.
>
> How do I get two div sections to sit next to each other horizontally?
I subscribe to Andy's well-presented opinion on the matter. However, divs
don't go "all the way to the bottom of the page" if the content is
insufficient unless the author does something which is usually wrong.
That's a fact to bear in mind particularly when considering backgrounds.
--
Neredbojias
Half lies are worth twice as much as whole lies.
"Neredbojias"
news:Xns99B626D13FC8nanopandaneredbojias@198.186.190.161...
> Well bust mah britches and call me cheeky, on Mon, 24 Sep 2007 22:05:21
> GMT
> scribed:
>
>> Hi
>>
>> I'm learning to use the DIV tag and am having some problems dividing a
>> page into two horizontal sections.
>>
>> I want a div area that goes across the top of the page (which I can
>> get to work), then two sections that sit next to each other and go all
>> the way to the bottom of the page.
>>
>> How do I get two div sections to sit next to each other horizontally?
>
> I subscribe to Andy's well-presented opinion on the matter. However, divs
> don't go "all the way to the bottom of the page" if the content is
> insufficient unless the author does something which is usually wrong.
> That's a fact to bear in mind particularly when considering backgrounds.
Further, what exactly is the "page"?
Usually, with a really simple HTML file, it is the end of that HTML file.
The bottom of the "content". Where the browser stops scrolling when one
leans on ones page down button, because said browser can't go down any more.
There is nothing further. Therebelow lie dragons.
However if one distrupts the usual content flow by introducing floated
elements or
totally loses the concept of the "page".
Where is the bottom of the "page" for a floated element? The bottom of the
element? The bottom of the surrounding content?
Where is the bottom of the "page" for an absolutely positioned div element?
Where is the bottom of the "page" for an absolutely positioned div element
where top: 1000px; has been specified? (try it and see, you will need to
scroll down). Indeed if that element is the only one in the body of the
HTML file where is the "top" of the "page"? Pixel 0 or pixel 1000?
Hint: We don't actually know.
The best we can guess is that, after the browser has done its best to lay
out the content, after due consideration to these floated and positioned
elements, the bottom of the page is where there is nothing more. That is,
the browser does not need to draw anything below this point. You have
reached the end of the scroll bar. And no, there is no CSS property to
position something at the end of the scroll bar, least of all the bottom of
an element :-)
In any case HTML files do not describe "pages". They describe content, with
CSS to pretty that content. The browser lays out the elements containing the
content as it sees fit, with the CSS taken into account. Why should we ask
more? "Page" is for print, not web.
Ah, but I see I have just upset a considerable number of graphic artists who
think they are web drezigners ;-)
OP: Why do you need to divide your content into two sections side by side?
There are a [google] number of ways to do this. Show your best effort.
--
Richard
Well bust mah britches and call me cheeky, on Tue, 25 Sep 2007 11:59:43
GMT rf scribed:
>>> How do I get two div sections to sit next to each other
>>> horizontally?
>>
>> I subscribe to Andy's well-presented opinion on the matter. However,
>> divs don't go "all the way to the bottom of the page" if the content
>> is insufficient unless the author does something which is usually
>> wrong. That's a fact to bear in mind particularly when considering
>> backgrounds.
>
> Further, what exactly is the "page"?
>
> Usually, with a really simple HTML file, it is the end of that HTML
> file. The bottom of the "content". Where the browser stops scrolling
> when one leans on ones page down button, because said browser can't go
> down any more. There is nothing further. Therebelow lie dragons.
>
> However if one distrupts the usual content flow by introducing floated
> elements or
> one totally loses the concept of the "page".
>
> Where is the bottom of the "page" for a floated element? The bottom of
> the element? The bottom of the surrounding content?
>
> Where is the bottom of the "page" for an absolutely positioned div
> element?
>
> Where is the bottom of the "page" for an absolutely positioned div
> element where top: 1000px; has been specified? (try it and see, you
> will need to scroll down). Indeed if that element is the only one in
> the body of the HTML file where is the "top" of the "page"? Pixel 0 or
> pixel 1000?
>
> Hint: We don't actually know.
>
> The best we can guess is that, after the browser has done its best to
> lay out the content, after due consideration to these floated and
> positioned elements, the bottom of the page is where there is nothing
> more. That is, the browser does not need to draw anything below this
> point. You have reached the end of the scroll bar. And no, there is no
> CSS property to position something at the end of the scroll bar, least
> of all the bottom of an element :-)
>
> In any case HTML files do not describe "pages". They describe content,
> with CSS to pretty that content. The browser lays out the elements
> containing the content as it sees fit, with the CSS taken into
> account. Why should we ask more? "Page" is for print, not web.
>
> Ah, but I see I have just upset a considerable number of graphic
> artists who think they are web drezigners ;-)
Yeah, I agree. Page is at most an inexact concept when it comes to The
Web. What you really have is a "set of content" which may contain
subsets and elements therein. How these elements relate to one another
in a visual and particularly semantic fashion for the non-visual
interpreter is what web page design is about, not the physically-limited
methods typically applied to print. That's why "fixed" web design stands
out as being poor while a smoothly-flowing, adeptly-integrated page seems
so intrinsically "right" and attractive.
So-called designers who brag about the looks of their static page are
really just saying that one frame in a movie appears nicely rendered.
The rest of the movie sucks, but that isn't their worry because they are
too dense to understand it.
--
Neredbojias
Half lies are worth twice as much as whole lies.
On Sep 26, 6:37 pm, Neredbojias
> Well bust mah britches and call me cheeky, on Tue, 25 Sep 2007 11:59:43
> GMT rf scribed:
>
>
>
>
>
> >>> How do I get two div sections to sit next to each other
> >>> horizontally?
>
> >> I subscribe to Andy's well-presented opinion on the matter. However,
> >> divs don't go "all the way to the bottom of the page" if the content
> >> is insufficient unless the author does something which is usually
> >> wrong. That's a fact to bear in mind particularly when considering
> >> backgrounds.
>
> > Further, what exactly is the "page"?
>
> > Usually, with a really simple HTML file, it is the end of that HTML
> > file. The bottom of the "content". Where the browser stops scrolling
> > when one leans on ones page down button, because said browser can't go
> > down any more. There is nothing further. Therebelow lie dragons.
>
> > However if one distrupts the usual content flow by introducing floated
> > elements or
> > one totally loses the concept of the "page".
>
> > Where is the bottom of the "page" for a floated element? The bottom of
> > the element? The bottom of the surrounding content?
>
> > Where is the bottom of the "page" for an absolutely positioned div
> > element?
>
> > Where is the bottom of the "page" for an absolutely positioned div
> > element where top: 1000px; has been specified? (try it and see, you
> > will need to scroll down). Indeed if that element is the only one in
> > the body of the HTML file where is the "top" of the "page"? Pixel 0 or
> > pixel 1000?
>
> > Hint: We don't actually know.
>
> > The best we can guess is that, after the browser has done its best to
> > lay out the content, after due consideration to these floated and
> > positioned elements, the bottom of the page is where there is nothing
> > more. That is, the browser does not need to draw anything below this
> > point. You have reached the end of the scroll bar. And no, there is no
> > CSS property to position something at the end of the scroll bar, least
> > of all the bottom of an element :-)
>
> > In any case HTML files do not describe "pages". They describe content,
> > with CSS to pretty that content. The browser lays out the elements
> > containing the content as it sees fit, with the CSS taken into
> > account. Why should we ask more? "Page" is for print, not web.
>
> > Ah, but I see I have just upset a considerable number of graphic
> > artists who think they are web drezigners ;-)
>
> Yeah, I agree. Page is at most an inexact concept when it comes to The
> Web. What you really have is a "set of content" which may contain
> subsets and elements therein. How these elements relate to one another
> in a visual and particularly semantic fashion for the non-visual
> interpreter is what web page design is about, not the physically-limited
> methods typically applied to print. That's why "fixed" web design stands
> out as being poor while a smoothly-flowing, adeptly-integrated page seems
> so intrinsically "right" and attractive.
>
> So-called designers who brag about the looks of their static page are
> really just saying that one frame in a movie appears nicely rendered.
> The rest of the movie sucks, but that isn't their worry because they are
> too dense to understand it.
>
> --
> Neredbojias
> Half lies are worth twice as much as whole lies.- Hide quoted text -
>
> - Show quoted text -
I don't really have a best effort yet. I'm looking at changing some
old pages that use table style layout to use div's instead so I'm just
starting to think about how to go about this.
In this context when I say 'page' I'm just thinking about the
structure of the page and not any content. For example I'm thinking of
an area to place a title header, a space to place a menu down the left
hand side, and main content area on the right hand side. I'm more
thinking about the structure of the page instead of the content.
Yes I also aggree with your thoughts about using a fluid layout
instead of static layouts.
Thanks for your thoughts guys.
On Sep 25, 9:13 pm, Andy Dingley
> On 24 Sep, 23:05, ben_camero...@hotmail.com wrote:
>
> > How do I get two div sections to sit next to each other horizontally?
>
> Use the CSS property "float"
>
> This is harder to use correctly and well than you might imagine. In
> particular, "floating" is easy, but tidying things up afterwards can
> be surprising. It's not hard, but you do need to learn some background
> first. The tutorial athttp://brainjar.com/css/positioning/is good,
> accurate and readable.
>
> Design your pages with a good and accurate browser such as Firefox
> first, because IE has many bugs in this area. You can make IE-
> compatible and cross-browser pages easily enough, but start from the
> "correct" case and make it work for IE. Hacking it up to look right
> for IE first, and then trying to fix it, is harder.
>
> Don't believe anything you read on w3schools - much is wrong, bad
> practice, obsolete, or at best poorly written.
>
> Don't use absolue positioning. Avoid pixel dimensions. Either of these
> make for pages that are inflexible and non-fluid. You might use either
> technique at times, but beginners especially should avoid them as
> being the technique of first choice.
I've checked out the given tutorial, its very good, thanks.
Well bust mah britches and call me cheeky, on Wed, 26 Sep 2007 08:36:17
GMT Sems scribed:
> I don't really have a best effort yet. I'm looking at changing some
> old pages that use table style layout to use div's instead so I'm just
> starting to think about how to go about this.
This typically means utilizing css. A page should be "outlined" as
logically as possible using applicable html semantic markup, but (and
although some will say otherwise) css is really essential for layout beyond
its supposedly presentational-only purpose. Learn it well and you can
decide for yourself in what category of truthfulness the dogma belongs.
> In this context when I say 'page' I'm just thinking about the
> structure of the page and not any content. For example I'm thinking of
> an area to place a title header, a space to place a menu down the left
> hand side, and main content area on the right hand side. I'm more
> thinking about the structure of the page instead of the content.
>
> Yes I also aggree with your thoughts about using a fluid layout
> instead of static layouts.
A static page can be functional but a well-designed fluid page has so much
more advantage.
> Thanks for your thoughts guys.
--
Neredbojias
Half lies are worth twice as much as whole lies.
On 2007-09-25, rf
[...]
> Further, what exactly is the "page"?
There is the viewport, and the dimensions of the root element. If the
latter is bigger than the former, the browser gives you scrollbars.
The root element what most people mean by the "page".
Actually you can prevent the scrollbars if you really want to by an
obscure incantation that effectively sets overflow on the viewport:
UAs must apply the 'overflow' property set on the root element to the
viewport. HTML UAs must instead apply the 'overflow' property from
the BODY element to the viewport, if the value on the HTML element is
'visible'. The 'visible' value when used for the viewport must be
interpreted as 'auto'. The element from which the value is propagated
must have a used value for 'overflow' of 'visible'.
What all that means is that if you set overflow:visible on HTML and
overflow:hidden on BODY then you should get overflow:hidden on the
viewport and not be able to scroll to things that don't fit in it. I'm
sure that'll come in useful one day.
You can even supposedly make the viewport overflow:visible, but it does
say that might not work (depending on the "native operating
environment").
> Usually, with a really simple HTML file, it is the end of that HTML file.
> The bottom of the "content". Where the browser stops scrolling when one
> leans on ones page down button, because said browser can't go down any more.
> There is nothing further. Therebelow lie dragons.
>
> However if one distrupts the usual content flow by introducing floated
> elements or
> totally loses the concept of the "page".
The root element ("page") is a block formatting context so grows in
height to fit the floats in.
> Where is the bottom of the "page" for a floated element? The bottom of the
> element? The bottom of the surrounding content?
Whichever's lower.
> Where is the bottom of the "page" for an absolutely positioned div
> element?
Now here things do get a bit fishy. The root element grows in size to
the bounding box of all the absolutely positioned things as well. I
don't know where/if that's specified.
> Where is the bottom of the "page" for an absolutely positioned div element
> where top: 1000px; has been specified? (try it and see, you will need to
> scroll down). Indeed if that element is the only one in the body of the
> HTML file where is the "top" of the "page"? Pixel 0 or pixel 1000?
Pixel 0 is the top, Pixel 1000 + height of the div is the bottom. +/-1
here and there.
> Hint: We don't actually know.
>
> The best we can guess is that, after the browser has done its best to lay
> out the content, after due consideration to these floated and positioned
> elements, the bottom of the page is where there is nothing more.
I think that's right. Note that the left and right edges of the root
element can also get pushed out by absolutely positioned elements.
[...]
> In any case HTML files do not describe "pages". They describe content, with
> CSS to pretty that content. The browser lays out the elements containing the
> content as it sees fit, with the CSS taken into account. Why should we ask
> more? "Page" is for print, not web.
OK, but "root element" = "page" pretty much.