Highlight Words

[shapper]

Hello,

I am creating a search engine which searches keywords inside SQL
database and displays the results in a web page.

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

How can I do this?

Thanks,

Miguel

[Dag Sunde]

shapper wrote:

Hello,

I am creating a search engine which searches keywords inside SQL
database and displays the results in a web page.

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

How can I do this?

When you generate the result page, wrap the search words in the text
with <span class='search'>theword</spanbefore serving the result
to the client.

in your css you can then set:

.search {
background-color: #7f7f7f;
}

--
Dag.

[Sherm Pendley]

"shapper" <md*****@gmail.comwrites:

I am creating a search engine which searches keywords inside SQL
database and displays the results in a web page.

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

How can I do this?

On the server, enclose the keywords in <span class="keyword">...</span>
elements. How to do that will vary, and it's off-topic here, so if you're
having trouble with that part, ask in whatever group is appropriate for
the server-side tech you're using.

Then style as appropriate in your stylesheet, for instance:

..keyword {
background-color: #eee;
}

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Nik]

shapper wrote:

Hello,

I am creating a search engine which searches keywords inside SQL
database and displays the results in a web page.

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

l

>

You can enclose the words in a span.:
<span class="searchterm">these words are highlighted</span>

and then use span.searchterm{background-color:grey;} in your CSS.

The usual disclaimers about not being able to guarantee that the user
will see this apply.

Nik

[Jukka K. Korpela]

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 <strongmarkup for the words, optionally with a class attribute if you
use <strongfor other emphasis as well, and something like

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

The reason for font-weight: normal is that <strongare typically displayed
in bold by default and I assume you don't want that. It is essential to set
color whenever you set background. The usefulness for padding becomes
obvious if you try setting the background color without setting padding.

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

[Dag Sunde]

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 <strongmarkup for the words, optionally with a class attribute
if you use <strongfor other emphasis as well, and something like

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

The reason for font-weight: normal is that <strongare typically
displayed in bold by default and I assume you don't want that. It is
essential to set color whenever you set background. The usefulness
for padding becomes obvious if you try setting the background color
without setting padding.

I think you owe your audience an explanation for declaring nearly
identical solutions for "essentially wrong".

I (think I) understand that you are on a semantical crusade, but
it is not easy to guess.

It is especially important to explain if you want to achieve something
with your statements...

:-)

--
Dag.

[Jukka K. Korpela]

Scripsit Dag Sunde:

I think you owe your audience an explanation for declaring nearly
identical solutions for "essentially wrong".

No, I don't. But you owe me an explanation for quoting my message in
extenso. Actually, since no fair use justified the pointless fullquote, I
could sue you for copyright infringement.

It is especially important to explain if you want to achieve something
with your statements...

As I wrote, the question was fairly elementary, and the other answers had
elementary mistakes in them. You have the option of comparing them with my
answer and checking the FAQs for explanations, or you can just use the wrong
answers if you like. It'll actually help you more than spoon-feeding would.

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

[Andy Dingley]

Dag Sunde wrote:

I think you owe your audience an explanation for declaring nearly
identical solutions for "essentially wrong".

No he doesn't! Jukka is infallible! Jukka is not to be questioned!
Burn the heretics who disagree with The Word Of Jukka!
Burn the unbelievers who even question The Word Of Jukka!
I can only assume that his "esentially wrong" comment refers to the
fact that all answers described the trivia of marking up the resultant
HTML, but didn't describe the coding needed to embed this within the
string extracted from the database. If this was a programming
newsgroup, then he'd have a point.

As to his dogmatic assertion that <strongshould 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.

[Dag Sunde]

Andy Dingley wrote:

Dag Sunde wrote:

>I think you owe your audience an explanation for declaring nearly
identical solutions for "essentially wrong".

No he doesn't! Jukka is infallible! Jukka is not to be questioned!
Burn the heretics who disagree with The Word Of Jukka!
Burn the unbelievers who even question The Word Of Jukka!

