Highlight Words

Jukka K. Korpela wrote:

What do the FAQs say about specifying color whenever you
specify background, and vice versa?

What you said was this:

It is essential to set color whenever you set background.

Which is simply wrong. It's far from "essential" to do this.

It's good practice to do it, and it's even important to consider doing
it. But the real need is to check that the colours are going to be
compatible, and you can do that (more slowly) by studying the CSS
context of the test of the page. If your page is demonstrably never
going to set an incompatible foreground for your chosen highlight
background, then setting foreground explicitly is superfluous and
certainly not "essential".

You will probably retort with some straw-man argument about the need to
cope with user stylesheets over-ruling the page's default foreground
color. It's a fair point to raise, but an explicit foreground color
wouldn't fix it either. We just don't know what the user's foreground
preference will be, or whether they themselves have been careful to
avoid specifying it by a route that might give rise to conflicts.

As to his dogmatic assertion that <strong> should be used rather than
span class="foo" >, then that's just pedantry stretched beyond the
boundaries of rationality. HTML's semantics aren't sophisticated
enough, let alone rigid enough, to require any absolute dogma like
this.

Agreed! :-D

So you now say that you agree with someone who says that there is no point
in using semantically correct markup is better than semantically empty
markup?

I said nothing of the sort. Personally I'd use <em class="search-term"

rather than <span>. My disagreement with your post is twofold: trivally that I'd use <em> "Indicates emphasis." rather than <strong> "Indicates stronger emphasis.". Mainly though I <strong>disagree</strong> (note the "stronger emphasis") that the use of <span> is "essentially wrong".

If you want a field of study to make such absolute statements about, it
needs to be one with more absolute significance than the trivia of
HTML's paltry semantics. You might like to consider Creationism, a
popular choice these days I hear.

..oO(Andy Dingley)

Jukka K. Korpela wrote:

It is essential to set color whenever you set background.

Which is simply wrong. It's far from "essential" to do this.

It's good practice to do it, and it's even important to consider doing
it. But the real need is to check that the colours are going to be
compatible, and you can do that (more slowly) by studying the CSS
context of the test of the page. [...]

ACK

You will probably retort with some straw-man argument about the need to
cope with user stylesheets over-ruling the page's default foreground
color. It's a fair point to raise, but an explicit foreground color
wouldn't fix it either. [...]

Actually if someone uses a user stylesheet then he should know what he's
doing. If he wants to override certain properties then it's _his_ task
to do it properly by setting his own background _and_ foreground colors.
I as the author just have to make sure that the site works well in all
normal and usual situations. I don't have to care much about the user's
own stylesheets.

Just my 2 cents

Micha

Scripsit Andy Dingley:

Jukka K. Korpela wrote:

What do the FAQs say about specifying color whenever you
specify background, and vice versa?

What you said was this:
It is essential to set color whenever you set background.

Which is simply wrong. It's far from "essential" to do this.

Apparently you'd need to check the FAQs. People reduce the amount of
pointless babbling after a few doses of FAQs, you know.

But the real need is to check that the colours are going to be
compatible,

That's another real need, and for it, you need to know what "the colours"
are. Unless you set the content color and the background together, you can't
even know that.

If your page is demonstrably never
going to set an incompatible foreground for your chosen highlight
background, then setting foreground explicitly is superfluous and
certainly not "essential".

Try reading the FAQs. I'm sure they explain something about the "C" in
"CSS".

You will probably retort with some straw-man argument about the need
to cope with user stylesheets

Do you know what a straw-man argument is? It is a fictitional argument that
you set up and claim it to be someone else's, then attack against it. So if
the argument you describe here were a straw-man argument, then this would
all be _your_ fallacy. Instead, it's the real argument presented, among
other things, in FAQs and in CSS specifications.

an explicit
foreground color wouldn't fix it either.

An explicit foreground color is part of the stylesheet author's job. He's
not expected to do other people's job, just to do his part in coping with
the "C" in "CSS" (the cascade).

So you now say that you agree with someone who says that there is no
point
in using semantically correct markup is better than semantically
empty
markup?

I said nothing of the sort.

You refuted the principle of using logical markup instead of semantically
empty <span>, and even tried to ridicule it as dogmatism and whatever.

Mainly though I
strong>disagree</strong> (note the "stronger emphasis") that the
use of <span> is "essentially wrong".

You don't seem to agree with yourself here, but you apparently end up with
saying that there is no essential difference between using semantically
empty markup (which will be ignored in CSS-disabled browsing) and semantic
markup (which is expected to be rendered in _some_ useful way even in
CSS-disabled browsing). That's basically how I described your position,
though I didn't mention that put _strong_ emphasis on it.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Scripsit Michael Fesser:

Actually if someone uses a user stylesheet then he should know what
he's doing.

If an author uses an author stylesheet, he should understand the "C" in
"CSS".

