opacity -moz-opacity filter alpha transparency css3

[Marek Mänd]

This posting will express my concern about the future of css3
forthcoming recommendation.

I think for long time now, that the current implementation of CSS
attribute opacity is less than usable in practical real life situations.
The soon forthcoming CSS3 recommendation does not serve the public
interests in this area not at all. The problem relies in the definition
what opacity is, how it is to applied to page elements.

In past 5 years the web based applications have made a big leap in
visual, they are becoming more appealing and eye-catching. More and more
software applications are used via web browser. Transparency has given
us potentially to craft more versatile user interface experience to the
end user. But the problem is - POTENTIALLY.

As time has gone by, we all have witnessed how time consuming has been
for majority of the browser makers to adopt to CSS2, thus it is not
shortsighted to claim, that the same process will happen to the CSS3
likely too. Therefore it would be highly regretable if the currect
definition of opacity in CSS3 candidate recommendation will be the final
word, that defines opactiy behaviour for CSS3.

So where is the problem?
Problem is that the opacity definition seems again one of those kind,
that is specified in not foreseeable manner, that requires for browser
makers to do only little - implement few bits to acclaim the
compatibility with css3.
But the real software engineers needs, who actualy build applications
used via web browsers, are different that the CSS3 current "weak"
recommendation (section included below my posting) proposes.
There should be a ability to make elements transparent in manner, that
DOES NOT MAKE the elements containing text transparent. That is - there
should be definately a way to make element backgrounds transparent
without using IMAGES (ccs backround-image). Developing that idea, it
should also be possible to make the opacity to be applied only on parts
of the element (borders, content area etc). Although the current
inheritage system for opacity follows the natural CSS logic, it is still
totally unaceptable for software engineers of near future who craft web
applications used via web browser - there is no way to put in a box that
has opacity set another box that can be "fully seen without effect
applied". The opacity is the first of its kind of CSS properties - a
graphics filter - and thus the problem domain is totally new to the CSS
standard which traditionally basically deals with handling dimensions,
gaps, widths-heights between elements and font sizes and colors. AS
problem dmain is new, the opacity has been handled the old css way and
therefore it is and will become unusable in more complex use cases.
When the current CSS3 candidate recommendation opacity specification
will be in power, web application frontend developers will TRULY FIND NO
PRACTICAL USE for the opacity css property.
The previous examples of such kind of non demanding and
"no-hard-work-to-do" requierments (maybe compiled so due to lobby of
browser makers) for browser makers friendly spec in CSS2 was the table
cell attributes inheritage from column
http://www.w3.org/TR/CSS2/tables.html#q4
where only inherited css attributes by the specification were
'border','background','width','visibility'
and
where you could not apply such practical things as padding to the whole
column, and what even more outrageous, that the CSS2 spec never gave
orders to must-have implementation of CSS text-align property
http://www.w3.org/TR/html4/struct/tables.html#edef-COL
although as seen from HTML4.01 specification, the attributes
ALIGN
http://www.w3.org/TR/html4/sgml/dtd.html#cellhalign
VALIGN
http://www.w3.org/TR/html4/sgml/dtd.html#cellvalign
definately and clearly exist in HTML specifications and as opposed to
the majotity of in past reigned mindset, that those CSS text-align and
CSS vertical-align (aswll as other) attributes will cause inheritance
conflicts in tables, is to be prooved FALSE, as there exists the same
functionality in HTML4.01 and it works. As ALIGN and VALIGN HTML
attributes are presentational attributes it is a

shame

that the CSS2 creators should feel the guilt of offereing the world such
sub-ueber specification, as the whole concept of CSS was controlling the
presentation. Statements about inheritation conficts unresolvancy are
immature and biased, not seeing the industry everyday needs as the by
the Microsoft Internet Explorer the inheritage of table column CSS
attributes is beyond the attributes
'border','background','width','visibility'
because it uses common sense and industry needs and the performance loss
is no significant.
There is even a table of table componet virtual layers
17.5.1 Table layers and transparency
http://www.w3.org/TR/CSS2/tables.html#q4
which defines how ro draw backrounds, which have could been used to
define the inheritage for other vital table column css-properties such
as "text-align" and padding.

--
Marek Mänd
Europe, Estonia, Tallinn
P.S.
what says w3c doucuments about opacity?
http://www.w3.org/TR/2003/CR-css3-co.../#transparency
..2. Transparency: the 'opacity' property

Opacity can be thought of conceptually as a postprocessing operation.
Conceptually, after the element (including its children) is rendered
into an RGBA offscreen image, the opacity setting specifies how to blend
the offscreen rendering into the current composite rendering.
Name: opacity
Value: <alphavalue> | inherit
Initial: 1
Applies to: all elements
Inherited: no
Percentages: N/A
Media: visual
Computed value: The same as the specified value after clipping the
<alphavalue> to the range [0.0,1.0].

<alphavalue>
Syntactically a <number>. The uniform opacity setting to be applied
across an entire object. Any values outside the range 0.0 (fully
transparent) to 1.0 (fully opaque) will be clamped to this range. If the
object is a container element, then the effect is as if the contents of
the container element were blended against the current background using
a mask where the value of each pixel of the mask is <alphavalue>.

[Martin!]

Marek Mänd wrote:

i took the freedom to condence your story a little.

I think the current implementation of CSS attribute opacity is less than usable. The -current- CSS3 recommendation -on opacity is not helpful-. Problem is that the opacity definition -is unclear-. There should be a ability to make elements transparent -while
keeping the text opaque-.
it should also be possible to apply the opacity on borders, content area etc. -currently, opacity is inherited and cannot be undone in nested elements-

like this i would even subscribe to your comments and wishes-list on
css-opacity. but i dont think that opacity is so important.

gl
martin

[phil_gg04]

I think what you're saying is that you'd like to be able to specify
opacity with the same level of control that you have to control colour.
For example, with the current proposal you can say:

foo {
background-color: rgb(255,0,0);
color: rgb(0,0,0);
opacity: 50%;
}

and get 50%-transparent black text on a red background. But you'd like
to make it 100% opaque black text on a 50% transparent red background.
I can understand this. Perhaps the way to do it is to make the alpha
value part of the colour properties, like this:

foo {
background-color: rgba(255,0,0,128);
color: rgba(0,0,0,255);
}

This sounds sensible to me. Has the case been made to the appropriate
people? What do they say? Is the implementation efficiency
significantly impacted?

I believe that you can get the effect that you want with an extra level
of nesting:

<div class="a"><div class="b>.....

..a{
background-color: rgb(255,0,0);
opacity: 50%;
}
..b {
color: rgb(255,0,0);
opacity: 100%;
}

Is this true?

--Phil.

[Salagir]

The original post may be a troll, but I shall feed it anyway.

On 4 Mar 2005 10:22:07 -0800, in comp.infosystems.www.authoring.stylesheets,
ph*******@treefic.com wrote:

background-color: rgba(255,0,0,128);
color: rgba(0,0,0,255);

This would be a very good thing. Really.
I'm more and more worried about the CSS2 and CSS3 specifications. It
seems like they're trying to do something very logic, very strict, and I
like that, but it really become impossible to use. I mean especially in
pratical cases.
It's certainly an old troll, but there are many thing I can't do because
implementing them would certainly make the css spec less "solid", but
these are things the webmaster *will* want to do.
The webmasters WILL WANT to have a div background half-transparent and
without using a div in a div or a 32bit-png image.
The webmasters WILL WANT to put a div with a total width
(margin+padding+border) of 50% and a specific margin and padding at
differents units and don't care that they can specify the inner width to
something. They don't know what will be its size. They don't want to use
a div in a div either.
The webmasters WILL WANT to put a background-image that will
automatiquely adjust to the size of the div.

And they want to do it simply.

Each time a friend asks for help for css, I tell them many many
workarounds, and not only because browsers do things differently.
When css will be understandable only by geeks, people will make sites
in flash or some microsoft page layout standart. :-(

--
My Webcomic: www.geeksworld.org -+- All my websites: manaworld.free.fr
There's never enough time to do all the nothing you want.
-- Calvin