I got that impression, yes...

A real net-nanny... Especially when I didn't mean to be sarcastic at all.
I partly agree with him that a <strongor <emis semantically more
correct than <spanin the case of OP's question.
I just wanted him to put forth the rationale behind his thoughts, so
the OP and potentially others could learn/understand.

<snipped />

As to his dogmatic assertion that <strongshould 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

--
Dag.

[Jukka K. Korpela]

Scripsit Dag Sunde:

A real net-nanny...

Do you mean you really need a net-nanny to spoon-feed you? Well, I'll just
give you a hint. What do the FAQs say about specifying color whenever you
specify background, and vice versa? (Actually, I explicitly mentioned the
point, but you might have been busy with other affairs, like getting
upset.) - Admittedly, the setting the padding is a more advanced issue, but
as I wrote, it becomes evident if you actually try it.

I partly agree with him that a <strongor <emis semantically
more correct than <spanin the case of OP's question.

So you partly think that semantically correct markup is better than
semantically empty markup? That's partly fine.

I just wanted him to put forth the rationale behind his thoughts, so
the OP and potentially others could learn/understand.

I just wanted to help you and potentially others to learn CSS yourself. I
know that using (a variant of) the Socratic method isn't very successful; it
didn't work too well even for Socrates himself.

>As to his dogmatic assertion that <strongshould 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? Vow, that fast! I mean a fast change of opinion.

Hint: Do you the FAQs say something about considering situations where CSS
is "off"? Does the phrase "CSS caveats" ring a bell? No? Then google for it!

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

[John Dunlop]

Dag Sunde:

I think you owe your audience an explanation for declaring nearly
identical solutions for "essentially wrong".

None of the three examples are anywhere near identical to
Jukka K. Korpela's, but funnily enough they are almost identical
to each other.* As such, they are all open to two criticisms:
they all specify a background colour without specifying a
foreground colour, and they all use SPAN where emphasis was
wanted. The first two could also be criticised for their class
names.
* Please forgive me if I took your structurally ambiguous
sentence the wrong way. You did mean to say that the three
examples were nearly identical to Jukka K. Korpela's, didn't you?

--
Jock

