Got a page with a frameset containing two frames (frame 0 and frame 1). The page in the top frames (frame 0) has links and each link calls the same JavaScript function parsing a different value. I want the bottom frame page (frame 1) to have its background colour set to the parsed value. My problem is, within the JavaScript function; window.parent.frames[1].document.bgColor = "#xxxxxx" Will change the bgcolor but I have since gotten round to implementing css. Now this won't change the bgcolor because of the css use of background-color. However; window.parent.frames[1].document.style.backgroundcolor = "#xxxxxx"; Doesn't change the background color. Internet Explorer shows me this error: 'window.parent.frames.1.document.style' is null or not an object I'm stumped? Any advice would be greatly appreciated! -- Regards, James ;) Charles de Gaulle - "The better I get to know men, the more I find myself loving dogs." - http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html
Firstly, can I just say "Frames? Urgggh". More helpfully, can I suggest using a toolkit to abstract out some of the browser differences. My current favourite is JQuery - I can't check right now, but I'm sure it has something to make what you're doing much easier. Greg On Sunday, February 14, 2010, James Bensley <jwbensley@gmail.com> wrote:
Got a page with a frameset containing two frames (frame 0 and frame 1). The page in the top frames (frame 0) has links and each link calls the same JavaScript function parsing a different value. I want the bottom frame page (frame 1) to have its background colour set to the parsed value.
My problem is, within the JavaScript function; window.parent.frames[1].document.bgColor = "#xxxxxx"
Will change the bgcolor but I have since gotten round to implementing css. Now this won't change the bgcolor because of the css use of background-color.
However;
window.parent.frames[1].document.style.backgroundcolor = "#xxxxxx";
Doesn't change the background color. Internet Explorer shows me this error:
'window.parent.frames.1.document.style' is null or not an object
I'm stumped? Any advice would be greatly appreciated!
-- Regards, James ;)
Charles de Gaulle - "The better I get to know men, the more I find myself loving dogs." - http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
James Bensley wrote:
Got a page with a frameset containing two frames (frame 0 and frame 1). I have since gotten round to implementing css. Now this won't change the bgcolor because of the css use of background-color.
window.parent.frames[1].document.style.backgroundcolor = "#xxxxxx"; Doesn't change the background color. Internet Explorer shows me this error: 'window.parent.frames.1.document.style' is null or not an object
It's because the document itself is not a style-able object (it has no visible/presentation properties). You need to access the body and style it directly, i.e. ...document.body.style.backgroundColor = "#xxxxxx"; However, I'm duty-bound to say... Frames??! Hth, Simon -- ====================================================================== Simon Ransome http://nosher.net Photo RSS Feed: http://nosher.net/images/images.rss
On Mon, 2010-02-15 at 09:50 +0000, Simon Ransome wrote:
However, I'm duty-bound to say... Frames??!
Is there any technique for presenting multi-column output that does not have some problem? Frames, you say are out. I've seem recommendations elsewhere not to use tables a layout tool but only for real tables of data because using them for layout is reputed to confuse screen readers. There is a technique that seems to put content into floating objects but this has the drawback that when the window gets shrunk to a smaller size than the designer had in mind instead of degrading gracefully, for example by wrapping text that would otherwise have been on one line, objects get drawn on top of each other making the whole thing an unreadable mess. Steve.
On 15/02/10 14:53, Steve Fosdick wrote:
I've seem recommendations elsewhere not to use tables a layout tool but only for real tables of data because using them for layout is reputed to confuse screen readers.
We were debating this in the office today (without satisfactory conclusions). A fairly typical website design has a header, a footer, and the bit between the two split vertically to give a menu on the left and content on the right. Is there a way in CSS to do this simply so that the layout is adhered to regardless of the content of the four "panes"? With tables this is trivial, but every CSS design I've seen seems to work fine until (eg) the content pane has enough content in it to reach the bottom of the left hand menu, then it wraps below the menu, or all the content drops below the menu, or something else weird happens. I think part of the problem is that with CSS it seems quite easy to apply a style to some of the content that breaks the page layout in ways that would be impossible when it is constrained inside a table cell. Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG
On 15 Feb 15:01, Mark Rogers wrote:
On 15/02/10 14:53, Steve Fosdick wrote:
I've seem recommendations elsewhere not to use tables a layout tool but only for real tables of data because using them for layout is reputed to confuse screen readers.
We were debating this in the office today (without satisfactory conclusions).
A fairly typical website design has a header, a footer, and the bit between the two split vertically to give a menu on the left and content on the right.
Is there a way in CSS to do this simply so that the layout is adhered to regardless of the content of the four "panes"? With tables this is trivial, but every CSS design I've seen seems to work fine until (eg) the content pane has enough content in it to reach the bottom of the left hand menu, then it wraps below the menu, or all the content drops below the menu, or something else weird happens.
Usual method round that is to float menu to left, content to right, wrap them in a containing div, and have one more div in there that is basically just a clear: both; so that the footer kicks in in the right place (though, you can just make that div the footer and have done with it :) So you end up with a div layout like: +---------------------------+ | HEADER | +---------------------------+ |+----++-------------------+| ||MENU||CONTENT || || || || || || || |+----+| || | | || | +-------------------+| |+-------------------------+| || FOOTER || |+-------------------------+| +---------------------------+ (Yeah - OK - I know my ASCII art skills suck, but that should give a reasonable idea.)
I think part of the problem is that with CSS it seems quite easy to apply a style to some of the content that breaks the page layout in ways that would be impossible when it is constrained inside a table cell.
Well, you can transcribe a div layout in to a table layout *IF* you forget about interwebnets exploder, as the css spec allows you to do that with the display attribute (IIRC). Damn I've been in this business too long ;) -- Brett Parker
On 15/02/10 15:11, Brett Parker wrote:
Usual method round that is to float menu to left, content to right, wrap them in a containing div, and have one more div in there that is basically just a clear: both; so that the footer kicks in in the right place (though, you can just make that div the footer and have done with it :)
Thanks for confirming what I thought! I went looking at the code causing a problem and found all sorts of bodges in the CSS, which having stripped most of them out I did make everything work. One problem seems still to be that I have to fix the MENU and CONTENT widths. Otherwise, if the CONTENT pane is fixed width as a result of its content (eg if it comprises only a fixed width table) the entire CONTENT "pane" floats to the right hand edge of the layout, leaving an ugly gap between the MENU and CONTENT panes. Although that could also be something else wrong in the code I'm looking at.
Well, you can transcribe a div layout in to a table layout *IF* you forget about interwebnets exploder, as the css spec allows you to do that with the display attribute (IIRC).
Unfortunately the pressure is always to *only* pay attention to IE, and forget the alternatives. It is *so* helpful that there are at least 3 IE versions to pay attention to now: Q: why do you use Firefox? the whole world uses IE so you should do everything that way A: OK, which version of IE do you want me to use? Q: The same one everyone else uses A: Well you seem to be on v7, there's a lot of people still on v6 because they can't upgrade, and anyone who keeps up with updates will be on v8. Q: <pause, then change subject, the simple solution just got too complicated> -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG
On 15 Feb 17:07, Mark Rogers wrote:
On 15/02/10 15:11, Brett Parker wrote:
Usual method round that is to float menu to left, content to right, wrap them in a containing div, and have one more div in there that is basically just a clear: both; so that the footer kicks in in the right place (though, you can just make that div the footer and have done with it :)
Thanks for confirming what I thought!
I went looking at the code causing a problem and found all sorts of bodges in the CSS, which having stripped most of them out I did make everything work.
One problem seems still to be that I have to fix the MENU and CONTENT widths. Otherwise, if the CONTENT pane is fixed width as a result of its content (eg if it comprises only a fixed width table) the entire CONTENT "pane" floats to the right hand edge of the layout, leaving an ugly gap between the MENU and CONTENT panes. Although that could also be something else wrong in the code I'm looking at.
I tend to stick to percentage widths, fixed width layouts are generally a bad idea anyways ;)
Well, you can transcribe a div layout in to a table layout *IF* you forget about interwebnets exploder, as the css spec allows you to do that with the display attribute (IIRC).
Unfortunately the pressure is always to *only* pay attention to IE, and forget the alternatives. It is *so* helpful that there are at least 3 IE versions to pay attention to now:
Q: why do you use Firefox? the whole world uses IE so you should do everything that way A: OK, which version of IE do you want me to use? Q: The same one everyone else uses A: Well you seem to be on v7, there's a lot of people still on v6 because they can't upgrade, and anyone who keeps up with updates will be on v8. Q: <pause, then change subject, the simple solution just got too complicated>
Yup, been there, got that t-shirt :) -- Brett Parker
Brett Parker wrote:
On 15 Feb 17:07, Mark Rogers wrote:
On 15/02/10 15:11, Brett Parker wrote:
Usual method round that is to float menu to left, content to right, wrap them in a containing div, and have one more div in there that is basically just a clear: both; so that the footer kicks in in the right place (though, you can just make that div the footer and have done with it :)
Thanks for confirming what I thought!
I went looking at the code causing a problem and found all sorts of bodges in the CSS, which having stripped most of them out I did make everything work.
One problem seems still to be that I have to fix the MENU and CONTENT widths. Otherwise, if the CONTENT pane is fixed width as a result of its content (eg if it comprises only a fixed width table) the entire CONTENT "pane" floats to the right hand edge of the layout, leaving an ugly gap between the MENU and CONTENT panes. Although that could also be something else wrong in the code I'm looking at.
I tend to stick to percentage widths, fixed width layouts are generally a bad idea anyways ;)
Indeed, although in this scenario a combination would not be out of the question. For instance: Set the outer container width to, e.g. 80%, then within this float-right your menu with some fixed width (which is not unreasonable for a menu). Then, follow with a content div with no width set. Divs are naturally fill-to-fit, and so this should fill up whatever space is left between the left edge of the outer container and the menu (subject to margins/padding), meaning your layout should adapt to almost any screen size (apart from /very/ tiny, whereupon the fixed menu will overwhelm the elastic content div). Simon -- ====================================================================== Simon Ransome http://nosher.net Photo RSS Feed: http://nosher.net/images/images.rss
On 15/02/10 17:18, Brett Parker wrote:
I tend to stick to percentage widths, fixed width layouts are generally a bad idea anyways ;)
Ideally I want a way to say "make this bit as narrow as possible without wrapping" and "give this bit all the remaining space". Tables made this quite easy, I'm not quite sure how to do this in CSS. Half the problems I have to solve are when someone has "fixed" problems by using absolute or relative position and suddenly the whole layout stops responding to sensible changes!
Yup, been there, got that t-shirt :
It's funny that as soon as MS give users choice, they start to understand that there are more choices than MS. Same seems to be true of Office 2003 vs Office 2007 (giving OOo a way in), and XP/Vista/Win7. It's no longer a simple decision to use Windows, Internet Explorer and Office, just because everyone else does. All of those now prompt the "yes, but which one?" reply. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) @ 13 Clarke Rd, Milton Keynes, MK1 1LG
On 15 Feb 14:53, Steve Fosdick wrote:
On Mon, 2010-02-15 at 09:50 +0000, Simon Ransome wrote:
However, I'm duty-bound to say... Frames??!
Is there any technique for presenting multi-column output that does not have some problem?
Frames, you say are out.
I've seem recommendations elsewhere not to use tables a layout tool but only for real tables of data because using them for layout is reputed to confuse screen readers.
There is a technique that seems to put content into floating objects but this has the drawback that when the window gets shrunk to a smaller size than the designer had in mind instead of degrading gracefully, for example by wrapping text that would otherwise have been on one line, objects get drawn on top of each other making the whole thing an unreadable mess.
Erm, only if the web dev was a moron... unfortunately, there's a lot of morons out there... Now, if browser support for CSS3 was more wide spread, and people concentrated on content rather than appearance, the web would be a much happier place. Style over substance is annoying. Anyways - yes, frames are out. Mostly you can replace them with fixed positioning, but then you have a whole new issue... mostly that IE doesn't do fixed positioning (*sigh*), so you end up with a javascript hack to do the fixed positioning... Now, what are you actually trying to do? Because, like, that makes all the difference! -- Brett Parker
Now, what are you actually trying to do? Because, like, that makes all the difference! -- Brett Parker
Well I have a frame along the top that is the menu (100% width, 15% height) and the rest below is a separate single frame for content, my problem is that I don't want to have to the same menu over and over again in every page using div and table to align it, so what alternative would you recommend to frames? -- Regards, James ;) Ted Turner - "Sports is like a war without the killing." - http://www.brainyquote.com/quotes/authors/t/ted_turner.html
On 15 Feb 19:23, James Bensley wrote:
Now, what are you actually trying to do? Because, like, that makes all the difference! -- Brett Parker
Well I have a frame along the top that is the menu (100% width, 15% height) and the rest below is a separate single frame for content, my problem is that I don't want to have to the same menu over and over again in every page using div and table to align it, so what alternative would you recommend to frames?
Erm, a decent templating system. -- Brett Parker
participants (6)
-
Brett Parker -
Greg Thomas -
James Bensley -
Mark Rogers -
Simon Ransome -
Steve Fosdick