Re: Opacity 0-1: Bad Idea?

Andy wrote:
> 
> Chris Lilley wrote:

> > The majority of these are svg-only, but some are also allowing opacity
> > to be used in non-svg contexts in the same tree, now that its definition
> > is nailed down and that it is merely a case of including it or not in
> > CSS3 for non-graphical uses.
> 
> Thanks for going to the effort of compiling that list Chris. It's
> certainly fascinating to see there are such a breadth of implementations
> out there. I still feel its a you (plural) picked the syntax you did but
> I guess the writing in indeed on the wall for that one.

OK. And yes, it is a pretty impressive list of implementations, isn't
it?

> While I've raised the subject though - could you give me your opinion on
> opacity for other parts of CSS. Specifically I guess I am talking about
> (X)HTML here, but it could equally apply to another XML dialect, I think.

CSS box model applies to any textual format in XML. It can of course be
XHTML but equally it could be MyFooMLThatIJustMadeUp.

> Opacity is great for certain effects, and it removes the need to use
> images purely to achieve for some styles of presentation, but the
> problem I've encountered with it is it adversely effects text legibility.

Yes. Of course, that assumes the value is statuic.the next thing to do
is to animate it so content can fade in from zero opacity to full
opacity (and, as you note, legibility).

> I'd personally like to see separate control over text opacity, so I
> could write:
> 
> opacity: 0.5;
> text-opacity: 1.0;
> 
> so I would get the effect I want from my background, without sacrificing
> the readability of my text.

Yes, I can see where you are going with this and I agree (but see below
about the names)

> For the purposes of orthagonality within CSS as it applies to HTML, this
> would suggest defining border-opacity, though that is less useful I can
> see cases where people would want a firm border around an otherwise
> partly transparent box (for a GIF based "fake" example see
> http://www.penny-arcade.com/) Indeed I can see that ideally one would define:
> 
> background-opacity, text-opacity and border-opacity

Yes. You have probably already noticed that in addition to the opacity
property, SVG defines fill-opacity and stroke-opacity and stop-opacity
.... which apply to individual elements wheras the group 'opacity'
property applies to an entire subtree which is rendered opaque into an
offsctreen buffer and then composited at the particular opacity value.

> 
>  I guess opacity would set the all of the contents of an element and
> children, as it does now, and the others would allow more fine-grained
> control.

Yes, exactly.

> Would this be compatible with SVG and other uses of the attribute?

Sure.

You would note that the definition of the CSS 'color' property
explicitly says it is the *color of text*, so SVG was unable to re-use
it (well you can set other properties from it, but its not used
directly) plus in graphics things can be both filled and stroked. So SVG
has properties for the fill and for the strok, and each has the
corresponding value for the opacity (fill-opacity and stroke-opacity).
Also, since we have gradients with stops, each stop can have the
stop-color and the stop-opacity set.

So for CSS3 it makes sense to be able to control the background opacity
as one can with the background color, and also the border opacity as one
can with border color (problem though, would we need border-top-opacity
and all that stuff too) and the text color opacity (color-opacity?).

In addition to the opacity property which is for rendering entire
subtrees at a particular opacity.

Note that the introduction of opacity on background requires definition
of ther color of the canvas before the roor element is painted. In SVG
we went for white. You can get other colors by setting the background
color on the root element and setting the background opacity to 1.0. But
if its *not* 1.0 you need to know what color to composite on top of.

-- 
Chris

Received on Monday, 12 November 2001 19:08:40 UTC