[whatwg] [html5] Rendering of interactive content

On Wed, Feb 11, 2009 at 10:13 AM, Smylers <Smylers at stripey.com> wrote:
> Ah, I see.  Thanks for explaining that.  I'm interpreting it as "for
> each bit of text that you cause the background colour to be set for,
> also specify its foreground colour (and _vice versa_)".

But that's not *possible* in CSS.  Not within reason, anyway.  You
can't be expected to set color for all descendants.

> True, but that introduces other awkwardnesses.  Given that many pages
> (or regions of pages) have a background colour shared across several
> elements, it's tedious to have to specify it for each one -- and also
> harder to change.

It's the only way to be *sure* that things won't break (at least, you
can be sure as long as everyone does it).

> On that basis transparent backgrounds are useless, since you can never
> be sure that somebody else won't change the background colour of the
> parent element without ensuring none of its content's text colours
> clash.

Transparent backgrounds (i.e., no background) can still be set safely
if you don't specify the text color.  You only need to set the
background when you set the text color.

In practice, of course, this still isn't necessarily feasible.  E.g.,
there may be a complicated background-image on body, which you can't
respecify on descendants because it wouldn't line up properly.  Then
if you want to change the color of elements, you have to do it with a
nonexistent (transparent) background.  This means you'll have to
accept the risk of things breaking if the user specifies a different
style.

> Your interpretation and my interpretation both 'work'.  However, mine's
> less hassle to deal with (avoids proliferation of repetitive properties)
> and compatible with the extant web.

Well, what you call "my" interpretation is also the interpretation of
whoever wrote the W3C CSS validator, AFAICT.  It's *not* safe to set
foreground color without background or vice versa, at least if you
assume that your CSS might interact with arbitrary CSS from other
sources.  It may sometimes (even often) be worth the risk, however.

I would say that what you're suggesting is an entirely different
principle: stylesheet authors should manually set :link, :visited, and
:hover foreground colors if they set any background color on any
element that might contain a link, because they can't guarantee UA
behavior otherwise.  This is a much more specific point -- it doesn't
cover interaction with author or user stylesheets and requires at most
three rules per set of stylesheets.

> Fair point.  But browsers have for a long time provided UI for users to
> specify other link colours in way that they haven't, for exmaple, the
> colour of headings or emphasized text.  I'm sure some users take
> advantage of such UI (and wouldn't consider them to be user
> style-sheets; somebody clicking on such UI possibly isn't even aware of
> the concept of user style-sheets).

Good point.  I just checked and Firefox does in fact have such an
option.  So I'll agree that authors should always specify link colors
to override the UA's stylesheet, if they specify backgrounds.  My
objection to what Ian said was incorrect.

Received on Wednesday, 11 February 2009 07:41:12 UTC