If he wants to override certain properties then it's
_his_ task to do it properly by setting his own background _and_
foreground colors.

So you require a user to do something that you, as an author, don't bother
doing?

There's nothing technically wrong with, say, a user style sheet like

* { background: black; color: white; }

When a page becomes a mess because an author style sheet sets, for some
element, background color but not content color, it is definitely the
author's fault.

I as the author just have to make sure that the
site works well in all normal and usual situations.

For that, you need to understand the "C".

I don't have to
care much about the user's own stylesheets.

So why do you think they call CSS _cascading_ style sheets? Things would be
simpler if user and author style sheets wouldn't need to coexist. But they
do.

I'm pretty sure this _is_ in the FAQs. At least it should be. You've
presented a very common fallacy - _after_ this line of thinking had been
described as erroneous.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

..oO(Jukka K. Korpela)

Scripsit Michael Fesser:

If he wants to override certain properties then it's
_his_ task to do it properly by setting his own background _and_
foreground colors.

So you require a user to do something that you, as an author, don't bother
doing?

In this particular case, yes.

There's nothing technically wrong with, say, a user style sheet like

* { background: black; color: white; }

When a page becomes a mess because an author style sheet sets, for some
element, background color but not content color, it is definitely the
author's fault.

Even with a "properly" written stylesheet, which specifies all colors,
the site might still look a bit messy, like a patchwork. Something like

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

would make more sense, if the user really wants to make sure that the
site adheres to his preferences.

I as the author just have to make sure that the
site works well in all normal and usual situations.

For that, you need to understand the "C".

The user is free to override anything he wants, I don't hinder him.

I don't have to
care much about the user's own stylesheets.

So why do you think they call CSS _cascading_ style sheets? Things would be
simpler if user and author style sheets wouldn't need to coexist. But they
do.

Yep. And I don't have a problem with it. But if the user wants to make
more drastically changes to a site's appearance than just the link color
for example, then he should be prepared for unwanted results and take
the appropriate actions if necessary.

Micha

Scripsit Michael Fesser:

Even with a "properly" written stylesheet, which specifies all colors,
the site might still look a bit messy, like a patchwork. Something
like

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

would make more sense, if the user really wants to make sure that the
site adheres to his preferences.

This wasn't about _your_ preferences but about a possible user style sheet
that is, unlike _your_ author style sheet, technically correct.

It's not really our business at all to consider what users _should_ set in
their user style sheets, but just as a casual note, I'd like to mention that
it's quite possible to wish to set background and foreground color for all
elements for which a page does not set them. Actually, that's more or less
what _every_ user does, to some extent at least, either implicitly (by
accepting their browser defaults, which logically correspond to a browser
style sheet) or explicitly (by setting them in a user style sheet _or_ by
setting the color settings in browser menus).

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

Jukka K. Korpela wrote:

Scripsit shapper:

In the results web page I would like to give a grey background to the
words which were used as Keywords for the search.

Is this a trick question?

At least the three answers you've got are essentially the same, and
essentially wrong.

So maybe it was a genuine question, though it looks _very_ elementary.

Use <strong> markup for the words, optionally with a class attribute if
you use <strong> for other emphasis as well

Most likely, especially if any of the text being indexed is itself HTML
that might contain tags of its own.

, and something like

strong { background: #ddd;
color: black;
font-weight: normal;
padding: 0 0.1em; }

Why <strong> versus <em>? Here's an opportunity to note that any
semantic distinction between the notions of "strongness" and "emphasis"
is arbitrary, and leaves one to guess that the only reason that tags
exist with both names is that the committee felt that both italics and
boldfacing had to be covered by the new, presentation-free taxonomy.

..oO(Jukka K. Korpela)

This wasn't about _your_ preferences but about a possible user style sheet
that is, unlike _your_ author style sheet, technically correct.

Mine is technically correct as well. A warning is not an error.
And some people even consider that warning a bug.

Micha

Scripsit Michael Fesser:

.oO(Jukka K. Korpela)

This wasn't about _your_ preferences but about a possible user style
sheet that is, unlike _your_ author style sheet, technically correct.

Mine is technically correct as well.

It's not technically correct to use CSS code that does not take the cascade
into account. Technical correctness is more than obeying syntax rules.
Setting
body { color: black; background: black; }
does not violate any syntax rules either, but it is not technically correct.

A warning is not an error.

Nobody said it was. A warning may suggest that there might be an error or a
problem.

And some people even consider that warning a bug.

You are referring to people who do not understand the cascade or don't care
about it.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

..oO(Jukka K. Korpela)

It's not technically correct to use CSS code that does not take the cascade
into account. Technical correctness is more than obeying syntax rules.
Setting
body { color: black; background: black; }
does not violate any syntax rules either, but it is not technically correct.

Depends on how you define "technically correct". That rule alone is
pretty useless, but in another context it might make some sense.

Micha