Background in css gives warning

Discussion in 'HTML' started by Adario, Feb 24, 2006.

  1. Adario

    Adario Guest

    When I use the following:

    body {background: #d4ecfb;}

    The validator says:

    Warnings
    URI : file://localhost/main.css

    * Line : 1 (Level : 1) You have no color with your background-color :
    body

    It works but gives the warning. Any ideas?
     
    Adario, Feb 24, 2006
    #1
    1. Advertising

  2. Adario wrote:

    > When I use the following:
    >
    > body {background: #d4ecfb;}
    >
    > The validator says:
    >
    > Warnings
    > URI : file://localhost/main.css
    >
    > * Line : 1 (Level : 1) You have no color with your background-color :
    > body
    >
    > It works but gives the warning. Any ideas?


    "You have no *color* with your background-color"

    body {background: #d4ecfb; color: #000;}

    [or whatever works and contrasts with #d4ecfb...]
    --
    -bts
    -Warning: I brake for lawn deer
     
    Beauregard T. Shagnasty, Feb 24, 2006
    #2
    1. Advertising

  3. Adario

    Ed Mullen Guest

    Adario wrote:
    > When I use the following:
    >
    > body {background: #d4ecfb;}
    >
    > The validator says:
    >
    > Warnings
    > URI : file://localhost/main.css
    >
    > * Line : 1 (Level : 1) You have no color with your background-color :
    > body
    >
    > It works but gives the warning. Any ideas?


    It is not invalid, it's just a warning. The point is that a user's
    settings may specify either or both of background color and text color.
    If you specify, for instance, only a bg color of black and the user
    has an over-ride setting text color to black ... well. So the validator
    is telling you of a potential usability problem, not invalid code.

    --
    Ed Mullen
    http://edmullen.net
    http://mozilla.edmullen.net
    http://abington.edmullen.net
     
    Ed Mullen, Feb 24, 2006
    #3
  4. Adario

    Neredbojias Guest

    With neither quill nor qualm, Adario quothed:

    > When I use the following:
    >
    > body {background: #d4ecfb;}
    >
    > The validator says:
    >
    > Warnings
    > URI : file://localhost/main.css
    >
    > * Line : 1 (Level : 1) You have no color with your background-color :
    > body
    >
    > It works but gives the warning. Any ideas?


    If you specify a color without a background-color or vice versa on any
    element, the validator will give a warning. In some cases it's
    ridiculous (-not all,) but the validator is the validator...

    --
    Neredbojias
    Contrary to popular belief, it is believable.
     
    Neredbojias, Feb 24, 2006
    #4
  5. Adario

    Adario Guest

    Thanks to everyone who responded.
    Now I understand!
     
    Adario, Feb 24, 2006
    #5
  6. Neredbojias <> wrote:

    > If you specify a color without a background-color or vice versa on
    > any element, the validator will give a warning.


    The CSS checker, misleadingly named "CSS Validator", indeed issues a
    useful warning.

    > In some cases it's ridiculous (-not all,)


    No it isn't. The ridiculous part is that authors complain about the
    useful warning with outbursts that clearly demonstrate why the warning
    is useful and almost always points at a design mistake: authors do not
    understand the cascade.

    > but the validator is the validator...


    No it isn't.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
     
    Jukka K. Korpela, Feb 24, 2006
    #6
  7. Adario

    Neredbojias Guest

    With neither quill nor qualm, Jukka K. Korpela quothed:

    > Neredbojias <> wrote:
    >
    > > If you specify a color without a background-color or vice versa on
    > > any element, the validator will give a warning.

    >
    > The CSS checker, misleadingly named "CSS Validator", indeed issues a
    > useful warning.
    >
    > > In some cases it's ridiculous (-not all,)

    >
    > No it isn't. The ridiculous part is that authors complain about the
    > useful warning with outbursts that clearly demonstrate why the warning
    > is useful and almost always points at a design mistake: authors do not
    > understand the cascade.


    Suppose I have many lines of white text and decide to span one word to
    change its color to yellow. Do I need to state a background? I think
    not.

    > > but the validator is the validator...

    >
    > No it isn't.


    Well... It purports to be a validator, is from the w3c, and is
    internationally recognized, so despite its errors I think it could be
    legitimately called a "validator" but I don't necessarily disagree with
    the import of your statement.

    --
    Neredbojias
    Contrary to popular belief, it is believable.
     
    Neredbojias, Feb 24, 2006
    #7
  8. On Fri, 24 Feb 2006, Neredbojias wrote:

    > Suppose I have many lines of white text and decide to span one word
    > to change its color to yellow. Do I need to state a background?


    Do you "need" to? - No, you're entitled to ignore a warning, but it's
    best to understand the warning before deciding to ignore it. Consider
    e.g cascading with a stylesheet which defined the background for span
    to be yellow.

    Is it *good practice* to do so? - I'd say yes, and so say the folks
    at the W3C CSS "validator". But sometimes there's no choice (e.g if
    you want the background image of an outer element to "shine through"
    an inner element at the same time as specifying text colour for that
    inner element).

    > Well... It purports to be a validator,


    The problem here is that in an SGML/XML context, the term "validator"
    has a very specialised meaning, which matters (or ought to) to HTML
    authors. CSS is neither SGML nor XML, and those who care about the
    meaning of words would prefer not to have the water muddied by this
    kind of sloppy terminology.

    --

    Most folks would think a Referer header is something you smoke.
    -- Bruce Tomlin in a.s.r
     
    Alan J. Flavell, Feb 24, 2006
    #8
  9. Adario

    Neredbojias Guest

    With neither quill nor qualm, Alan J. Flavell quothed:

    > On Fri, 24 Feb 2006, Neredbojias wrote:
    >
    > > Suppose I have many lines of white text and decide to span one word
    > > to change its color to yellow. Do I need to state a background?

    >
    > Do you "need" to? - No, you're entitled to ignore a warning, but it's
    > best to understand the warning before deciding to ignore it.


    Agreed, -at least you should understand the css cascading of style
    sheets which prompt the warning.

    > Consider
    > e.g cascading with a stylesheet which defined the background for span
    > to be yellow.


    Since you surely mean a user stylesheet, suppose my body text color was
    yellow? -With a brown body background? If a hypothetical user
    _overrides_ page settings, it is his responsibility to ensure that he
    does not err in his endeavors. "Cascading" does _not_ mean having to
    set a background-color for every color designated. In fact, it means
    rather the opposite.

    > Is it *good practice* to do so? - I'd say yes, and so say the folks
    > at the W3C CSS "validator".


    You're undoubtedly right here, but it reminds me a lot of Microsoft's
    old practice of "covering for" third-party mistakes. That does not lead
    to markup excellence.

    > But sometimes there's no choice (e.g if
    > you want the background image of an outer element to "shine through"
    > an inner element at the same time as specifying text colour for that
    > inner element).


    Transparent??

    > > Well... It purports to be a validator,

    >
    > The problem here is that in an SGML/XML context, the term "validator"
    > has a very specialised meaning, which matters (or ought to) to HTML
    > authors. CSS is neither SGML nor XML, and those who care about the
    > meaning of words would prefer not to have the water muddied by this
    > kind of sloppy terminology.


    Okay, I dunno, and I'm not that much into it to be persnickety. I do
    know the damn thing has errors, so whether a "validator" or a "checker",
    it's flawed.

    --
    Neredbojias
    Contrary to popular belief, it is believable.
     
    Neredbojias, Feb 25, 2006
    #9
  10. Neredbojias <> wrote:

    > - - at least you should understand the css cascading of style
    > sheets which prompt the warning.


    People who understand the cascade won't ignore the warning. (Well, once
    in a blue moon they might - but they do it knowing what they are doing
    and not whining about the warning).

    >> Consider
    >> e.g cascading with a stylesheet which defined the background for
    >> span to be yellow.

    >
    > Since you surely mean a user stylesheet,


    I don't know what Alan had in his mind, but surely there might be a
    browser style sheet, too, or another author style sheet (say, after,
    ACME has bought all rights to your pages for an indecent sum of money
    and made them available in a context where ACME corporate style sheet
    is used, too).

    > suppose my body text color
    > was yellow? -With a brown body background?


    Your body text color and background are, as other properties,
    determined in the cascade.

    > If a hypothetical user
    > _overrides_ page settings, it is his responsibility to ensure that
    > he does not err in his endeavors.


    Yes, and the author has his part of the game to take care of.

    If both set color whenever setting background and vice versa, and do
    that well (with sufficient contrast), the serious problem of (say)
    yellow on yellow can be avoided. If _you_ set only color for <span>,
    then _you_ have a mistake, and it does not help that the user did his
    job well.

    > "Cascading" does _not_ mean
    > having to set a background-color for every color designated. In
    > fact, it means rather the opposite.


    The opposite? Don't be ridiculous.

    In the cascade, every property is handled separately for each element
    (after we have conceptually expanded all shortcuts). This might be a
    fundamental design flaw in CSS, but it's there. It implies that if you
    set the color property for an element without setting the background
    properties, the cascade may give the element any background.

    Even if you do things right, it is possible to break things, since a
    user style sheet could override your color setting and not set
    background. But _that_ would be a user's error, which is quite
    comparable to the author's mistake we are discussing.

    > Transparent??


    Transparent means that you accept that whatever the cascade happens to
    assign as value to the parent element's background property this time
    will appear as the background.

    > I do know the damn thing has errors, so whether a "validator" or a
    > "checker", it's flawed.


    It has its share of errors, but the warning you are complaining about
    is not among them.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
     
    Jukka K. Korpela, Feb 25, 2006
    #10
  11. Adario

    Toby Inkster Guest

    Jukka K. Korpela wrote:

    > Transparent means that you accept that whatever the cascade happens to
    > assign as value to the parent element's background property this time
    > will appear as the background.


    If you control all of the HTML, then specifying something like:

    STRONG {
    color: red;
    background: transparent;
    }

    in CSS might make sense, because you may know that you'll only ever use
    <strong> within <div id="content"> which has an off-white background.

    But if there are multiple markup authors, then "background:transparent"
    might be almost as useless as not specifying a background at all.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
     
    Toby Inkster, Feb 25, 2006
    #11
  12. On Sat, 25 Feb 2006, Toby Inkster wrote:

    > If you control all of the HTML, then specifying something like:
    >
    > STRONG {
    > color: red;
    > background: transparent;
    > }
    >
    > in CSS might make sense,


    Ah, you say you "control all of the HTML": but who controls "all of"
    the CSS?

    At the very least, the /user/ has every right to cascade their own
    stylesheet with the one provided by the author. And it wouldn't
    surprise me if some kinds of service provider were to impose a
    stylesheet of their own, in addition to what the author provides.
    There's a long history of service-providers injecting
    syntactically-invalid fragments of HTML into the web pages of their
    customers, after all - who's stopping them from doing much the same
    with stylesheets?

    And it's not unknown for corporates to insist on their corporate
    stylesheet being applied for house consistency. Their management can
    decree at any moment a complete change of the house style - so a
    one-off exercise of ensuring that the author's styles jive well with
    the *current* corporate stylesheet is by no means a complete solution.

    > But if there are multiple markup authors, then
    > "background:transparent" might be almost as useless as not
    > specifying a background at all.


    Well, a transparent background is the "initial value"; so the only
    difference between specifying it and not specifying it is the question
    of what priority it gets in the cascade.

    cheers
     
    Alan J. Flavell, Feb 25, 2006
    #12
  13. Adario

    Els Guest

    Alan J. Flavell wrote:

    > On Sat, 25 Feb 2006, Toby Inkster wrote:
    >
    >> But if there are multiple markup authors, then
    >> "background:transparent" might be almost as useless as not
    >> specifying a background at all.

    >
    > Well, a transparent background is the "initial value"; so the only
    > difference between specifying it and not specifying it is the question
    > of what priority it gets in the cascade.


    That, and validation, or rather, seeing possible errors in the
    validator results without having to wade through the 'missing
    background-color' warnings.

    --
    Els http://locusmeus.com/
     
    Els, Feb 25, 2006
    #13
  14. Adario

    Neredbojias Guest

    With neither quill nor qualm, Jukka K. Korpela quothed:

    > Neredbojias <> wrote:
    >
    > > - - at least you should understand the css cascading of style
    > > sheets which prompt the warning.

    >
    > People who understand the cascade won't ignore the warning. (Well, once
    > in a blue moon they might - but they do it knowing what they are doing
    > and not whining about the warning).
    >
    > >> Consider
    > >> e.g cascading with a stylesheet which defined the background for
    > >> span to be yellow.

    > >
    > > Since you surely mean a user stylesheet,

    >
    > I don't know what Alan had in his mind, but surely there might be a
    > browser style sheet, too, or another author style sheet (say, after,
    > ACME has bought all rights to your pages for an indecent sum of money
    > and made them available in a context where ACME corporate style sheet
    > is used, too).
    >
    > > suppose my body text color
    > > was yellow? -With a brown body background?

    >
    > Your body text color and background are, as other properties,
    > determined in the cascade.
    >
    > > If a hypothetical user
    > > _overrides_ page settings, it is his responsibility to ensure that
    > > he does not err in his endeavors.

    >
    > Yes, and the author has his part of the game to take care of.
    >
    > If both set color whenever setting background and vice versa, and do
    > that well (with sufficient contrast), the serious problem of (say)
    > yellow on yellow can be avoided. If _you_ set only color for <span>,
    > then _you_ have a mistake, and it does not help that the user did his
    > job well.
    >
    > > "Cascading" does _not_ mean
    > > having to set a background-color for every color designated. In
    > > fact, it means rather the opposite.

    >
    > The opposite? Don't be ridiculous.
    >
    > In the cascade, every property is handled separately for each element
    > (after we have conceptually expanded all shortcuts). This might be a
    > fundamental design flaw in CSS, but it's there. It implies that if you
    > set the color property for an element without setting the background
    > properties, the cascade may give the element any background.
    >
    > Even if you do things right, it is possible to break things, since a
    > user style sheet could override your color setting and not set
    > background. But _that_ would be a user's error, which is quite
    > comparable to the author's mistake we are discussing.
    >
    > > Transparent??

    >
    > Transparent means that you accept that whatever the cascade happens to
    > assign as value to the parent element's background property this time
    > will appear as the background.
    >
    > > I do know the damn thing has errors, so whether a "validator" or a
    > > "checker", it's flawed.

    >
    > It has its share of errors, but the warning you are complaining about
    > is not among them.


    Yep, you're right. I started replying in a much different manner than
    this, but as I was describing a hypothetical scenario, I saw it.

    Suppose I have white text/brown background on the body. I span a word,
    coloring it yellow, sans background. The user comes along and styles
    the body color brown and the body background yellow (including both
    attributes correctly.) My spanned word "disappears" and I am at fault.

    I really thought that _always_ setting both color and bg wasn't
    necessary. What can I say? Would you accept a humble "oops"? Please
    don't banish me to Finland 'cause I hate cold weather...

    --
    Neredbojias
    Contrary to popular belief, it is believable.
     
    Neredbojias, Feb 25, 2006
    #14
  15. Alan J. Flavell wrote:

    > The problem here is that in an SGML/XML context, the term "validator"
    > has a very specialised meaning, which matters (or ought to) to HTML
    > authors. CSS is neither SGML nor XML, and those who care about the
    > meaning of words would prefer not to have the water muddied by this
    > kind of sloppy terminology.


    I don't quite get that. Neither the term nor the concept "validator" was
    invented or is owned by the people who wrote the SGML and XML standards.
    It's been defined by them for use in those contexts, but that has no
    bearing on legitimate plain-English uses of the word outside of those
    contexts. As you say, CSS is neither SGML nor XML, so one need make no
    reference to the SGML or XML standards to use the term "validator" in
    the context of CSS.
     
    Harlan Messinger, Feb 26, 2006
    #15
  16. Toby Inkster wrote:
    > Jukka K. Korpela wrote:
    >
    >> Transparent means that you accept that whatever the cascade happens to
    >> assign as value to the parent element's background property this time
    >> will appear as the background.

    >
    > If you control all of the HTML, then specifying something like:
    >
    > STRONG {
    > color: red;
    > background: transparent;
    > }
    >
    > in CSS might make sense, because you may know that you'll only ever use
    > <strong> within <div id="content"> which has an off-white background.


    But the user may have a stylesheet with

    STRONG { background-color: red ! important; }

    though I doubt it. However, in your scenario, you could use the selector

    div#content STRONG

    instead. The user's stylesheet is highly unlikely to have anything
    applicable that's of higher specificity than that.
     
    Harlan Messinger, Feb 26, 2006
    #16
  17. Harlan Messinger <> wrote:

    > But the user may have a stylesheet with
    >
    > STRONG { background-color: red ! important; }
    >
    > though I doubt it.


    Well, it's a poorly written style sheet since it does not specify
    color. We cannot protect against such style sheets. We can and should
    protect against clashes with technically well-designed user style
    sheets, such as

    STRONG { background-color: red ! important; color: white ! important; }

    (which would not result in a problem in this case) _or_ the same
    without the !important specifiers.

    > However, in your scenario, you could use the
    > selector
    >
    > div#content STRONG
    >
    > instead. The user's stylesheet is highly unlikely to have anything
    > applicable that's of higher specificity than that.


    Specificity isn't all. A user style sheet can trump all rules in an
    author style sheet, even using the least specific selector *:

    * { color: white !important; background: black !important; }

    In this case, problems would arise if the user style sheet had

    div { color: white !important; background: red !important; }

    But things really get _more difficult_ when people try to avoid
    declaring colors and backgrounds together. I can understand some
    reasons to such reluctance, but there's really no other way to write
    robust style sheets.

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
     
    Jukka K. Korpela, Feb 26, 2006
    #17
  18. Els <> wrote:

    > That, and validation, or rather, seeing possible errors in the
    > validator results without having to wade through the 'missing
    > background-color' warnings.


    You can switch off the warnings if you like.

    Of course, there's always the option of actually fixing what's broken,
    but why would anyone do so when the wrong may appears to be working
    this sunny afternoon?

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
    Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html
     
    Jukka K. Korpela, Feb 27, 2006
    #18
  19. Adario

    Els Guest

    Jukka K. Korpela wrote:

    > Els <> wrote:
    >
    >> That, and validation, or rather, seeing possible errors in the
    >> validator results without having to wade through the 'missing
    >> background-color' warnings.

    >
    > You can switch off the warnings if you like.


    Too paranoid for that - you never know if there would be any warning
    you want to know about ;-)

    > Of course, there's always the option of actually fixing what's broken,
    > but why would anyone do so when the wrong may appears to be working
    > this sunny afternoon?


    Because we are glued to the computer anyway, so it doesn't really
    matter if it's sunny or not? Besides, although it was sunny earlier,
    it looks all grey outside now.

    (not sure what it is you're referring to that's broken)

    --
    Els http://locusmeus.com/
     
    Els, Feb 27, 2006
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Why the compiler gives warning ?

    , Aug 9, 2005, in forum: C Programming
    Replies:
    13
    Views:
    537
  2. Eugene Rice

    char as array index gives warning in gcc

    Eugene Rice, Oct 21, 2006, in forum: C Programming
    Replies:
    13
    Views:
    758
    Dave Thompson
    Nov 6, 2006
  3. Replies:
    5
    Views:
    466
    Daniel T.
    Jul 8, 2007
  4. Harry Ebbers

    QA-C gives side-effects warning. Unknown why

    Harry Ebbers, Nov 26, 2008, in forum: C Programming
    Replies:
    24
    Views:
    1,213
    Harry Ebbers
    Dec 1, 2008
  5. Borked Pseudo Mailed

    QA-C gives side-effects warning. Unknown why

    Borked Pseudo Mailed, Nov 29, 2008, in forum: C Programming
    Replies:
    2
    Views:
    319
    CBFalconer
    Dec 1, 2008
Loading...

Share This Page