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

On Tuesday, March 26, 2002, 6:45:54 PM, Tantek wrote:

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

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

TC> Yes, this should be clarified either way.

TC> Strikethroughs are typically drawn over the relevant text.

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

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

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

For SVG, the order of rendering individual glyphs was specified (since
they can be semi-transparent and it makes a difference)
http://www.w3.org/TR/SVG/text.html#TextRenderingOrder

also the order of drawing of text decoration.
http://www.w3.org/TR/SVG/text.html#TextDecorationProperties

<quote from='10.12'>
Except for any additional information provided in this specification,
the normative definition of the property is in [CSS2-text-decoration].
The rules for expressing the syntax of CSS property values can be
found at [CSS2-propdef].  [...]

Because SVG allows text to be both filled and stroked, drawing order
matters in some circumstances with text decorations. Text decoration
drawing order should be as follows:

All text decorations except line-through should be drawn before the
text is filled and stroked; thus, the text is rendered on top of these
decorations.

Line-through should be drawn after the text is filled and stroked;
thus, the line-through is rendered on top of the text.
</quote>

This is the same order as you described.

TC> Perhaps this should be clarified in the CSS3 Text Module?

Since there seems to be at least two data points agreeing on an order,
perhaps adopting the wording from the SVG 1.0 Rec would solve the
wider problem, too.

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

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

You misunderstand.

1) compound values can already be animated

2) there is already an animate Color element, specifically to animate
color

3) animations can be chained, and can repeat

4) try expressing an animation where the
color goes from blue to green, over a period of five seconds, for
times; and where the transparency of the text fades from 0 to 1 over a period of three seconds and repeats indefinitely
a) using animations of separate properties
b) using an animation of a single property

Both can be done, but one is a whole lot easier to author and to understand.


>>and DOM manipulation.

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

Granted. Provided the inefficiencies of string slicing are not a
drawback, this can be done.

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

TC> You have to do so in either case.
Yes, that is correct. I was showing that the additional rules were
shorter in the separate property 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}

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

Ah, that seemed to be the point.

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

Yes, you will. However, such rules need not re-state the color as well.


-- 
 Chris                            mailto:chris@w3.org

Received on Wednesday, 27 March 2002 22:59:29 UTC