How is multi-color text/font done in CSS?

On Thu, 18 Jan 2007, eastcoastguyz wrote:

How can
you change the colors of the text in the same word in CSS? For example,
when how can you take the word "infosystems" and make the "info" part
red, and the "systems" part blue?

Example:
http://www.unics.uni-hannover.de/nht.../rainbow.html6

Jan 18 '07 #3

eastcoastguyz wrote:

For example,
when how can you take the word "infosystems" and make the "info" part
red, and the "systems" part blue?

>systems</span>

</p>

I don't want to have to hard-code
this in HTML which is why I'm looking to CSS to do this.

Hard-code suitably abstract class or id values into the HTML, then
attach the specific styles through CSS.
If your classes are appropriate, it's not aproblem to have hard-coded
them

Jan 18 '07 #4

eastcoastguyz

Andy Dingley wrote:

eastcoastguyz wrote:

For example,
when how can you take the word "infosystems" and make the "info" part
red, and the "systems" part blue?

<style type="text/css" >
.highlight { color: red; }
.lowlight { color: blue; }
</style>

<p>
<span class="highlight" >info</span><span class="lowlight"
systems</span>
</p>

I don't want to have to hard-code
this in HTML which is why I'm looking to CSS to do this.

Hard-code suitably abstract class or id values into the HTML, then
attach the specific styles through CSS.
If your classes are appropriate, it's not aproblem to have hard-coded
them

Thanks to all for replying.

What if you had the same word in this example, "infosystems" and wanted
each letter to be a different color, would this require each letter be
addressed to a different span class? Thanks!

Jan 18 '07 #5

Scripsit eastcoastguyz:

What if you had the same word in this example, "infosystems" and
wanted each letter to be a different color, would this require each
letter be addressed to a different span class? Thanks!

Yes, though in principle you could use some other tags than <span(but
<spanis safest since it means nothing and has no default styling in any
reasonable browser).

The very idea is so weird that it's perhaps just fine that it's cumbersome
to implement in CSS.

Note, by the way, that people who posted you some sample codes forgot to set
the background. You will now probably be inclined into making the same
common mistake. Doing _technically correctly_ the thing you want is actually
even more awkward than the simplistic examples suggest.

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

Jan 18 '07 #6

dorayme

In article
<11**********************@51g2000cwl.googlegroups. com>,
"Andy Dingley" <di*****@codesmiths.comwrote:

eastcoastguyz wrote:

For example,
when how can you take the word "infosystems" and make the "info" part
red, and the "systems" part blue?

<style type="text/css" >
.highlight { color: red; }
.lowlight { color: blue; }
</style>

<p>
<span class="highlight" >info</span><span class="lowlight"
systems</span>
</p>

and put in a background colour too where while at it, eg.

