Re: Opacity 0-1: Bad Idea?

Chris Lilley wrote:

> Computer graphics artists are, in fact, people ;-)

I'll tell the ones I know, they'll be pleased to hear the w3c recognises
this ;)

> > J David also proposes supporting both percentages and units, and both
> > opacity and transparency, thus covering both compatibility with SVG and
> > the way people think in real life.
> 
> No. Sorry, that does not provide 'compatibility' at all. Consider a
> multi-namespace XML document where parts are in some namespace that uis
> being styled textually using the CSS box model and parts are in the SVG
> namespace and being styled as SVG. Consider particularly  the case where
> the root of the document A is textual, it has a child tree B in SVG
> which in turn has a child tree C which is textual. For example, C is a
> callout B is a diagram and A is a manual. Now, if I have an opacity
> property (or a transparency property that somehow interacts with it) set
> on A and it inherits right down to C - what is the computed value at all
> points

I must admit this confuses me somewhat. If one, for the purposes of this
discussion, defines "transparency" as simply the opposite of opacity,
then, as far as I can see it has no effect on the above example. Anyone
implementing such a viewer could simply implement transparency by saying
"opacity = 1.0f - transparency" (or 100% - transparency%) and compute
the value at all points just as they were before. Not to say this
wouldn't require some work to work out the correct composition, but I
was regarding transparency as a (preferable to me) syntatic sugar for
opacity. It shouldn't effect the overall difficulty of determining the
final result...?

> I live in hope that, maybe in five to ten years, some folks might
> realise that there is more to life than HTML browsers.....

heh. nah ;)

[ ... long list] 

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

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.

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.

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

 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. Would this be compatible with SVG and other uses of the attribute?



-- 
AndyT (lordpixel)

Received on Monday, 12 November 2001 18:15:36 UTC