validation woes
Angela
validate, Mine works fine, as much as browsers let it, but doesn't validate
because i haven't applied background colours to some classes that have
specified font colours, The reason being that my menu is in a layer above a
picture, and if i give it a background colour, it looks terrible. Are there
any workarounds to this or i should just get over it and not care if it
validates.
Thanks,
Angela
Mark Tranchant
That's not a validation failure, it's a warning. Background is
transparent by default. Give us a URL to be certain.
Does the validator actually state "Error" anywhere in its assessment?
Jukka K. Korpela
> That's not a validation failure, it's a warning. Background is
> transparent by default. Give us a URL to be certain.
It is true that background is transparent by default, in a sense, but what
will happen if a user style sheet contains
a:link { background: #000; color: #ddf; }
a:visited { background: url(dark.png); color: #fdf; }
for example?
> Does the validator actually state "Error" anywhere in its assessment?
There is no such thing as a CSS validator. They just call it that way.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Alan J. Flavell
> > Hi, I was just wondering how critical it really is to have your css
> > validate, Mine works fine, as much as browsers let it, but doesn't validate
> > because i haven't applied background colours to some classes that have
> > specified font colours,
> That's not a validation failure, it's a warning.
True. It is, however, warning about a real issue in CSS.
> Background is transparent by default.
To be more accurate, the background is whatever colour the other
cascaded stylesheets (not forgetting the user stylesheet) said it
should be. And that's the reason for the warning.
> Does the validator actually state "Error" anywhere in its assessment?
You're technically accurate: however, whereas an actual error could be
harmless (in the sense that a properly-behaved[1] client is supposed
to ignore anything that's objectively invalid), it could well happen
that a failure by the author to understand and deal with one of these
"warnings" could result in text being displayed, for example,
black-on-black, leaving the reader completely unaware of some part of
the page.
cheers
[1] unfortunately some mass-market browsers have failed to understand
the benefit of this part of CSS error handling, and are liable to make
a guess at what the defective property could mean. This sometimes
happens to produce the intended result, but could equally make the
page completely unusable. You'd think they might have learned
something from the unpleasant experiences from IE3.*, but apparently
not.
Michael Lefevre
Flavell wrote:
> On Thu, Feb 27, Mark Tranchant inscribed on the eternal scroll:
>
>> > Hi, I was just wondering how critical it really is to have your css
>> > validate, Mine works fine, as much as browsers let it, but doesn't validate
>> > because i haven't applied background colours to some classes that have
>> > specified font colours,
>
>> That's not a validation failure, it's a warning.
>
> True. It is, however, warning about a real issue in CSS.
>
>> Background is transparent by default.
>
> To be more accurate, the background is whatever colour the other
> cascaded stylesheets (not forgetting the user stylesheet) said it
> should be. And that's the reason for the warning.
>
>> Does the validator actually state "Error" anywhere in its assessment?
>
> You're technically accurate: however, whereas an actual error could be
> harmless (in the sense that a properly-behaved[1] client is supposed
> to ignore anything that's objectively invalid), it could well happen
> that a failure by the author to understand and deal with one of these
> "warnings" could result in text being displayed, for example,
> black-on-black, leaving the reader completely unaware of some part of
> the page.
I had a stylesheet with this issue - is there a practical solution to
avoid the issue that this warning is about? I'm afraid I don't have a
page to point at, but if you have, say, a page with a dark blue
background image and white text, and you then want to specify yellow text
on a particular element, what can you do about the background on that
element? If you don't specify it and a user stylesheet sets the body to
be black-on-white, you'll get unreadable yellow-on-white. If you specify
a background colour, you'll have a plain background over your page
background image, and if you specify the same background image, you'll
get a new copy of the image on the element.
--
Michael
Steven R. Gerber
Sorry,
I must disagree.
HTML:
The W3C MarkUp Validation Service
http://validator.w3.org/
CSS:
W3C CSS Validation Service
http://jigsaw.w3.org/css-validator/
Steven
Cien
news:3e5e0142$0$5553$afc3...@news.optusnet.com.au...
{background-color: transparent; }
or for shorthand
{background : transparent;}
I get valid css with no warnings. Not sure if there are any problems you
might run into, but the page looks how I want it.
Cien
Jukka K. Korpela
>> There is no such thing as a CSS validator. They just call it that way.
>>
> Sorry,
> I must disagree.
Really? Then you don't know what a "validator" is.
> HTML:
> The W3C MarkUp Validation Service
> http://validator.w3.org/
That's a validator, tuned for processing HTML documents. It has absolutely
nothing to do with CSS.
> CSS:
> W3C CSS Validation Service
> http://jigsaw.w3.org/css-validator/
That's not a validator. Their calling it one does not make it one, but it
surely causes confusion, as we have seen.
A validator checks whether a document complies with its Document Type
Definition (DTD). There is no DTD for CSS, since CSS is _not_ a notation
with its syntax defined in SGML "(an SGML application").
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Bertilo Wennergren
> A validator checks whether a document complies with its Document Type
> Definition (DTD). There is no DTD for CSS, since CSS is _not_ a notation
> with its syntax defined in SGML "(an SGML application").
The term "validator" has a clear and formal definition in the mark-up world
of HTML, SGML, XML etc. But CSS is not a part of that world, and as far as
I know there is no formal definition of the term "validator" in the world
that CSS belongs to. Thus we're free to use it in a loose common-langugage
meaning when we're talking about CSS.
So "CSS validator" can very well mean "a program that checks if the CSS code
follows the CSS rules".
--
Bertil Wennergren <bert...@gmx.net> <http://www.bertilow.com>
Stan Brown
Michael Lefevre <new...@michaellefevre.com> wrote in
comp.infosystems.www.authoring.stylesheets:
>If you don't specify it and a user stylesheet sets the body to
>be black-on-white, you'll get unreadable yellow-on-white. If you specify
>a background colour, you'll have a plain background over your page
>background image, and if you specify the same background image, you'll
>get a new copy of the image on the element.
background-color: transparent
This should be the default anyway. Why specify it, then?
Suppose your author stylesheet has a fairly light background image
and selects a fitting text color of #800 (medium-dark blue). Suppose
a user stylesheet specifies color: #FFF; background-color: #000 a in
your example. Since stylesheets cascade, that user would see blue-
on-black text. If you actually specify background-color:transparent
in your author stylesheet, text is now "blue on transparent", and
your image shows through as you intended, regardless of what may be
in a user stylesheet.
(The user stylesheet can still force the user's settings by marking
them "!important". But a user who makes background-color !important
without making text color !important as well deserves whatever s/he
gets.)
--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
"My theory was a perfectly good one. The facts were misleading."
-- /The Lady Vanishes/ (1938)
Stan Brown
comp.infosystems.www.authoring.stylesheets:
>"Steven R. Gerber" <Steven...@Technologist.com> wrote:
>
>>> There is no such thing as a CSS validator. They just call it that way.
>>>
>> Sorry, I must disagree.
>
>Really? Then you don't know what a "validator" is.
According to your definition, Jukka.
>> CSS:
>> W3C CSS Validation Service
>> http://jigsaw.w3.org/css-validator/
>
>That's not a validator. Their calling it one does not make it one, but it
>surely causes confusion, as we have seen.
>
>A validator checks whether a document complies with its Document Type
>Definition (DTD). There is no DTD for CSS, since CSS is _not_ a notation
>with its syntax defined in SGML "(an SGML application").
Okay, that's your definition. But I suggest that it's neither the
common one not a terribly useful one. A useful definition of
"validator" is "something that checks whether a given item or
process meets the relevant published standard."
The online Merriam-Webster <http://www.m-w.com/mw/netdict.htm> has
no entry for "validator", but we would assume it's an agent-noun for
"validate", which M-W defines as "confirm the validity of".
Stan Brown
Angela <onl...@optusnet.com.au> wrote in
comp.infosystems.www.authoring.stylesheets:
>Hi, I was just wondering how critical it really is to have your css
>validate,
The reason for validating your CSS is that different browsers do
different things with invalid CSS, sometimes unpredictable things.
Having valid CSS improves your chances of having your pages look ore
like you want them in more browsers.
> Mine works fine, as much as browsers let it, but doesn't validate
>because i haven't applied background colours to some classes that have
>specified font colours, The reason being that my menu is in a layer above a
>picture, and if i give it a background colour, it looks terrible. Are there
>any workarounds to this or i should just get over it and not care if it
>validates.
My opinion is that you _should_ care. The warnings are annoying, but
look behind them for the reason. You want to specify a background-
color because if you don't, and a user stylesheet does specify a
background color, your page will probably be unreadable.
The particular background color you want to specify is "transparent"
(no quotes). This will let the image shine through, as you intended.
Chris Hoess
> Jukka K. Korpela <jkor...@cs.tut.fi> wrote in
>
>>> W3C CSS Validation Service
>>> http://jigsaw.w3.org/css-validator/
>>
>>That's not a validator. Their calling it one does not make it one, but it
>>surely causes confusion, as we have seen.
>>
>>A validator checks whether a document complies with its Document Type
>>Definition (DTD). There is no DTD for CSS, since CSS is _not_ a notation
>>with its syntax defined in SGML "(an SGML application").
>
> Okay, that's your definition. But I suggest that it's neither the
> common one not a terribly useful one. A useful definition of
> "validator" is "something that checks whether a given item or
> process meets the relevant published standard."
On the contrary, I think it's a very useful definition within its scope,
namely, purported applications of ISO 8879. But since CSS is, as stated,
not such an application, there's no reason a definition of "validator"
operative only in that context should apply to it, rather than the common
English one.
--
Chris Hoess
Brian
>
> background-color: transparent
>
> This should be the default anyway. Why specify it, then?
>
> Suppose your author stylesheet has a fairly light background image
> and selects a fitting text color of #800 (medium-dark blue). Suppose
> a user stylesheet specifies color: #FFF; background-color: #000 a in
> your example. Since stylesheets cascade, that user would see blue-
> on-black text. If you actually specify background-color:transparent
> in your author stylesheet, text is now "blue on transparent", and
> your image shows through as you intended, regardless of what may be
> in a user stylesheet.
So what happens if the author sheet has
body {color white ; background: black }
li {color: yellow ; background: transparent }
and the user style sheet has
ul {color: blue ; background: yellow}
The author expects li elements to be yellow on black, but wouldn't the
user get yellow on yellow? I think this is the problem with not
setting background colors to let a background image show though.
--
Brian
follow the directions in my address to email me
Angela
background-color: transparent is perfect, i've been using dreamweaver and
just didn't think because if you select transparent it's just default and
nothing is specified in the stylesheet. It's been a while since i did all
the reading up on css and it just didn't occur to me.
Thanks again for the help,
Angela
Somewhere
"Stan Brown" <the_sta...@fastmail.fm> wrote in message
news:MPG.18c848dc1...@news.odyssey.net...
Jukka K. Korpela
> The term "validator" has a clear and formal definition in the mark-up
> world of HTML, SGML, XML etc.
Yes.
> But CSS is not a part of that world,
But it needs to coexist with it, desperately - CSS is pointless without a
markup system (or "language") that it relates to.
> So "CSS validator" can very well mean "a program that checks if the CSS
> code follows the CSS rules".
Isn't the word "checker" much more understandable and shorter?
There's something around the word "validator" that makes it somehow sexy.
But as we have seen, in this discussion and elsewhere, it suggests a
definitive comparison of something against objective criteria - which is a
correct denotation and connotation for "validation" in the SGML sense,
provided that one really understands what the criteria include (and what
they don't).
So is it a surprise that people get confused when a "validator" says that
there is something wrong in their style sheet and there actually isn't?
(Even if a CSS checker would be limited to reporting violations of CSS
specifications only, it would be misleading to call it a validator. The
word would mislead people as regards to which aspects are actually checked
by the checker. For SGML, this can be objectively decided, for a real
validator.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Keith Bowes
>
> The online Merriam-Webster <http://www.m-w.com/mw/netdict.htm> has
> no entry for "validator", but we would assume it's an agent-noun for
> "validate", which M-W defines as "confirm the validity of".
>
But since the referenced pages are now called "validation services"
rather than "validators", I'd say their meaning is in the jurisdiction
of colloquial English. Definition 1b of "validate" ("to grant official
sanction to by marking") seems to describe it the best (assuming you
consider the provided optional icons as marking). The SGML terminology
is irrelevant in the case of CSS, being that CSS is not an SGML
application and in that the two services are separate (and are, in fact,
written in different programming languages).
Nick Theodorakis
Is this valid CSS?
div
{
float: left;
}
The w3c css "validator" says,
"No error or warning found."
But the CSS spec says:
<blockquote>
Visual Formatting Model
. . . .
9.5 Floats
. . . .
A floated box must have an explicit width (assigned via the 'width'
property, or its intrinsic width in the case of replaced elements)...
</blockquote>
See: <http://www.w3.org/TR/REC-CSS2/visuren.html#floats>
So in the example above, there is no width specified, so why is it
considered valid?
I suppose if the block contained only a replaced element such as an
<img> then it would have an intrinsic width. But shouldn't the
"validator" at least give a warning?
Nick
--
Nick Theodorakis
nicholas_t...@urmc.rochester.edu
Alan J. Flavell
> My opinion is that you _should_ care. The warnings are annoying, but
> look behind them for the reason. You want to specify a background-
> color because if you don't, and a user stylesheet does specify a
> background color, your page will probably be unreadable.
Correct, and an example of what could go wrong has already been given
on this thread.
> The particular background color you want to specify is "transparent"
> (no quotes). This will let the image shine through, as you intended.
But think about it: that just moves the original problem (i.e of a
possibly inappropriate combination of text and background colours
resulting after the cascade) elsewhere.
In fact, there's an item on the mailing list for the CSS vali^Wchecker
where I make this point to them, and they agree that a specification
of 'transparent' probably ought to get a warning just as the omission
of a specification gets one.
As another has commented on this thread, though, the exercise gets
difficult if the intention is for an overall background image to be
used. Seems as if that aspect hadn't quite been thought-through from
the point of view of the cascade mechanism.
Alan J. Flavell
> I had a stylesheet with this issue - is there a practical solution to
> avoid the issue that this warning is about?
If it was only a matter of text and background colour, then the advice
is clear: all stylesheets (author or user) at every specificity should
either specify both colours explicitly, or neither. Even if the
background is _expected_ to be the same colour, since the cascade
could change that.
> I'm afraid I don't have a
> page to point at, but if you have, say, a page with a dark blue
> background image and white text, and you then want to specify yellow text
> on a particular element, what can you do about the background on that
> element?
Background images are admittedly a problem.
There's something to be said for keeping background images out of
running text if possible. If the image is sufficiently low-contrast
as not to upset the clarity of running text then it might be
acceptable for small snippets of text (e.g links) to have plain-colour
backgrounds. Then the problem itself goes away.
If it's a texture then you might respecify the background image for
the inner element, and hope that the joins don't show. OK, I guess
that's not the answer you wanted.
If that's not acceptable then in theory you can respecify the image
and define its position as fixed, and the browser _should_ line it up
correctly; whether it will in practice is a different issue.
So, finally I guess you could just do the obvious i.e specifying
'transparent', and hoping that it wins the cascade. :-} But the
logical possibility of it going wrong is still there.
Btw, just a reminder to anyone who said that it's pointless to ever
specify transparent because it's the default anyway: that's not true
when stylesheets are cascaded. The default (as far as your own
stylesheet is concerned) is whatever you got from any cascaded
stylesheet(s). So, if transparent is what you want, then there _is_
some sense in asking for it. (But the logical companion of an
transparent background is an inherited text colour, rather than some
explicitly supplied colour.)
That's the logical analysis that underlies the thing, anyhow, AFAICS.
It's up to you if you want to take a design decision to flout the
rules; I'm just doing my best to throw light on how the logic would
work. As they say, you can't take an informed decision to break the
rules until you are clear about what the rules are ;-)
Bjoern Hoehrmann
>Is this valid CSS?
>
>div
>{
>float: left;
>}
Yes, see <http://www.w3.org/TR/CSS2/conform#valid-style-sheet>:
[...]
Valid style sheet
[...]
A valid CSS2 style sheet must be written according to the grammar of
CSS2. Furthermore, it must contain only at-rules, property names, and
property values defined in this specification.
[...]
>I suppose if the block contained only a replaced element such as an
><img> then it would have an intrinsic width. But shouldn't the
>"validator" at least give a warning?
Maybe. I suggest proposing this to the <www-vali...@w3.org>
mailing list.
Bertilo Wennergren
> Bertilo Wennergren <bert...@gmx.net> wrote:
>> The term "validator" has a clear and formal definition in the mark-up
>> world of HTML, SGML, XML etc.
> Yes.
>> But CSS is not a part of that world,
> But it needs to coexist with it, desperately - CSS is pointless without a
> markup system (or "language") that it relates to.
True. And from a _practical_ point of view - for the actual users - the CSS
Validator at W3C does the same thing as does the HTML Validator at W3C. So
it seems convenient to use the same word for both. Anyone who is capable of
understanding what really makes an HTML validator a validator, is also
capable of understanding that a CSS validator is not a validator in the
same sense. If you know what a DTD is, you probably also know that CSS does
not use DTDs. So there will be no misunderstanding.
>> So "CSS validator" can very well mean "a program that checks if the CSS
>> code follows the CSS rules".
> Isn't the word "checker" much more understandable and shorter?
Could be. But since the most important CSS checker is named "CSS Validator"
it seems best to go with that flow.
> There's something around the word "validator" that makes it somehow sexy.
> But as we have seen, in this discussion and elsewhere, it suggests a
> definitive comparison of something against objective criteria - which is a
> correct denotation and connotation for "validation" in the SGML sense,
> provided that one really understands what the criteria include (and what
> they don't).
There are formal syntax rules for CSS. I take it that the CSS "validator" at
W3C checks CSS for deviations from those syntax rules. That seems formal
and objective enought for me.
> So is it a surprise that people get confused when a "validator" says that
> there is something wrong in their style sheet and there actually isn't?
I don't think a switch to "checker" would change anything about that.
> (Even if a CSS checker would be limited to reporting violations of CSS
> specifications only, it would be misleading to call it a validator. The
> word would mislead people as regards to which aspects are actually checked
> by the checker. For SGML, this can be objectively decided, for a real
> validator.)
The messages do clearly distinguish between errors and warnings, and you can
also choose if you want to see any warnings.
People misunderstand the HTML validator too - al lot.
Bertilo Wennergren
The "validator" just reports "no errors found". The word "valid" is not
being used.
The CSS validator/checker at W3C checks for violations of some kinds of
errors in CSS. It seems it mostly checks for _syntax_ errors.
The HTML validator also only checks for certain kinds of errors. Other
errors, that don't violate anything in the DTD, just in the prose of the
relevant HTML recommendation, are not being checked.
So "valid" for HTML has one meaning (very formally and strictly defined),
and "valid" for CSS (at least as far as the W3C CSS Validator goes) has
another, probably less formally defined meaning. I don't see a problem in
that. HTML (SGML, XML) has one terminology. CSS has another.
kchayka
>
> In fact, there's an item on the mailing list for the CSS vali^Wchecker
> where I make this point to them, and they agree that a specification
> of 'transparent' probably ought to get a warning just as the omission
> of a specification gets one.
>
> As another has commented on this thread, though, the exercise gets
> difficult if the intention is for an overall background image to be
> used. Seems as if that aspect hadn't quite been thought-through from
> the point of view of the cascade mechanism.
This aspect is usually overlooked whenever the subject of
color/background-color pairs comes up. I use "transparent" as a
background-color often enough, but it virtually always has something to
do with images, where specifying any particular color has an undesirable
effect in a conforming browser. If the W3C CSS validator starts
flagging "transparent" as a warning, then I might as well just stop
specifying background-color altogether in these cases. Now, what has
really been accomplished? Nothing, except I just traded one warning for
another.
--
To email a reply, remove (dash)ns(dash). Mail sent to the ns
address is automatically deleted and will not be read.
Stan Brown
comp.infosystems.www.authoring.stylesheets:
>So what happens if the author sheet has
>
>body {color white ; background: black }
>li {color: yellow ; background: transparent }
>
>and the user style sheet has
>
>ul {color: blue ; background: yellow}
^^ I'm pretty sure you meant "li" here.
Also I think you meant to say "background-color" and not
"background".(*)
>The author expects li elements to be yellow on black, but wouldn't the
>user get yellow on yellow?
Nope. The browser tries to figure out what color the background
should be in an <li> element. The users stylesheet says yellow, but
any setting in the author stylesheet overrides that. Since the
author stylesheet says background-color is transparent, that's what
color the background will be -- not transparent over yellow, but
transparent.
In other words, the stylesheet that is applied to any given Web page
is a merge, from low to high priority, of user stylesheet, author
stylesheet, and !important items from user stylesheet. A selector
and property from a lower-priority stylesheet gets overridden by the
same selector and property if found in a higher-priority stylesheet.
If the author stylesheet sets "li { background-color: ____ }" then
it doesn't matter whether the users stylesheet sets background-color
in li or not.
The W3C spec explains this "cascade" much better, and I recommend
you have a look at <http://www.w3.org/TR/REC-CSS2/cascade.html>. I
know I oversimplified the previous paragraph, and it's even possible
that I said something technically wrong though I tried to be
careful.
(*)The fact that you said "background" rather than "background-
color" complicates things. "background" is a shortcut for several
properties. Saying "background: transparent" sets the background-
color to transparent, but it also resets background-image,
background-position, background-attachment, and background-repeat
back to their default values. So I think you really want background-
color and not background. See
<http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background>.
Stan Brown
>(Even if a CSS checker would be limited to reporting violations of CSS
>specifications only, it would be misleading to call it a validator. The
>word would mislead people as regards to which aspects are actually checked
>by the checker. For SGML, this can be objectively decided, for a real
>validator.)
Jukka, I think you are trying to take a SGML term and apply it to
the whole world. Perhaps it would make more sense to think of "SGML
validators" as a genus of the "validators" family. There are many
specifications out there that are not SGML, and it is still possible
to validate against them. It can be said unambiguously whether a C
program, or a stylesheet, or an Usenet article, is syntactically
valid; and a logical name for programs that make those
determinations is "validator".
You might want to read the article "popularized technicalities" in
Fowler's /Modern English Usage/ second edition. (Then again, you
might not. :-)
Michael Lefevre
wrote:
> Brian <br...@wfcr.deletethispart.org> wrote in
> comp.infosystems.www.authoring.stylesheets:
>
>>So what happens if the author sheet has
>>
>>body {color white ; background: black }
>>li {color: yellow ; background: transparent }
>>
>>and the user style sheet has
>>
>>ul {color: blue ; background: yellow}
> ^^ I'm pretty sure you meant "li" here.
no, I think that his point was what would happen with author specifying
body and li, and user specifying ul.
> Also I think you meant to say "background-color" and not
> "background".(*)
probably...
>>The author expects li elements to be yellow on black, but wouldn't the
>>user get yellow on yellow?
>
> Nope. The browser tries to figure out what color the background
> should be in an <li> element. The users stylesheet says yellow, but
> any setting in the author stylesheet overrides that. Since the
> author stylesheet says background-color is transparent, that's what
> color the background will be -- not transparent over yellow, but
> transparent.
[snip]
not with li, but given the ul as he stated, it would. the user/author
combination above will result in:
body {color white ; background: black }
li {color: yellow ; background: transparent }
ul {color: blue ; background: yellow}
so (assuming reasonable html), the li will indeed become yellow on
yellow.
specifying the transparent background makes it less likely to be
unreadable, but it's not guaranteed. I guess the author could explicitly
specify a transparent background on all the element in the cascade...
that would make it even more unlikely to end in a mismatch, but still not
impossible.
--
Michael
Alan J. Flavell
> Brian <br...@wfcr.deletethispart.org> wrote in
> comp.infosystems.www.authoring.stylesheets:
>
> >So what happens if the author sheet has
> >
> >body {color white ; background: black }
> >li {color: yellow ; background: transparent }
> >
> >and the user style sheet has
> >
> >ul {color: blue ; background: yellow}
> ^^ I'm pretty sure you meant "li" here.
I don't think so: in fact I think you've missed the key feature of the
argument.
An analogous effect would result if the user stylesheet had specifed
body attributes with !important; but by using one of the intervening
elements for his demonstration, Brian has shown that even a user
stylesheet which doesn't use !important can upset the cart.
Incidentally, we keep talking about author and user stylesheets as if
they were the only two possibilities, but in general the author might
be required to include their company's corporate stylesheet too, for
example. And then if the company gets a new team of design
consultants in, you can pretty much guarantee that the corporate
stylesheet will change without much warning, which is another good
reason for taking care that a design can still be used after the
cascade has done its work.
Headless
>>ul {color: blue ; background: yellow}
> ^^ I'm pretty sure you meant "li" here.
>
>Also I think you meant to say "background-color" and not
>"background".(*)
background:yellow
background:url(img.png)
background:url(img.png) 0 0
background:#eee url(img.png) 0 0
background:url(img.png) 0 0 fixed
background:url(img.png) repeat-x
are all valid usage of the short hand property "background"
Headless
Stan Brown
comp.infosystems.www.authoring.stylesheets:
>Stan Brown <the_sta...@fastmail.fm> wrote:
>>Also I think you meant to say "background-color" and not
>>"background".(*)
>
>background:yellow
>background:url(img.png)
>background:url(img.png) 0 0
>background:#eee url(img.png) 0 0
>background:url(img.png) 0 0 fixed
>background:url(img.png) repeat-x
>
>are all valid usage of the short hand property "background"
Of course they are (assuming you haven't made some non-obvious
typing error). So what? How does that invalidate my point? Did you
even bother to read my point? It was a whole paragraph of
explanation, and nowhere did I claim that "background:yellow" was
not valid CSS, just that it was probably not what the PP intended.
Stan Brown
comp.infosystems.www.authoring.stylesheets:
>On Fri, Feb 28, Stan Brown inscribed on the eternal scroll:
>
>> Brian <br...@wfcr.deletethispart.org> wrote in
>> comp.infosystems.www.authoring.stylesheets:
>>
>> >So what happens if the author sheet has
>> >
>> >body {color white ; background: black }
>> >li {color: yellow ; background: transparent }
>> >
>> >and the user style sheet has
>> >
>> >ul {color: blue ; background: yellow}
>> ^^ I'm pretty sure you meant "li" here.
>
>I don't think so: in fact I think you've missed the key feature of the
>argument.
Ah! It seems to me that this example shows that the author
stylesheet that specifies <li> colors should also specify <ul>
colors.
So the validator should not warn about "transparent" per se, but
perhaps about specifying colors for a child-type element without
also specifying them for its required parent. This is a bit murky
since <li> can be a child of <ol> or <ul>; perhaps the stylesheet
that specifies <li> and <ol> colors doesn't specify <ul> colors
because in fact no Web page that links to that stylesheet actually
uses an <ul>.
>An analogous effect would result if the user stylesheet had specifed
>body attributes with !important; but by using one of the intervening
>elements for his demonstration, Brian has shown that even a user
>stylesheet which doesn't use !important can upset the cart.
I guess my position is that the author should code a stylesheet so
that it will do the right thing after the cascade, but not to defend
against a user who is bent on shooting himself in the foot. I still
believe that a user who specifies one of color and background-color
but not the other deserves whatever he gets. (But I'm prepared to be
argued out of that position, if you can made a reasonable case why a
user should specify one of those but not the other.)
>Incidentally, we keep talking about author and user stylesheets as if
>they were the only two possibilities, but in general the author might
>be required to include their company's corporate stylesheet too, for
>example. And then if the company gets a new team of design
>consultants in, you can pretty much guarantee that the corporate
>stylesheet will change without much warning, which is another good
>reason for taking care that a design can still be used after the
>cascade has done its work.
On this latter point I think we all agree.
Jukka K. Korpela
> Perhaps it would make more sense to think of "SGML
> validators" as a genus of the "validators" family.
On some other planet, yes. On Earth, it would just add to the confusion we
have.
> There are many
> specifications out there that are not SGML, and it is still possible
> to validate against them.
For some definitions of "validate", yes.
> It can be said unambiguously whether a C
> program, or a stylesheet, or an Usenet article, is syntactically
> valid;
"Syntactically correct" is the phrase I've learned. And it pretty much
depends on what "syntax" means. Considering what _linguists_ mean by it, I
would not say that it is possible to decide automatically whether a Usenet
article is syntactically correct. Considering RFC 1036, it's a different
issue, but the it's a _completely_ different meaning of "syntactic
correctness" (or "validity", if you insist). This is the basic point around
"CSS validity".
What good does it do to authors to know that a style sheet is or is not
"syntactically valid", if they have no idea, or have a completely wrong
idea, of what "syntactically valid" means?
The style sheet
body { font-size:1000000000000mm; color: black; background: black; }
is certainly "syntactically correct" in the sense of complying with any
formal or semi-formal requirement in CSS specifications. It would be
absurd, however, to say that it is "correct" or "valid" in the everyday
sense of these words.
> and a logical name for programs that make those
> determinations is "validator".
Why wasn't lint named a "validator"? Why aren't compilers called
"validators" even if they check the BNF syntax?
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Alan J. Flavell
> I guess my position is that the author should code a stylesheet so
> that it will do the right thing after the cascade, but not to defend
> against a user who is bent on shooting himself in the foot.
Hang on: the point of a user stylesheet might be to compensate for
some user problem, such as colour blindness, or a need to read light
text on a dark ground although the author has called for the opposite.
> I still believe that a user who specifies one of color and
> background-color but not the other deserves whatever he gets.
Sure, but that isn't the point. _Both_ parties to the agreement need
to specify either both colours or neither, or the cascade logic can
fail to produce a usable combination.
> (But I'm prepared to be
> argued out of that position, if you can made a reasonable case why a
> user should specify one of those but not the other.)
I've said repeatedly that both parties need to specify either both
colours or neither, at each specificity. Where did you get the idea
that I'm trying to persuade you to only specify one?
You're still missing the point. It's about the author asking for
"transparent" on an inner element (while specifying an explicit text
colour), and getting whatever background comes through from an outer
element.
cheers
Stan Brown
>
>> I guess my position is that the author should code a stylesheet so
>> that it will do the right thing after the cascade, but not to defend
>> against a user who is bent on shooting himself in the foot.
>
>Hang on: the point of a user stylesheet might be to compensate for
>some user problem, such as colour blindness, or a need to read light
>text on a dark ground although the author has called for the opposite.
"Hang on"?? I agree with what you say -- in fact I've said it myself
in this forum more than once.
A visually impaired user can set text and background colors and make
them !important so that a modern browser will honor those settings
regardless of the author's intentions. And that's a good thing: it
increases accessibility.
But a visually impaired user who specifies color and not background-
color is shooting himself in the foot. If he can't read the result,
that's the user's fault and not the author's; and the remedy is
within the user's control. If you want white text on black
background, you don't just put color:white in your stylesheet, you
put color:white; background-color:black.
It's like a hearing-impaired user who sets the television volume too
low: the broadcasters should not compensate for that possibility by
making the program louder.
>> I still believe that a user who specifies one of color and
>> background-color but not the other deserves whatever he gets.
>
>Sure, but that isn't the point. _Both_ parties to the agreement need
>to specify either both colours or neither, or the cascade logic can
>fail to produce a usable combination.
Well, of course. I don't know what I might have said to give you the
impression I thought otherwise.
>You're still missing the point. It's about the author asking for
>"transparent" on an inner element (while specifying an explicit text
>colour), and getting whatever background comes through from an outer
>element.
No, Alan, I grasp that point quite well, and I said so:
>Ah! It seems to me that this example shows that the author
>stylesheet that specifies <li> colors should also specify <ul>
>colors.
By "colors" I meant both color and background-color; perhaps you
read it as [font] color only?
The same principle applies with other sets of inner and outer
elements, but since our discussion was in the context of li and ul
it didn't seem necessary to list them.
Stan Brown
>
>> Perhaps it would make more sense to think of "SGML
>> validators" as a genus of the "validators" family.
>
>On some other planet, yes. On Earth, it would just add to the confusion we
>have.
There's no need to get snippy, particularly when several other
people have also pointed out to you that your definition really
doesn't match the way most people use the word.
>> There are many
>> specifications out there that are not SGML, and it is still possible
>> to validate against them.
>
>For some definitions of "validate", yes.
You certainly have the right to use the word "validator" in whatever
way you wish. But it is more than a little disingenuous to castigate
others who use it in the common way. As has been pointed out, even
the W3C seem to think that their CSS validator is a validator. If
you want to deny that, it's your privilege but you're swimming
against the current.
[big snip]
>Why wasn't lint named a "validator"? Why aren't compilers called
>"validators" even if they check the BNF syntax?
Is this a serious question? It's a long time since I've used lint,
but as far as I can remember it _is_ a validator, one that works on
groups of files (projects, perhaps) and not just single translation
units. And of course a compiler isn't called a validator because
that's not its primary function.
Jukka K. Korpela
>>Why wasn't lint named a "validator"? Why aren't compilers called
>>"validators" even if they check the BNF syntax?
>
> Is this a serious question?
Yes it is.
> It's a long time since I've used lint,
> but as far as I can remember it _is_ a validator,
And if its _name_ had been "C validator", you would be rather sure about
that, wouldn't you? Especially if the C standardization committee had given
it that name. Exactly my point. You would have an idea of what it is, on
the basis of the name, irrespectively of what it actually is. (Quite a many
people even believe that the "CSE HTML Validator" is a validator!)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Headless
>even bother to read my point? It was a whole paragraph of
>explanation, and nowhere did I claim that "background:yellow" was
>not valid CSS
Skim read your message, missed half of it, sorry.
Headless
Lauri Raittila
wrote:
> (*)The fact that you said "background" rather than "background-
> color" complicates things. "background" is a shortcut for several
> properties. Saying "background: transparent" sets the background-
> color to transparent, but it also resets background-image,
> background-position, background-attachment, and background-repeat
> back to their default values. So I think you really want background-
> color and not background. See
> <http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background>.
Well, I would think exactly opposite. If you want transparent background,
background-color:transparent would be worse, if:
User:
element {background:url(dark.png) black;
color:white;
}
Author
body {background:url(light.png) white;}
element {background-color:transparent;
color:black
}
Happens:
black text on dark background.
If author uses background:transparent; then user sees black on light
image.
If you can please give us example when it's good to use
background-color:transparent instead of background:transparent, when you
(as an author) don't set other background properties elsewhere.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Saapi lähettää meiliä, jos aihe ei liity ryhmään, tai on yksityinen
tjsp., mutta älä lähetä samaa viestiä meilitse ja ryhmään.
Stan Brown
comp.infosystems.www.authoring.stylesheets:
>In article <MPG.18c937987...@news.odyssey.net>, Stan Brown
>wrote:
>
>> (*)The fact that you said "background" rather than "background-
>> color" complicates things.
>background-color:transparent instead of background:transparent, when you
>(as an author) don't set other background properties elsewhere.
Sigh. The OP _told_ us that the page as a whole had an image
background, and that's why the OP wanted transparent background for
the text.
And though it's not obvious from your selective quote, I did not
advocate setting background color alone, but setting it with text
color. Obviously it would be a bad idea to et one without the other.
--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
"Walrus meat as a diet is less repulsive than seal."
-- Harry de Windt, /From Paris to New York by Land/ (1904)
Lauri Raittila
wrote:
> Lauri Raittila <la...@raittila.cjb.net> wrote in
> comp.infosystems.www.authoring.stylesheets:
> >In article <MPG.18c937987...@news.odyssey.net>, Stan Brown
> >wrote:
> >
> >> (*)The fact that you said "background" rather than "background-
> >> color" complicates things.
> >If you can please give us example when it's good to use
> >background-color:transparent instead of background:transparent, when you
> >(as an author) don't set other background properties elsewhere.
>
> Sigh. The OP _told_ us that the page as a whole had an image
> background, and that's why the OP wanted transparent background for
> the text.
So, OP would like to have some other background image for links, that was
used in whole page? Why don't you read whole post, before replying? And
if you think I'm mistaken, would you quote the relevent part.
> And though it's not obvious from your selective quote, I did not
> advocate setting background color alone, but setting it with text
> color.
Well, I certainly never thought you wouldn't know that. It was not at all
what I meant. I meant you were only using background-color, whitout
background-image. That is as almost as bad as not using background color
at all, only reason it is not is that not many people use bacground
images in their userstyles.
If you only have set text color and background color, it means that you
haven't set background image and therefore it is possible that people see
black on black or white on white, as background image overrides
background color.
> Obviously it would be a bad idea to et one without the other.
Yes, as well as it is bad idea to specify background color whitout
specifying background image. And if you want transparent background on
link, you do want to set background image to default which is none.
Otherwise you won't get transparent background, unless there is not
background image in userstyle. (it is true that hardly anyone has
background image for links in their userstylesheet, but there might be
one - and there is no problem whatsoever to use background shorthand, as
it even has better support in old browsers IIRC.)
Stan Brown
>used in whole page?
No, the links were not to have any background image of their own,
but the image for the whole page was to shine through all the text.
This was pretty clear from the OP's first query, as I recall.
Perhaps that never reached you? It will surely be in google by now.
> Why don't you read whole post, before replying?
"Do as I say, not as I do"?
Lauri Raittila
wrote:
> Lauri Raittila <la...@raittila.cjb.net> wrote in
> comp.infosystems.www.authoring.stylesheets:
> >So, OP would like to have some other background image for links, that was
> >used in whole page?
>
> No, the links were not to have any background image of their own,
> but the image for the whole page was to shine through all the text.
Exactly. But if author only uses 'background-color' for links, and not
'background-image', user that has set some 'background-image' for links
will still see this 'background-image'. How many times I must repeat
this?
> This was pretty clear from the OP's first query, as I recall.
> Perhaps that never reached you? It will surely be in google by now.
Perhaps you still failed to understand my point. Which was: if you don't
specify 'bacground-image', browser uses users default which is not
necessarily none. OTOH, if you specify the color using 'background'
shorthand, it will be default specified in CSS spec, in other words none.
So your recommendation of avoiding 'background' shorthand is not good,
especially in this case.
Why on earth one wouldn't want to reset background-image,
background-position, background-attachment, and background-repeat
back to their default values, if one want's to have transparent
background on particular element? What good would it do?
> > Why don't you read whole post, before replying?
>
> "Do as I say, not as I do"?
Well, maybe you just did not understand my post. Maybe it has something
to do with my English skills.