[whatwg] [html5] Rendering of interactive content

[Aryeh Gregor]

On Wed, Feb 11, 2009 at 8:36 AM, Smylers <Smylers at stripey.com> wrote:
> That is precisely an instance of an author setting a background colour
> without a foreground colour -- specifically the author set the
> background colour used on links without setting the foreground colour
> for links.
>. . .
> Browsers do of course (typically) set both together -- in that they
> provide a default background colour, plus foreground colours for visited
> links, unvisitied links, and non-link text.

I interpret "authors should always set background and foreground
colors together" as "no single CSS rule should set 'background'
without setting 'color' or vice versa".  I can't figure out exactly
how you're interpreting it.

The point is that to ensure that the foreground and background don't
conflict, you must always set foreground and background colors *in the
same CSS rule*.  As long as all stylesheets observe this principle,
there will never be a mismatch.  Either the color and background are
overridden both at once, or not at all, since the cascade works on a
rule-by-rule basis, not property-by-property.

The browser is the one that's failing to observe the principle in this
case, and the author is observing it.  The author is *not* setting the
background color for :link, nor the foreground color.  The author is
only setting the colors for body.  On the other hand, the UA is
setting the foreground color for :link, but is *not* setting a
background color for :link -- only for body.  If you put the rule
":link { color: blue; }" into the W3C CSS validator, it will warn you
that you're setting color without setting background, regardless of
whether there's any inherited color you've set.

> If an author overrides one
> of those four then he generally needs to override all of them (except in
> circumstances where he knows the area in question won't have any links,
> or any-non links, or any text).

So you're saying links are a special case for this principle?  Why?
UAs might just as reasonably change the colors of other elements as
well.  It's only convention that says they only change the color of
links.  But that exact same convention says that the color of links is
blue.

> It's significantly stranger, for a couple of reasons:
>
> * Links are a distinct type of element with a specific purpose.
>  <span>-s convey no semantics of their own, and are used for multiple
>  purposes.

So instead, suppose it were something like:

strong { color: red; }

In fact, though, green spans would not be significantly less common in
UA default stylesheets than green links -- as far as I know, neither
has ever occurred, certainly not in a notable browser.  That's what I
meant by saying it would be "not much stranger".  Conceptually it's
stranger, but practically it's not.

> * Links are conventionally a different colour from other text; <span>-s
>  aren't.  Prefering links to be green rather than blue is a minor
>  change, possibly one of aesthetics or to assist somebody who has
>  trouble distinguishing certain colours.  Whereas prefering <span>-s to
>  be green rather than indistinguishable from the surrounding text is
>  adding in a distinction not normally seen.

Yes, links are conventionally a different color from other text.  More
particularly, they're conventionally *blue*.  Every color browser I
have ever heard of back to the dawn of the Web uses blue for links.
NCSA Mosaic 0.6 beta already used blue for links:

http://gladiator.ncsa.uiuc.edu/Images/press-images/mosaic.6beta.tif

I have never heard of any exception.  If you're saying that authors
should expect browsers to behave conventionally in not changing the
colors of non-links, I can't see how you would say that authors
shouldn't expect them to behave conventionally in making links blue.
Either the UAs are adopting the universal standards that everyone
everywhere has always used, or they're doing heaven knows what.

> Yes.  Users can choose to implement custom styles which mess things up.
> Users are free to do that if they want.

We aren't talking about user stylesheets here, we're talking about
browser default stylesheets.  HTML5 does not mention user stylesheets,
as far as I'm aware.

> We don't want a way "round" it.

We always want a way around the possibility of sites breaking due to
different assumptions between UA and author.  That's what standards
are *for*.  In this case, however, it's not feasible to mandate a
single default rendering for all UAs.  Clearly text-based browsers,
monochrome browsers, screen readers, etc. need to use different rules.
 Therefore sites will sometimes break in browsers they weren't
designed for, and this is unfortunate, but it's not something HTML5
can prevent.