..highlight { color: red; background: #fff;}

Since old K and I teamed up, he leaves me to mention the little
stuff, I am not to be trusted with anything bigger.

--
dorayme

Jan 19 '07 #7

Jukka K. Korpela wrote:

Note, by the way, that people who posted you some sample codes forgot to set
the background.

I didn't forget, I omitted it deliberately as being inappropriate.

There is no reason to set background colour in every CSS block. There's
no reason why every time colour is set, background colour needs to be
set too. The need is to ensure that unviewable combinations don't
arise. This can be achieved by crudely setting in pairs, or by by
carefully studying the overall stylesheet.

Usually it's a good idea to set both. Most uses of CSS blocks are
driven by applying the whole block to an element in a fairly simple
manner, with a "blanket" set of rules to apply. Setting only one
colour here would be likely to cause conflicts with inherited
backgrounds etc.

In this case though, the CSS is a little more obscure. We're applying a
simple "highlight" by actively controlling only one color. The other
color _should_ be left as inherited - we have no interest in changing
it. It's also a problem from maintenance reasons if we did set the pair
of colours. This breaches the good software principle of "Don't Repeat
Yourself" which is just as important as the CSS principle of "Don't set
only one colour next to an unknown inherited background".

It's necessary to know the scope in which this CSS rule is used. It's
necessary to know that the backgrounds possible in this scope can't
generate a conflict with the possible colours. If these conditions are
met by studying the page design, then there's no reason to duplicate a
hard-coded background setting into every block.

Of course this isn't perfect, in the case of some heavyweight user
stylesheet colour and background settings. But nor is the "set
everything twice" behaviour.

Jan 19 '07 #8

On Fri, 19 Jan 2007, Jukka K. Korpela wrote:

Yes, though in principle you could use some other tags than <span(but <span>
is safest since it means nothing and has no default styling in any reasonable
browser).

Even <spanmay break the joining of Arabic letters.

Note, by the way, that people who posted you some sample codes forgot to set
the background. You will now probably be inclined into making the same common
mistake.

Background for what? For span? Not even http://jigsaw.w3.org/css-validator/
with "Warnings: Normal report" reports this as warning, let alone as
"mistake" (= error).

Jan 19 '07 #9

Andreas Prilop wrote:

Even <spanmay break the joining of Arabic letters.

I'd suggest that the idea of alternately colouring arabic letters is so
aberrant that this simply isn't a problem. Even if it's an arabic
calligraphy instruction book and might _possibly_ want to apply some
sort of highlight. For a language like arabic that has stopped being
expressible as a character-based text problem and has become a
graphical issue.

Jan 19 '07 #10

On Fri, 19 Jan 2007, Andy Dingley wrote:

>Even <spanmay break the joining of Arabic letters.

I'd suggest that the idea of alternately colouring arabic letters is so
aberrant that this simply isn't a problem.

It is; see the thread starting with
http://www.unicode.org/mail-arch/uni...-m06/0110.html
login: unicode-ml
password: unicode

Jan 19 '07 #11

Andreas Prilop wrote:

On Fri, 19 Jan 2007, Andy Dingley wrote:

Even <spanmay break the joining of Arabic letters.
I'd suggest that the idea of alternately colouring arabic letters is so
aberrant that this simply isn't a problem.

It is; see the thread starting with
http://www.unicode.org/mail-arch/uni...-m06/0110.html
login: unicode-ml
password: unicode

That's a nice example, but I don't think it changes my point.

Arabic text has a sense of joining between letters that English has
only very rarely. Using a zero-width non joiner is a deliberate way to
indicate a separation between them.

The question is "Should even the minimum of HTML markup be treated in
the same way as &zwnj; ?" As your example demonstrates, it does so for
<span(in my FF anyway). You appear to disagree with this but I'm not
so sure. Is HTML markup really so invisible as to not warrant this?

My example is perhaps irrelevant and a cop-out. I simply think that to
even _try_ to apply this sort of per-character slicing in a language
like Arabic is itself wrong. The correct rendering simply isn't
slicable like this (for ancient calligraphic reasons), unless we turn
the "rendered text" into a "picture of rendered text" and treat it as a
pure image.

Jan 19 '07 #12

On Fri, 19 Jan 2007, Andy Dingley wrote:

The question is "Should even the minimum of HTML markup be treated in
the same way as &zwnj; ?" As your example demonstrates, it does so for
<span(in my FF anyway). You appear to disagree with this but I'm not
so sure.

No, I was just asking whether Mozilla Firefox or Internet Explorer
is right.

I simply think that to
even _try_ to apply this sort of per-character slicing in a language
like Arabic is itself wrong.

If you don't like the idea of coloured letters, think of the
TITLE attribute and other examples shown at
http://www.unics.uni-hannover.de/nht...-text.html#zwj
http://www.unics.uni-hannover.de/nht...uby-annotation

Jan 19 '07 #13

Scripsit Andreas Prilop:

On Fri, 19 Jan 2007, Jukka K. Korpela wrote:

>Yes, though in principle you could use some other tags than <span>
(but <spanis safest since it means nothing and has no default
styling in any reasonable browser).

Even <spanmay break the joining of Arabic letters.

<spanis still _safest_. If it breaks something in this respect, then
that's because of the presence of markup in the first place, and that's
unavoidable (with the given premises).

>Note, by the way, that people who posted you some sample codes
forgot to set the background. You will now probably be inclined into
making the same common mistake.

Background for what? For span?

For any element.

Not even
http://jigsaw.w3.org/css-validator/ with "Warnings: Normal report"
reports this as warning, let alone as "mistake" (= error).

Neither does it complain if you set color and background both to black.

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

Jan 19 '07 #14

Scripsit Andy Dingley:

There's no reason why every time colour is set, background colour
needs to be set too.

There is. It has been explained at length several times in this group.
Novices who don't understand the cascade have a hard time in understanding
the issue, because they think much more simplistically than CSS actually
works. And it seems that you wish to make your contribution to the
propagation of ignorance and bad design.

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

Jan 19 '07 #15

dorayme

In article <WA*****************@reader1.news.saunalahti.fi> ,
"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

Scripsit Andy Dingley:

There's no reason why every time colour is set, background colour
needs to be set too.

There is. It has been explained at length several times in this group.
Novices who don't understand the cascade have a hard time in understanding
the issue, because they think much more simplistically than CSS actually
works. And it seems that you wish to make your contribution to the
propagation of ignorance and bad design.

I love it when you dress AG down because it makes me feel not so
bad when you do it to me, considering he knows miles more than
me. But remember, old chap, now we are a team, (me doing the
simple stuff like telling newbies to set a background colour when
setting a colour and you anything more complicated than that),
you need to go easier on me in future, at least in public.

--
dorayme

Jan 20 '07 #16

dorayme

In article
<do**********************************@news-vip.optusnet.com.au>,
dorayme <do************@optusnet.com.auwrote:

I love it when you dress AG down because it

AD, not AG

--
dorayme

Jan 20 '07 #17

Andreas Prilop wrote:

No, I was just asking whether Mozilla Firefox or Internet Explorer
is right.

Apropos of nothing, I asked our two native arabic-speaking web
developers about this (We develop Java web apps and sell them
internationally, including to Saudi Arabia). They found the question so
bizarre that they could barely understand what I was asking. To someone
who's first language is arabic, the idea of inserting separators or
markup like this just seemed nonsensical.

I think I agree with you though - <spanshouldn't act as a non-joiner
like this. This is not for any issue of meaning, it's just because it's
easy to add a non-joiner if you need one, but hard to "re-join" that
which <spanhas sundered.

Jan 20 '07 #18

Scripsit Andy Dingley:

I think I agree with you though - <spanshouldn't act as a non-joiner
like this.

Unfortunately the specifications seem to be silent on this, so we cannot
expect any consistent browser behavior. But on logical grounds, markup
should not have any surprise effects. The <spanmarkup has no defined
meaning beyond being inline markup, so it should not as such affect
rendering in any way. In practice, though, software designers have taken a
different look, or just did something that has nasty side effects. For
example, the IBM Home Page Reader considerably pauses within a word if there
is markup inside it.

This is not for any issue of meaning, it's just because
it's easy to add a non-joiner if you need one, but hard to "re-join"
that which <spanhas sundered.

Please tell me why adding ZERO WIDTH JOINER would be substantially more
difficult than adding ZERO WIDTH NON-JOINER.

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

Jan 20 '07 #19

Jukka K. Korpela wrote:

Please tell me why adding ZERO WIDTH JOINER would be substantially more
difficult than adding ZERO WIDTH NON-JOINER.

Obviously it's their effect that's at issue here, not the complexity of
editing the markup.

Let us assume that [...] xyz</span><span>abc [...] is to be
rendered as non-joined
(This is a reasonable and rational choice, even if we seem to agree
it's not the best interpretation of the spec)

In that case, I don't see that [...] xyz</span>&zwj;<span>abc [...]
should be rendered as joined.
Should [...] xyz</div>&zwj;<div>abc [...] be rendered as joined too?
How?!

The idea of "joining" is problematic and only vaguely defined in the
relative HTML & CSS specs. It also varies between languages so it's
hard to provide any consistent overall interpretation. In English (the
only language for which I can make any real comment) it's used to
indicate ligatures. From the origin of ligatures in typography rather
than linguistics, and from their usage in any period, it's
inappropriate to "re-join" a ligature that has already been sundered.
If your rendering algorithm is such that <spansplit them apart, then
there's no justification for an added joiner putting them back together
again.

The only consistent interpretation would seem to be that [...]
xyz</span><span>abc [...] is rendered as joined, exactly as [...]
xyz</span>&zwj;<span>abc [...] and in contrast to the un-joined
[...] xyz</span>&zwnj;<span>abc [...]

Jan 22 '07 #20

Scripsit Andy Dingley:

>Please tell me why adding ZERO WIDTH JOINER would be substantially
more difficult than adding ZERO WIDTH NON-JOINER.

Obviously it's their effect that's at issue here, not the complexity
of editing the markup.

You don't even need markup in order to use those characters (if you use
UTF-8).

Let us assume that [...] xyz</span><span>abc [...] is to be
rendered as non-joined
(This is a reasonable and rational choice, even if we seem to agree
it's not the best interpretation of the spec)

Indeed we disagree. I'm happy to see that IE agrees with me: it displays
<span>ب</span><span>ا</span>
the same way as without the <spanmarkup, i.e. with the two Arabic
characters written in a cursive manner (joined). And if I insert ZERO WIDTH
NON-JOINER (as a character or as a reference &zwnj;) I get the expected
result of displaying them as separated characters.

In that case, I don't see that [...] xyz</span>&zwj;<span>abc [...]
should be rendered as joined.

I can't argue with you on that, since I don't see your reasons for thinking
that markup as such should break the text flow, even when the markup is
semantically empty.

Should [...] xyz</div>&zwj;<div>abc [...] be rendered as joined too?

Of course not, because <divimplies line breaks and cursive joining does
not take place at line boundary in general.

The idea of "joining" is problematic and only vaguely defined in the
relative HTML & CSS specs.

It need not be defined there. It's a character level issue, and a quality of
implementation issue, and there's no apparent reason for making HTML or CSS
involved.

In English (the
only language for which I can make any real comment) it's used to
indicate ligatures.

The ZERO WIDTH JOINER and ZERO WIDTH NON-JOINER, though suitable in
principle for use like f&zwj;i (asking a rendering engine to present the f
and i as a ligature), is practically useless for that due to lack of support
in browsers. Their use with e.g. the Arabic script is a different issue.

In practical web authoring, if you want "fi" to appear as a ligature, use
the LATIN SMALL LIGATURE FI character (written e.g. as &#fb01;) and stay
tuned to seeing some problems due to lack of the character in some fonts.

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

Jan 22 '07 #21

Jukka K. Korpela wrote:

Scripsit Andy Dingley:

I can't argue with you on that, since I don't see your reasons for thinking
that markup as such should break the text flow,

I don't think it should, I'm merely discussing the implications of a
hypothetical case when it's intepreted to do so (as some browsers
appear to interpret it). Although one can construct a logically
consistent system around this behaviour, it's not one that has a
consistent interpretation when &zwj; is used as well.

Should [...] xyz</div>&zwj;<div>abc [...] be rendered as joined too?

Of course not, because <divimplies line breaks

That's my point. It's impossible to have a generalised system where
"It's OK to break joining at markup because we can re-join it by use of
&zwj;" With that constraint, it may be decided that the best
interpretation of rendering behaviour would be to decide to not break
joining at markup (including <span>) unless it was also a case
(whitespace, linebreak) where joining should obviously be broken
anyway.

It need not be defined there. It's a character level issue, and a quality of
implementation issue, and there's no apparent reason for making HTML or CSS
involved.

The issue of whether <spanbreaks joining must obviously involve at
least two of these three though, even if the joining of simple
character streams is simply a character level issue.

Jan 23 '07 #22

Scripsit Andy Dingley:

Jukka K. Korpela wrote:
>Scripsit Andy Dingley:

>I can't argue with you on that, since I don't see your reasons for
thinking that markup as such should break the text flow,

I don't think it should, I'm merely discussing the implications of a
hypothetical case when it's intepreted to do so (as some browsers
appear to interpret it).

I think it's a bug rather than an interpretation.

It is true that relevant standards and specifications are rather silent
about the matter, but I agree with Peter Constable's view in the Unicode
list discussion that Andreas referred to. Peter wrote:
"*My* opinion, supported by the silence of the Unicode Standard on the
topic, is that it is up to the higher-level protocol -- the HTML spec --
to specify what the impact of various markup elements may have on
various text processes over the character content of a document. For
instance, I would expect the sequences in <TD>abc</TD><TD>def</TDto be
treated as distinct document elements, implying no cursive connection
between them (among other things), but I would expect the sequences
<span>abc</span><span>def</spanto be considered a single text element
for rendering purposes (barring further stylesheet effects -- a
stylesheet might, of course, transform spans into distinct non-inline
structural elements)."

There are two issues mixed here: the logical meaning of markup, which may
indicate pieces of text as clearly separate (like cells of a table), and the
physical rendering, which may well make any question of joining irrelevant
(e.g., any spacing between characters inevitably prevents joining, not to
mention borders). For unstyled <span>, neither aspect suggests any
interference with joining behavior.

Even <strong>abc</strong>def might be seen as preventing cursive joining of
c and d both on logical grounds (you cannot emphasize one part of a ligature
or cursively joined combination without emphasizing the other - but
diacritic marks might be a different issue) and presentational grounds
(<strongmight be rendered in bold face, for example, and you cannot expect
to apply cursive joining to glyphs from different variants of a font).

Although one can construct a logically
consistent system around this behaviour, it's not one that has a
consistent interpretation when &zwj; is used as well.

I don't follow your logic. _If_ markup as such is supposed to break joining,
as Firefox still seems to think, then it would be _logical_ that &zwj;
cancels that effect.

>>Should [...] xyz</div>&zwj;<div>abc [...] be rendered as joined
too?

Of course not, because <divimplies line breaks

That's my point. It's impossible to have a generalised system where
"It's OK to break joining at markup because we can re-join it by use
of &zwj;"

That's a strawman argument. Nobody wrote the quoted sentence or anything
equivalent to it. You wrote that it is "hard to 're-join' that which <span>
has sundered", and I merely asked what's hard about it. _If_ the Mozilla
family of browsers simply applied the "interpretation" that markup as such
breaks joining, it could (and should) easily undo the effect in the presence
of ZWJ. Of course ZWJ would not join across line boundaries for example,
just as it does not join in plain text when you end or start a line with
ZWJ.

So the answer to my (somewhat rhetoric) question is that the hardness is
probably in Mozilla's code and its developers' minds. And although you wrote
a strawman argument, the view that you are trying to refute _is_ a
meaningful one and defendable: _if_ a browser consistently behaved so that
it breaks joining at markup, it _could_ (and should) allow this behavior to
be overridden using ZWJ. After all, that's the very idea of ZWJ: join
something that wouldn't otherwise be joined but could be joined.

>It need not be defined there. It's a character level issue, and a
quality of implementation issue, and there's no apparent reason for
making HTML or CSS involved.

The issue of whether <spanbreaks joining must obviously involve at
least two of these three though, even if the joining of simple
character streams is simply a character level issue.

The _idea_ of joining is what "it" originally referred to. The idea is
surely a character-level (or character rendering level) concept, so the
description of a markup or styling notation should not even try to define
the idea. What it might do is to _postulate_ the idea, implicitly or with an
explicit reference to a standard or specification or description, and then
say something that involves the idea.

But returning to the topic of c.i.w.a.s., it might be useful to have a
property that affects cursive joining. Even though joining can be prevented
or suggested at character level, using ZWNJ and ZWJ, such an approach
becomes awkward if you just want to say, for example, "please use ligatures
wherever you can" (or "don't use any ligatures").

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

Jan 23 '07 #23

Jukka K. Korpela wrote:

I don't think it should, I'm merely discussing the implications of a
hypothetical case when it's intepreted to do so (as some browsers
appear to interpret it).

