Hello, mapping css properties to dw::core::style::Style members went very smooth, because Style was obviously implemented with css in mind. Just for the shaded color thing I can't find a corresponding concept in css. What exactly is the definition of a shaded color? Is it just a bit darker than the normal one? Does anyone know the corresponding concept in css? Cheers, Johannes
Johannes wrote:
mapping css properties to dw::core::style::Style members went very smooth, because Style was obviously implemented with css in mind.
Just for the shaded color thing I can't find a corresponding concept in css. What exactly is the definition of a shaded color? Is it just a bit darker than the normal one? Does anyone know the corresponding concept in css?
I had figured the shaded colors were just for giving tables and rulers a three-dimensional appearance.
On Sun, Nov 23, 2008 at 04:13:56AM +0000, corvid wrote:
Johannes wrote:
mapping css properties to dw::core::style::Style members went very smooth, because Style was obviously implemented with css in mind.
Just for the shaded color thing I can't find a corresponding concept in css. What exactly is the definition of a shaded color? Is it just a bit darker than the normal one? Does anyone know the corresponding concept in css?
I had figured the shaded colors were just for giving tables and rulers a three-dimensional appearance.
Right, it seems to be used in drawBorder() in style.cc. Only now I noticed that the only difference between shaded colors and normal colors is that for shaded ones two more variations (SHADING_DARK and SHADING_LIGHT) are computed in addition to SHADING_NORMAL and SHADING_INVERSE. So it seems that it's an optimization to avoid calls to Color::shadeColor(). I'd like to get rid of the two types of colors and use always shaded colors. The current scheme adds complexity and can lead to errors (e.g. a normal color is passed to drawBorder(). In addition we can get more sharing of colors if they don't have a type member. If needed we could call Color::shadeColor() only on demand, but hide that optimization in the Color class. Any opinions? Cheers, Johannes
Johannes wrote:
On Sun, Nov 23, 2008 at 04:13:56AM +0000, corvid wrote:
Johannes wrote:
mapping css properties to dw::core::style::Style members went very smooth, because Style was obviously implemented with css in mind.
Just for the shaded color thing I can't find a corresponding concept in css. What exactly is the definition of a shaded color? Is it just a bit darker than the normal one? Does anyone know the corresponding concept in css?
I had figured the shaded colors were just for giving tables and rulers a three-dimensional appearance.
Right, it seems to be used in drawBorder() in style.cc. Only now I noticed that the only difference between shaded colors and normal colors is that for shaded ones two more variations (SHADING_DARK and SHADING_LIGHT) are computed in addition to SHADING_NORMAL and SHADING_INVERSE. So it seems that it's an optimization to avoid calls to Color::shadeColor().
I'd like to get rid of the two types of colors and use always shaded colors. The current scheme adds complexity and can lead to errors (e.g. a normal color is passed to drawBorder().
In addition we can get more sharing of colors if they don't have a type member.
If needed we could call Color::shadeColor() only on demand, but hide that optimization in the Color class.
Any opinions?
No objections here.
On Sun, Dec 14, 2008 at 08:00:48PM +0000, corvid wrote:
Johannes wrote:
On Sun, Nov 23, 2008 at 04:13:56AM +0000, corvid wrote:
Johannes wrote:
mapping css properties to dw::core::style::Style members went very smooth, because Style was obviously implemented with css in mind.
Just for the shaded color thing I can't find a corresponding concept in css. What exactly is the definition of a shaded color? Is it just a bit darker than the normal one? Does anyone know the corresponding concept in css?
I had figured the shaded colors were just for giving tables and rulers a three-dimensional appearance.
Right, it seems to be used in drawBorder() in style.cc. Only now I noticed that the only difference between shaded colors and normal colors is that for shaded ones two more variations (SHADING_DARK and SHADING_LIGHT) are computed in addition to SHADING_NORMAL and SHADING_INVERSE. So it seems that it's an optimization to avoid calls to Color::shadeColor().
I'd like to get rid of the two types of colors and use always shaded colors. The current scheme adds complexity and can lead to errors (e.g. a normal color is passed to drawBorder().
In addition we can get more sharing of colors if they don't have a type member.
If needed we could call Color::shadeColor() only on demand, but hide that optimization in the Color class.
Any opinions?
No objections here.
Ok, I pushed a corresponding change to css-prototype. Cheers, Johannes
participants (2)
-
corvid＠lavabit.com -
Johannes.Hofmann＠gmx.de