If in my CSS I set the "background-color" property on the "body"
element, it only covers the background of the elements defined in the
body, up to the current width and height of the page. However, if the
current component set has a resulting small height, this leaves most
of the page with the original background color (white).
However, if I set the property on the "html" element instead, it does
color the entire visible page, beyond the current height of all the
components on the page.
The latter seems like it's going to work better for me, but I'm
wondering if there are any disadvantages of doing this.
This probably won't make that much difference on a real page, as my
current page is just a page to test the JavaScript components I'm
integrating. The real page it gets integrated into will have much more
information, such that the initial page height will be longer than the
initial visible area.
Aug 19 '08
19  4021 
On 2008-08-19, David E. Ross <no****@nowhere .notwrote:
[...]
I created a very short page at
<http://www.rossde.com/test/bg_color.html>. This has an external CSS
file that sets both margins, background color, and background image on
BODY. With SeaMonkey 1.1.11, the entire viewing area shows the color
and image; they extend into the margins. Note that the default
background color that I set for my browser is quite distinct from the
background color specified in my CSS.
The W3C CSS1 specification states in Section 1.3:
"To set a "default" style property for a document, one can set the
property on an element from which all visible elements descend. In HTML
documents, the 'BODY' element can serve this function".
Thus, properties set for BODY apply to the entire viewing window and not
merely to the area within the margins.
Interesting. That's CSS1 which is very out-of-date of course. CSS 2.1
says:
The background of the root element becomes the background of the
canvas and covers the entire canvas [...]
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
For HTML documents whose root HTML element has computed values of
'transparent' for 'background-color' and 'none' for
'background-image', user agents must instead use the computed value
of those properties from that HTML element's first BODY element
child when painting backgrounds for the canvas, and must not paint a
background for that BODY element.
[Which is why your test works in SeaMoney 1.1.11 as it should]
To the OP: the point is not that there's anything wrong with setting a
background on the canvas, if that's what you want. The question is just
how to get it there. You can either set it on the html element, or on
the body element provided you leave the html element with its initial
value for background. The spec recommends the latter for HTML (as
opposed to XHTML) documents. But also check it actually works in the
browsers you're interested in.
In article <sl************ *********@bowse r.marioworld>,
Ben C <sp******@spam. eggswrote:
CSS 2.1
says:
The background of the root element becomes the background of the
canvas and covers the entire canvas [...]
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
I find it hard to imagine the exact context in which the words "For HTML
documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element" is said
(beyond the obvious of them being where they are in CSS 2.1)
If the recommendation is on the assumption that you are going to choose
*one* of BODY or HTML to put a background colour on in the knowledge
that it will be appropriated by CANVAS, then BODY for background seems
to be the one favoured. For reasons we can speculate on (you give one
interesting possibility).
But we need really to know what the reason is and if it bears on the
question of the possibility that the assumption is not always true. What
if you want CANVAS to be a different colour to BODY? You have no choice
but to instruct HTML (which you know will then be appropriated by
CANVAS)? Is anything said about this?
For HTML documents whose root HTML element has computed values of
'transparent' for 'background-color' and 'none' for
'background-image', user agents must instead use the computed value
of those properties from that HTML element's first BODY element
child when painting backgrounds for the canvas, and must not paint a
background for that BODY element.
--
dorayme
On 2008-08-20, dorayme <do************ @optusnet.com.a uwrote:
In article <sl************ *********@bowse r.marioworld>,
Ben C <sp******@spam. eggswrote:
>CSS 2.1
says:
The background of the root element becomes the background of the
canvas and covers the entire canvas [...]
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
I find it hard to imagine the exact context in which the words "For HTML
documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element" is said
(beyond the obvious of them being where they are in CSS 2.1)
They mean as opposed to XHTML. The context is here: http://www.w3.org/TR/CSS21/colors.html#background
14.2.
If the recommendation is on the assumption that you are going to choose
*one* of BODY or HTML to put a background colour on in the knowledge
that it will be appropriated by CANVAS, then BODY for background seems
to be the one favoured. For reasons we can speculate on (you give one
interesting possibility).
That seems to be what they are saying.
But we need really to know what the reason is and if it bears on the
question of the possibility that the assumption is not always true. What
if you want CANVAS to be a different colour to BODY?
Well exactly. A similar situation exists with overflow-- you can't apply
overflow to the root element, because it always gets moved to the
viewport as I was explaining to Korpela recently.
But it's not a big problem in practice because you usually want overflow
on the viewport, not on the root element.
You have no choice but to instruct HTML (which you know will then be
appropriated by CANVAS)? Is anything said about this?
Only what you see in 14.2. I guess if you want more backgrounds, you
just nest a couple of DIVs inside BODY.
In article <sl************ *********@bowse r.marioworld>,
Ben C <sp******@spam. eggswrote:
On 2008-08-20, dorayme <do************ @optusnet.com.a uwrote:
In article <sl************ *********@bowse r.marioworld>,
Ben C <sp******@spam. eggswrote:
CSS 2.1
....
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
I find it hard to imagine the exact context in which the words "For HTML
documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element" is said
(beyond the obvious of them being where they are in CSS 2.1)
They mean as opposed to XHTML. The context is here:
http://www.w3.org/TR/CSS21/colors.html#background
14.2.
If the recommendation is on the assumption that you are going to choose
*one* of BODY or HTML to put a background colour on in the knowledge
that it will be appropriated by CANVAS, then BODY for background seems
to be the one favoured. For reasons we can speculate on (you give one
interesting possibility).
That seems to be what they are saying.
But we need really to know what the reason is and if it bears on the
question of the possibility that the assumption is not always true. What
if you want CANVAS to be a different colour to BODY?
Well exactly. A similar situation exists with overflow-- you can't apply
overflow to the root element, because it always gets moved to the
viewport as I was explaining to Korpela recently.
But it's not a big problem in practice because you usually want overflow
on the viewport, not on the root element.
You have no choice but to instruct HTML (which you know will then be
appropriated by CANVAS)? Is anything said about this?
Only what you see in 14.2. I guess if you want more backgrounds, you
just nest a couple of DIVs inside BODY.
Yes, the practical is not any big problem, the idea I have is that the
author obviously should do the most with the least. And if you can do as
much as possible with elements you *have* to have (like HTML and BODY),
then, naturally, is it not tempting to give it a go? Here is something
fairly ecoomical (my editor says it was fine without any child in BODY,
so too did iCab but the validator at http://validator.w3.org/ kept
insisting there was something wrong with BODY and implied it might need
a child so I gave it one (reluctantly): http://tinyurl.com/67wd7l
or http://netweaver.com.au/rootStudies/...yElements.html
These are economy.
--
dorayme
Ben C wrote:
>
dorayme wrote:
>>Ben C wrote:
>>CSS 2.1
says:
The background of the root element becomes the background of the
canvas and covers the entire canvas [...]
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
I find it hard to imagine the exact context in which the words "For HTML
documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element" is said
(beyond the obvious of them being where they are in CSS 2.1)
They mean as opposed to XHTML. The context is here:
http://www.w3.org/TR/CSS21/colors.html#background
14.2 The background
Authors may specify the background of an element (i.e.,
its rendering surface) as either a color or an image.
In terms of the box model, "background " refers to the
background of the content, padding and border areas.
Border colors and styles are set with the border
properties. Margins are always transparent.
Background properties are not inherited, but the
parent box's background will shine through by
default because of the initial 'transparent'
value on 'background-color'.
The background of the root element becomes the
background of the canvas and covers the entire
canvas, anchored (for 'background-position') at
the same point as it would be if it was painted
only for the root element itself. The root
element does not paint this background again.
For HTML documents, however, we recommend that
authors specify the background for the BODY
element rather than the HTML element. For HTML
documents whose root HTML element has computed
values of 'transparent' for 'background-color'
and 'none' for 'background-image', user agents
must instead use the computed value of those
properties from that HTML element's first BODY
element child when painting backgrounds for
the canvas, and must not paint a background
for that BODY element. Such backgrounds must
also be anchored at the same point as they
would be if they were painted only for the
root element. This does not apply to XHTML
documents.
>
>If the recommendation is on the assumption that you are going to choose
*one* of BODY or HTML to put a background colour on in the knowledge
that it will be appropriated by CANVAS, then BODY for background seems
to be the one favoured. For reasons we can speculate on (you give one
interesting possibility).
That seems to be what they are saying.
>But we need really to know what the reason is and if it bears on the
question of the possibility that the assumption is not always true. What
if you want CANVAS to be a different colour to BODY?
Well exactly. A similar situation exists with overflow-- you can't apply
overflow to the root element, because it always gets moved to the
viewport as I was explaining to Korpela recently.
But it's not a big problem in practice because you usually want overflow
on the viewport, not on the root element.
>You have no choice but to instruct HTML (which you know will then be
appropriated by CANVAS)? Is anything said about this?
Only what you see in 14.2. I guess if you want more backgrounds, you
just nest a couple of DIVs inside BODY.
Interesting discussion about this topic here: http://www.molly.com/2005/02/18/root-element-html/
And a somewhat related IE hack here: http://tagsoup.com/cookbook/css/fixed/
My question is this: what if I simply use identical CSS
settings for *, HTML and BODY? Would that be a reliable
way to style everything (canvas, viewport, etc.) in all
browsers? Other than making the CSS bigger than it needs
to be, is there any downside? Or would * alone be enough?
--
Guy Macon
<http://www.GuyMacon.co m/>
On 8/20/2008 5:10 AM, Guy Macon wrote:
Details on CSS changes for IE7
http://blogs.msdn.com/ie/archive/2006/08/22/712830.aspx
http://msdn.microsoft.com/en-us/library/bb250496.aspx
Cascading Style Sheet Compatibility in Internet Explorer 7
I don't have IE7 installed; could someone test the page at
http://www.phaf.org/testroot/root.html and see if IE7
displays it the wau FireFox does?
SeaMonkey 1.1.x uses the same rendering engine as Firefox 2.0.x.
Comparing SeaMonkey 1.1.11 with IE 7.0, I see the following differences:
1. The "Canned Soup" box in IE is shifted slightly higher and
noticeably leftward relative to where it is in SeaMonkey.
2. At the very top of the page is a red box. The box is significantly
taller in IE than in SeaMonkey; it is wider in SeaMonkey than in IE.
3. The box at the very top contains a bar that is centered within the
box. In IE, the bar is blue. In SeaMonkey, the bar appears black.
No, I don't want to capture screen shots and upload them anyplace.
Note:
My IE 7.0 has inconsistent version numbers. From the menu bar,
selecting [Help About Internet Explorer], I see 7.0.5730.11. Looking
at the properties of iexplore.exe, I see 7.0.6000.16705. The user agent
string is:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
2.0.50727)
There are some inconsistencies with SeaMonkey's versions, too. On the
menu bar, selecting [Help About SeaMonkey] displays the user agent
string under "SeaMonkey 1.1.11":
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16)
Gecko/20080702 SeaMonkey/1.1.11
The properties for seamonkey.exe show three different versions:
file version (at the top of the Properties window) -- 1.8.20080.4680
file version (in the "Other version information" area) -- 1.8.1.16:
2008070216 (this is the version of the Gecko rendering engine and the
year-month-date-hour either Gecko or SeaMonkey was compiled)
product version -- 1.1.11
--
David E. Ross
<http://www.rossde.com/>
Q: What's a President Bush cocktail?
A: Business on the rocks.
David E. Ross wrote:
>
On 8/20/2008 5:10 AM, Guy Macon wrote:
>I don't have IE7 installed; could someone test the page at
http://www.phaf.org/testroot/root.html and see if IE7
displays it the wau FireFox does?
SeaMonkey 1.1.x uses the same rendering engine as Firefox 2.0.x.
Comparing SeaMonkey 1.1.11 with IE 7.0, I see the following differences:
1. The "Canned Soup" box in IE is shifted slightly higher and
noticeably leftward relative to where it is in SeaMonkey.
2. At the very top of the page is a red box. The box is significantly
taller in IE than in SeaMonkey; it is wider in SeaMonkey than in IE.
3. The box at the very top contains a bar that is centered within the
box. In IE, the bar is blue. In SeaMonkey, the bar appears black.
>From the menu bar, selecting [Help About Internet Explorer],
I see 7.0.5730.11.
>On the menu bar, selecting [Help About SeaMonkey] displays
[...] SeaMonkey 1.1.11"
Using the same Help About versioning, testing with Internet
Explorer 6.0.2800.1106 and with Mozilla Firefox 2.0.0.16 running
under Windows 2000 Advanced Server (all updates installed) I see:
The "Canned Soup" box in IE is shifted noticeably higher and
noticeably leftward relative to where it is in FireFox.
There is a red box that enclosed a black box with a blue interior
in FireFox. The black box is as high as the red box, but not as
wide.
The red box encloses the entire page -- including a grayed-out
vertical scrollbar -- in IE. FireFox has no scrollbar, and has
a thin white stripe on the left.
The black box has zero height in IE, so I can't tell it it as a
blue interior. I believe that this is the same as what you describe
above.
--
Guy Macon
<http://www.GuyMacon.co m/> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: mydejamail |
last post by:
Coming from an objectpascal background with strict type checking, I am
being driven nuts by PHP.
Stuff like using variables without declaring them, case sensitivity of
variables, getting true, false, 0, 1, "" mixed up, missing the $ before
variables etc is really slowing me down.
Is there a way to configure a run-time setting or interpreter setting
that will throw up warnings or declare an error if some of these issues
are present?
|
by: p s |
last post by:
hi
can someone tell me how to ensure the height of my window is always exact?
(excluding titlebar) in VB6
e.g. if i set the form to 300 pixels, then the total height of the form
takes into account the title bar, however i want to use a specific
background graphic in the main form background.... visual styles, and themes
and so on make this an impossiblilty! if the title bar is big (a la windows
xp) then i lose some pixels at the bottom,...
|
by: Dave |
last post by:
Hello NG,
Why would one not just always use std::multiset<> instead of std::set<> (and
similarly for maps)? Clearly, there must be tradeoffs to gain the ability
to have repeated keys. What are the tradeoffs?
Thanks,
Dave
|
by: MLH |
last post by:
A form named frmVehicleEntryForm has a number of textbox
controls who's OnGotFocus property setting is an expression...
=Change2Green()
Change2Green() looks something like this...
Dim MyControl As Control
Set MyControl = Screen.ActiveControl
MyControl.BackColor = 65280
Tabbing from control-to-control is great. Each time I land on
|
by: DexHex |
last post by:
Hi,
I am stumpt. Is there anyway to set the background image on a webpart
title?
| | |
by: PeterKellner |
last post by:
I'm having trouble setting a background style in a master page. The
declaration in the master page looks like this:
<div id="header_image" runat="server" style="background: transparent
url(images/bg_header.jpg) repeat-x scroll 0% 0%;;cursor: pointer;">
</div>
I tried adding runat="server" as well as changing the url to
~/images/bg_head.jpg but that didn't work.
|
by: vijai.kalyan |
last post by:
Hello,
I wrote a trivial program to set the console title in a console
application. Here is the code:-
namespace myns
{
class SetTitle
{
static void Main ( string args )
|
by: Mike.Wolowicz |
last post by:
I have a report that changes background colour when a running total
field hits a certain value...
Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
If >= 2400001 Then
Me.Section(0).BackColor = 16053492
Else
Me.Section(0).BackColor = 16777215
End If
End Sub
|
by: jaybob217 |
last post by:
Is there a way to set a labels background image programatically from the code behind page? I've played around with "style background-image: url()" but can't seem to get it to work.
Label.Style
|
by: RKT |
last post by:
I have a DataGridView bound to an MS Access table. This is a single-
user application. When the User is adding or editing a row, the User
may click on a Control elsewhere. That Control has context which I use
to programmatically set *other* r/o cell values for the currently
selected grid row. So, after that click on another control, and
stuffing the related cell values, I want to seamlessly allow the user
to resume editing/adding that row...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
