Re: Re[2]: W3C 'CSS3 module: Color' Working Draft dated 19th February 2002

On 3/26/02 7:53 AM, "Chris Lilley" <chris@w3.org> wrote:

> On Tuesday, March 26, 2002, 8:00:39 AM, fantasai wrote:
> 
> f> Tantek Çelik wrote:
>>> 
>>> text-decoration-opacity
> 
> f> I think text-decoration can be fairly grouped with text, especially since
> it
> f> doesn't have a separate color property, either.

You should check the CSS3 Text module before saying that.

> (And if there were separate
> f> opacity properties, border and outline opacity could have an initial value
> of
> f>  <foreground-opacity>, just as border-color has an initial value of
> <color>).
> 
> Provided it is made clear whether
> 
> a) text is drawn on top of underlines
> 
> b) text is drawn below underlines
> 
> c) text and underlines are combined into a single geometry and
> rendered as one (unlikely but possible)
> 
> Same for strikethrough.

Yes, this should be clarified either way.

Strikethroughs are typically drawn over the relevant text.

Underlines and overlines _could_ be drawn over the relevant text, but at
least underlines are much more commonly drawn under the text (avoid chopping
off descenders etc.), and I would presume that overlines would be drawn that
way as well for the same reason (ascenders).

CSS1 and CSS2 do not express any layering requirements for text-decoration.

Any text decoration experts want to express an opinion? (Michel?)

Perhaps this should be clarified in the CSS3 Text Module?


>>> It is much simpler to introduce 2 new color value types which can then be
>>> used with all properties that specify a color, rather than add 5-9 new
>>> properties.
> 
> Until one considers animation,

As far as animation is concerned, there are already several other compound
values in CSS (like text-decoration, font-family, clip, etc.). If animation
has trouble with compound values then that is a problem with animation and
has nothing to do with Color.

>and DOM manipulation.

DOM manipulation is not a problem.  DOM2Style already allows for
manipulation of the red value in an rgb() value, so manipulation of an alpha
value in an rgba() value logically follows.

>>> In addition, the new color value types permit controlling the opacity of
>>> these pieces of elements independently of elements' children, which the
>>> opacity property does affect.
> 
> Correct.
> 
> f> Which shows the fundamental problem with declaring rgba and hsla the
> f> solution to separating background and foreground opacity.
> 
> f> Suppose I have a <div>. I want the the <div>'s background to be
> translucent,
> f> but it's text should be opaque so it's easily readable. It's a reasonable
> f> request, no?
> 
> f> <div class="sidebar">
> f>   <p>Paragraph text.... <a href="file.html">Link</a>... So <strong>DON"T
> f>      FORGET...</strong> etc.
> f>   </p>
> f> </div>
> 
> f> Your suggestion would be to set the background as a transparent color.
> Thus:
> 
> f>   .sidebar {
> f>       background: rgba(255, 255, 0, .5);
> f>   }
> 
> f> Which works fine, except I also happen to have these rules in effect:
> 
> f>    :link, :visited {
> f>       background: #FFBB00;
> f>       color: #000033;
> f>    }
> 
> f>    strong {
> f>      background: #FF0000;
> f>      color: #000000;
> f>    }
> 
> f> So the background on the link and emphasized notice is opaque. This is not
> f> according to my design,
> 
> It is - you specified an opaque color and that is what you got.

Indeed, and even with a background-opacity property, you would still get the
same effect, since background-opacity would obviously not inherit.

> f> and IMO, it looks bad. So now I have to write separate
> f> rules for any elements in a sidebar, adjusting the background color's
> opacity
> f> accordingly.

You have to do so in either case.

> Yes, you would have to adjust the color as well because the color and
> the opacity are globbed together.  I agree it would be easier to just write
> 
> .sidebar {
>      background: rgb(255, 255, 0);
>      background-opacity: 0.5
> }
> .sidebar * { background-opacity: 0}

This would effectively hide the background color of all child elements which
I don't think is the desired effect either.

If there are such general rules that set solid backgrounds on elements,
which can occur inside an element which has a transparent background, you
will have to write additional rules for when those elements are inside the
element with the transparent background.  This is true for rgba() or a
separate property.

Tantek

Received on Tuesday, 26 March 2002 12:43:38 UTC