[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.

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 <strongshould 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 <spanis "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.

[Michael Fesser]

..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

[Jukka K. Korpela]

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 <spanis "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/

[Jukka K. Korpela]

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/

[Michael Fesser]

..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

[Jón Fairbairn]

"Jukka K. Korpela" <jk******@cs.tut.fiwrites:

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

* { background: black; color: white; }

That reminds me. Would it not be useful to have a (ciwas?)
user stylesheet that set everything to the most unexpected
values so that it would quickly draw attention to the sins
of omission?
--
Jón Fairbairn Jo***********@cl.cam.ac.uk

[Jukka K. Korpela]

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/

[Harlan Messinger]

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 <strongmarkup for the words, optionally with a class attribute if
you use <strongfor 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 <strongversus <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.

[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. A warning is not an error.
And some people even consider that warning a bug.

Micha

[Jukka K. Korpela]

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/

[Michael Fesser]

..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

[Andy Dingley]

Jukka K. Korpela wrote:

You refuted the principle of using logical markup instead of semantically
empty <span>,

If <span class="foo" is semantically meaningless, then you implicitly
limit the only expressible semantics of a HTML document to those
expressed in the DTD itself.

Why are semantics important in HTML? They're not important to
browsers, they're not important to CSS, so if semantics are to assume
any importance, they can only do this through being targetted at some
hypothetical semantically-aware consumer. There is no reason why such a
device is limited to the DTD and can't make sensible use of class.

[Andy Dingley]

Dag Sunde wrote:

A real net-nanny...

No, not really. Jukka is also the most knowledgeable HTML / SGML
expert you're ever likely to want to meet. Sometimes though he manages
to combine extreme pedantry with extreme unhelpfulness (I practice
both, but I try to limit it to one at a time). The fact that he's right
(almost always) is no excuse for pretending that there's no possibility
of an alternative view that isn't entirely wrong, or for simply being a
jerk.

We should pity him. It's months since he saw daylight and they've
probably already got to the cannibalistic stage.

[Jukka K. Korpela]

Scripsit Andy Dingley:

If <span class="foo" is semantically meaningless, then you
implicitly limit the only expressible semantics of a HTML document to
those expressed in the DTD itself.

I'm disappointed. I thought, from a long experience about your Usenet
postings, that you understood WWW issues fairly well. Now you express
considerable ignorance about some essential aspects and, moreover, express
it using technobabble. In reality, a DTD has absolutely nothing to do with
semantics; it is pure syntax by definition.

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

[Andy Dingley]

Jukka K. Korpela wrote:

Scripsit Andy Dingley:

If <span class="foo" is semantically meaningless, then you
implicitly limit the only expressible semantics of a HTML document to
those expressed in the DTD itself.

In reality, a DTD has absolutely nothing to do with
semantics; it is pure syntax by definition.

Of course the DTD by and of itself is pure syntax, but what else are
you suggesting to communicate the shared semantics?

For one thing, your original comment was that <strongwas somehow
meaningful when <spanwasn't. This only holds if you accept that the
DTD (in combination with the HTML recommendation) conveys semantic
meaning.
Semantics aren't a publishing problem, they're a communication problem.
Publish what you want, how you want, but if no-one else can understand
it, then there's little point in doing it.

So how _do_ we communicate the semantic schema from producer to
consumer? One perfectly acceptable (and almost commonplace) way is to
use an attribute like class with values from a shared vocabulary.
Dublin Core's element list being an obvious simple example.

It's also possible to express this schema by publishing it as a binding
to structures apart from class, such as the set of elements expressed
in the DTD. They're only syntactic _in_ the DTD, they're a little more
than this if you include the HTML recommendation too (as you yourself
did in advocating <strong>), but they can be as sophisticated as you
wish if you merely use the DTD as a list of elements upon which to
attach some further meaning.

Your point was that <spanwas meaningless, which seems to imply that
the use of class is somehow unworkable (it isn't, plenty of people have
been doing it successfully for years). If this were the case though,
what else is available to use? The only option I know of for HTML is by
implied attachment through the DTD and with some assumed context, such
as the HTML rec. This isn't large though - the DTD isn't expressive
enough to allow a precise semantics to be defined through it, no matter
how you attach or extend it. A list of a few dozen elements can't
usefully express many more than that number of slots.

[Jukka K. Korpela]

Scripsit Andy Dingley:

Of course the DTD by and of itself is pure syntax,

Please stop babbling. It's pure syntax, period.

For one thing, your original comment was that <strongwas somehow
meaningful when <spanwasn't. This only holds if you accept that the
DTD (in combination with the HTML recommendation) conveys semantic
meaning.

Nonsense. Stop making DTDs something mystic. They are just a fairly trivial
though contrived formalism for defining some aspects of syntax rules. At
present, DTDs have actually no impact on how browsers behave. (The document
type declarations have an impact, but _not_ due to browsers actually using
or even opening a DTD.)

So they have _nothing_ to do with the semantic questions. The _meanings_ of
elements have been defined in the prose of the HTML 4.01 specification.

Semantics aren't a publishing problem, they're a communication
problem. Publish what you want, how you want, but if no-one else can
understand it, then there's little point in doing it.

You seem to have completely missed the fact that browsers have, in fact,
recognized <strongas something that should be rendered in some highlighted
manner, even in the absence of CSS (and even before CSS was available). I
mentioned this as a particularly good practical reason to use semantic
markup and not a dummy element - used just as a container to which
attributes can be attached - when there is a choice.

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

[Andy Dingley]

Jukka K. Korpela wrote:

Scripsit Andy Dingley:

Of course the DTD by and of itself is pure syntax,

Please stop babbling. It's pure syntax, period.

Then in that case, <strongis no better than <span class="foo" >

You seem to have completely missed the fact that browsers have, in fact,
recognized <strongas something that should be rendered in some highlighted
manner, even in the absence of CSS (and even before CSS was available). I
mentioned this as a particularly good practical reason to use semantic
markup and not a dummy element

So you see the best hope for the growth of a "Semantic Web" as being
the pure-presentation aspects of a 10-year old default rendering on a
tiny handful of elements. That's hardly pushing the envelope, is it?

[John Dunlop]

Andy Dingley:

Then in that case, <strongis no better than <span class="foo" >

DTDs can't formally express element meaning. Rather, elements are
characterised, as it were, informally through comments in the DTD or
formally through a specification. Either way, the meaning is expressed
in natural, human language. This is why some matters of conformance
need a human to check. For example, 'Does this generic identifier
accurately connote this element type?' (/Handbook/, p.216).

According to the HTML4.01 specification, STRONG is emphasis
stronger than EM, and SPAN is a grouping element with no associated
"presentational idiom". In other words, while visual user-agents
generally render STRONG in bold text, it's reasonable to assume that
user-agents applying only their own stylesheets don't render SPAN
distinctly.

You _could_ mark up emphasised text with SPAN, just as you could
mark up a heading with <SPAN style="font-size: 150%">, but you
wouldn't, since HTML already has two element types for emphasis. The
community knows this, not only because the HTML specification series
has fostered a sense of awareness about what elements mean, but also
because user-agents actually render STRONG distinctly even without
author- or user-stylesheets.

SPAN where emphasis was wanted may not be an error of the same
order as invalid markup, or even of the same order as using EM for
citations, for example, but if an element exists with the specific
semantics you're after, why would you choose the more generic?

--
Jock

[Andy Dingley]

John Dunlop wrote:

You _could_ mark up emphasised text with SPAN,

Jukka said that to do that would be "essentially wrong". It isn't.
Maybe it's not a best practice, but it's far from being so emphatically
wrong.

[Sherm Pendley]

"John Dunlop" <us*********@john.dunlop.namewrites:

According to the HTML4.01 specification, STRONG is emphasis
stronger than EM, and SPAN is a grouping element with no associated
"presentational idiom". In other words, while visual user-agents
generally render STRONG in bold text, it's reasonable to assume that
user-agents applying only their own stylesheets don't render SPAN
distinctly.

FWIW, as someone who's "wrong" answer started this debate, I should add
that this is precisely why I chose span instead of em or strong. For a
stylesheet-aware browser, you can suggest distinctive presentations for
both span-highlighted keywords and ordinary em or strong elements, so
that it's clear to the user which is which

Without stylesheets, the use of em or strong would make no distinction
between emphasised text in the original document vs. text that's empha-
sised by virtue of being a found keyword. That would be a potential source
of confusion for the end user.

So, I figured it would be better to highlight the keywords in a way that
would be less likely to cause confusion for users of non-stylesheet user
agents.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[Manuel Collado]

Sherm Pendley escribió:

"John Dunlop" <us*********@john.dunlop.namewrites:

> According to the HTML4.01 specification, STRONG is emphasis
stronger than EM, and SPAN is a grouping element with no associated
"presentational idiom". In other words, while visual user-agents
generally render STRONG in bold text, it's reasonable to assume that
user-agents applying only their own stylesheets don't render SPAN
distinctly.

FWIW, as someone who's "wrong" answer started this debate, I should add
that this is precisely why I chose span instead of em or strong. For a
stylesheet-aware browser, you can suggest distinctive presentations for
both span-highlighted keywords and ordinary em or strong elements, so
that it's clear to the user which is which

Without stylesheets, the use of em or strong would make no distinction
between emphasised text in the original document vs. text that's empha-
sised by virtue of being a found keyword. That would be a potential source
of confusion for the end user.

So, I figured it would be better to highlight the keywords in a way that
would be less likely to cause confusion for users of non-stylesheet user
agents.

Perhaps it could be <strong class="keyword"instead of <span
class="keyword">. At least this makes explicit the intention of being
emphasized.

Regards.
--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

[Sherm Pendley]

Manuel Collado <m.*******@fi.upm.eswrites:

Sherm Pendley escribió:

>>
Without stylesheets, the use of em or strong would make no distinction
between emphasised text in the original document vs. text that's empha-
sised by virtue of being a found keyword. That would be a potential source
of confusion for the end user.

So, I figured it would be better to highlight the keywords in a way that
would be less likely to cause confusion for users of non-stylesheet user
agents.

Perhaps it could be <strong class="keyword"instead of <span
class="keyword">. At least this makes explicit the intention of being
emphasized.

Like I said - without the stylesheet, there would be no visual difference
between <strong class="keyword"and <strong>. It's not explicit at all;
the user is left with no easy way to know what's an emphasized keyword and
what's emphasized in the document itself.

IMHO, <span class="keyword"has a more graceful fallback. In the absence of
stylesheet support, I think it would be preferable to omit the highlighting
entirely, rather than highlight keywords in a way that may cause the end user
some confusion.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

[VK]

Jukka K. Korpela wrote:

You seem to have completely missed the fact that browsers have, in fact,
recognized <strongas something that should be rendered in some highlighted
manner, even in the absence of CSS (and even before CSS was available). I
mentioned this as a particularly good practical reason to use semantic
markup and not a dummy element

Andy Dingley wrote:

So you see the best hope for the growth of a "Semantic Web" as being
the pure-presentation aspects of a 10-year old default rendering on a
tiny handful of elements. That's hardly pushing the envelope, is it?

Every time Mr.Korpela explains his vision of semantic in (X)HTML, the
first thing I'm thinking about is the Newspeak from Orwell's "Nineteen
Eighty-Four" :-)

Who did not read this excellent book, check
<http://en.wikipedia.org/wiki/Newspeak- some analogies are amazing
:-)

For really semantically-preoccupied ones it could be also:

<!DOCTYPE html PUBLIC "-//VK//DTD XHTML X.X//EN"
"http://jsnet.sourceforge.net/tmp/vk.dtd">
<html>
<head>
<meta http-equiv="content-type"
content="text/html; charset=iso-8859-1" />
<title>Foobar</title>
<style type="text/css">
p keyword {
background-color: yellow;
}
</style>
</head>
<body>
<h1>In search of &quot;ipsum&quot;</h1>
<p>Lorem <keyword>ipsum</keyworddolor sit amet...</p>
</body>
</html>

[Jukka K. Korpela]

Scripsit Sherm Pendley:

IMHO, <span class="keyword"has a more graceful fallback. In the
absence of stylesheet support, I think it would be preferable to omit
the highlighting entirely, rather than highlight keywords in a way
that may cause the end user some confusion.

That's illogical. If the keywords are worth highlighting, why would it be
better fallback to have them rendered in the same manner as some other
words, emphasized for other reasons, than to have them not highlighted at
all?

Users are anyway faced with the fact that italics and bolding have different
meanings on different pages and even within a page. They simply make things
"stand out", expressing emphasis of different kinds, and not always emphasis
at all.

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

[Sherm Pendley]

"Jukka K. Korpela" <jk******@cs.tut.fiwrites:

Scripsit Sherm Pendley:

>IMHO, <span class="keyword"has a more graceful fallback. In the
absence of stylesheet support, I think it would be preferable to omit
the highlighting entirely, rather than highlight keywords in a way
that may cause the end user some confusion.

That's illogical.

No, it's a subjective opinion, hence the phrase "I think". Logic has
nothing to do with it, it's a matter of personal preference.

My opinion is that a search engine highlighting found keywords is act-
ing as part of the presentational layer. The highlighting is part of
the display, not part of the document itself. Thus, I feel it should
not be done unless it can be done in a way that distinguishes that
difference.

YMMV, of course.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net