Version: 4.0 (using KDE 3.1.93 (CVS >= 20031111), compiled sources) Compiler: gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk) OS: Linux (i686) release 2.4.21-3mdk The <button> tag should be rendered by default exactly like <input type="button">, that is - with the KDE widget style, but instead it is rendered using some default style which just doesn't fit with all the other form elements
Created attachment 3257 [details] Screenshot of problem
More button rendering problems - should I report them here or create a new bug ? * buttons are not flowing with text: each button is rendered like a <div> tag on a line of its own. <button> tags should flow with other content by default. * pushed buttons are not released until the mouse-out event - when a button is clicked, its image becomes "pushed" but when the mouse button is released, the image remains in the "pushed" state until the mouse is moved outside of the button.
Yes, report other things as seperate bugs. ATM the fact that button tags are handled differently from form buttons is at least a bit intentional, since button tags are very much more webpage-author-specific than input buttons are. I think the intention of the w3c was to make button tags extremely customizable, and form input buttons look native.
AFAIK, the intention of W3C is to phase out <input type="button"> and use only <button> tags (which are indeed more customizable). but I still think the default <button> should look like a native button. Thanks, I will resubmit the other problems as new bugs.
Created attachment 4269 [details] Some buttons themed, some not. For some strange reason it sometimes happens that only _some_ of the 'BUTTON' tag buttons are rendered without KDE themeing. The buttons on the screenshot are exactly the same in html, yet some of them appear differently in Konqueror.
I was going to post a bug about this, but didn't want to dupe. Any word on if this will be fix, or no action taken?
AFAIK nothing has been done in CVS regarding this issue. I wonder how safari is handling this issue.
Confirmed. The problem is that Qt widgets can't cope with html content (like <button> allows). We could hack around it, but I'm not sure if it's worth it.
I can see three options here: A. wait till Qt handles HTML in widget content (never?) B. Render the HTML using khtml into a QT button (does Qt widget have "owner render" as in Win32 ?) C. Try to detect if the content of the button tag is simple text (and render using Qt) or complex HTML (and render using current methods). I think implementing C will be the "most bang for the buck" solution and should be implemented. I don't think it'll be too hard, and I'm willing to do it myself if someone can point me at where I should look for - as I'm a bit rusty on C++ and know almost nothing of KHTML code base.
Since its just a graphical glitch it should be lower priority, but it would be very nice to fix them. I just switched my theme and found this problem so I went back and removed my button tags from a web-based program I'm making. Not saying you should fix it so I won't have to change the button tags to input type="button", but just because that shared look and feel of the browser components with that of the rest of the desktop is what I love about Konqueror.
unfortunately still valid in 3.5.0
*** Bug 119273 has been marked as a duplicate of this bug. ***
*** Bug 153155 has been marked as a duplicate of this bug. ***
And 4.0.0
How does Qt WebKit handle this?
Created attachment 24238 [details] button test using <button> and <input type=Button">
QtWebKit seems to do Oded Arbel's option C: Detects whether or not the <button> contains stuff Qt can't handle.
Still not fixed in 4.5.4, updating version.