I think it's a bug rather than an interpretation.

Albeit probably a bug of incorrect interpretation, not sloppy coding.

Even <strong>abc</strong>def might be seen as preventing cursive joining of
c and d both on logical grounds (you cannot emphasize one part of a ligature
or cursively joined combination without emphasizing the other - but
diacritic marks might be a different issue)

Is even this true? The beginning of this thread was about a branding
exercise around a trademark, then a digression into the display of
calligraphy textbooks. Both of these seem like cases to permit this
bizarre partial highlighting. It's not HTML's or Unicode's place to
define rules for such things.

Although one can construct a logically
consistent system around this behaviour, it's not one that has a
consistent interpretation when &zwj; is used as well.

I don't follow your logic. _If_ markup as such is supposed to break joining,
as Firefox still seems to think, then it would be _logical_ that &zwj;
cancels that effect.

That's a strawman argument.

It's not a strawman, it's a reductio ad absurdum. My intention is to
show that there is no consistent interpretation of the hypothetical
"<spanshould break" interpretation, thus this is not a good
interpretation to use. Of course that can't immediately be
extrapolated to mean that it wasn't what the W3C meant!

The two forms of argument are very similar, differing merely in whether
anyone might actually stand behnd the hypothetical case (Andreas cites
browsers that do). It would only be a strawman if I claimed falsely
that some particular browser did it.

