Thread: Tear 0.3 - Simple WebKit browser, now with Dashboard
View Single Post
Sho is offline Sho
2009-04-09 , 21:06
Posts: 126 | Thanked: 94 times | Joined on Jun 2007 @ Berlin, Germany
#869
Originally Posted by Bundyo View Post
About the colors - yes, I think I wrote just that above, though you missed something - when you turn on the system colors, the rest of the site breaks, not the input boxes.
Sorry, this was a later edit to your post, so I'll reply in a separate post now:

I did understand your point that using the system theme colors outright as default background and font colors would break many pages; I'm familiar with the problem, actually. Site authors frequently set a text color but forget to set a background color, so a browser inheriting a black window background color from the system for its document viewport corrupts site layout. I get it.

However, this is a more limited problem. It's about input fields. Somewhere in WebKit(GTK) is code that checks whether an input field is styled or unstyled, and then either uses custom drawing or goes to the system widgets. E.g. if I set "border:1px solid black" on an <input>, WebKit will draw a simple 1px border rectangle instead of a GTK+ widget. In the Google case I cite in the bug report, the website sets up black as default text color in <body>, but applies no other formatting to <input> tags. So WebKit(GTK) probably decides that this is an amount/a type of formatting that can be handled by the system widget and spawns one, asking it to render text in black. I believe that this decision right there is broken, because the widget's *background color* isn't taken from the site (because, well, there usually isn't one set by the author) while the *font color* is, which causes problems like this.

So I ask that it ignores the site's formatting and goes for the system default input field font color in all rendering cases that can satisfied by the system widget. This basically won't really break any pages, because any page that cares to set an unusual (i.e. other than black) font color on <input> will usually also change its background and border properties to a degree causing the GTK+ widget not to be used anyway.

As a KDE developer, I'm more familiar with the KHTML code than with WebKit's, and I expect this is one of the areas where the WebKit codebase diverges the most from KHTML, as KHTML simply directly goes for Qt widgets whereas WebKit has a platform/backend abstraction mechanism. But if the WebKit authors have at all managed to preserve the cleanness and simplicity of the KHTML codebase, the above behavioral change should be fairly simple to pull off.
Last edited by Sho; 2009-04-09 at 21:12.
 

The Following User Says Thank You to Sho For This Useful Post: