From StyleEngine we get a background and a text color, but we don't know what the text color would have been if the link would not be visited. So we can't enforce a color that is different from
Hi, as we seem to have agreed on using CSS for style customization intead of dillorc settings, I'm trying to get rid of these: link_color: visited_color: text_color: bg_color: force_my_colors: The same thing can more or less be expressed with a custom user stylesheet, so I want to remove them. The problem is non-HTML pages (plain). I would propose to simulate <body><pre> in this case and use the corresponding style. allow_white_bg: This can't be expressed with CSS. We could detect a white background in StyleEngine (like we detect font sizes smaller than font_min_size), but what color should we use instead in this case (note that it must be different enough from the text color)? contrast_visited_color: This one is hard. Consider we want to render a visited link. that. Generally (and even more with CSS), background- and text-colors can change arbitrarily within a page. So there is not a background and a text color per page. standard_widget_colors: Not sure about this one. On the one hand I think that CSS support broke this. On the other hand CSS allows the page author to directly set colors of form widgets. corvid, can you please have a look? Cheers, Johannes
Johannes wrote:
standard_widget_colors:
Not sure about this one. On the one hand I think that CSS support broke this. On the other hand CSS allows the page author to directly set colors of form widgets. corvid, can you please have a look?
I see that non-form inputs get a background color if I put html->styleEngine->inheritBackgroundColor () in open_body. I thought I didn't need that for elements that have a widget -- or is it different when the widget already exists? (and presumably I would just have to add another inheritBackgroundColor in open_form...)
On Thu, Mar 05, 2009 at 08:24:42PM +0000, corvid wrote:
Johannes wrote:
standard_widget_colors:
Not sure about this one. On the one hand I think that CSS support broke this. On the other hand CSS allows the page author to directly set colors of form widgets. corvid, can you please have a look?
I see that non-form inputs get a background color if I put html->styleEngine->inheritBackgroundColor () in open_body. I thought I didn't need that for elements that have a widget -- or is it different when the widget already exists?
No, I think the problem is that fltk widgets are not transparent. So even if the parent widget has drawn the background properly, it won't shine through the fltk widgets.
(and presumably I would just have to add another inheritBackgroundColor in open_form...)
I would rather suggest using styleEnginge::backgroundStyle() for non-transparent widgets. I haven't tested it though. To sum it up, inheritBackgroundColor() should be set if an element does not create a widget and therefore does not draw a background (e.g. <span>). backgroundStyle() can be used for widgets that need to have style->backgroundColor set to something non-NULL. Cheers, Johannes
participants (2)
-
corvid＠lavabit.com -
Johannes.Hofmann＠gmx.de