although you wrote
a strawman argument, the view that you are trying to refute _is_ a
meaningful one and defendable:

Then it's not a strawman, it's a hypothesis.

Jan 23 '07 #24

On Sat, 20 Jan 2007, Jukka K. Korpela wrote:

>Not even
http://jigsaw.w3.org/css-validator/ with "Warnings: Normal report"
reports this as warning, let alone as "mistake" (= error).

Neither does it complain if you set color and background both to black.

Oh yes, it does! It says:

Same colors for background-color and color

Jan 24 '07 #25

On Mon, 22 Jan 2007, Andy Dingley wrote:

Should [...] xyz</div>&zwj;<div>abc [...] be rendered as joined too?

Your are confused! It is

xyz&zwj;</div><div>&zwj;abc

Look again at the source text of
http://www.unics.uni-hannover.de/nht.../rainbow.html6

Jan 24 '07 #26

On Sat, 20 Jan 2007, Andy Dingley wrote:

Apropos of nothing, I asked our two native arabic-speaking web
developers about this (We develop Java web apps and sell them
internationally, including to Saudi Arabia). They found the question so
bizarre that they could barely understand what I was asking. To someone
who's first language is arabic, the idea of inserting separators or
markup like this just seemed nonsensical.

Some people just don't realize what is possible with computers!
First digitized dinosaurs in movies - now even coloured Arabic text ;-)

I have an old Latin grammar, which is printed throughout in black,
red, and green - really nice! For example, the word "audiatur" is
printed with "aud" in black, "i" in red, "atur" in green.
Each colour has its grammatical significance. That would be fine
for students' grammars and textbooks in the Arabic language, too.

Jan 24 '07 #27

On Tue, 23 Jan 2007, Jukka K. Korpela wrote:

>>>Should [...] xyz</div>&zwj;<div>abc [...] be rendered as joined
too?

So the answer to my (somewhat rhetoric) question is that the hardness is
probably in Mozilla's code and its developers' minds.

The "hardness" seems to see the difference between

</span>&zwj;<span>

and

&zwj;</span><span>&zwj;

The first is quite pointless.

Jan 24 '07 #28