Bug 73956

that looks like a mozilla css3 extention?

In Mozilla we have a moz-border-radius like it was used on the side I post. In css3 we have a border-radius definated, that I think was the same!

it's the same, yes. Only called -moz-, because it's still only a working draft.

I studied this to evaluate possible implementation. There are several problems. First the Mozilla implementation doesnt follow the specification. Second it is entirely impossible to follow the spec., since it is not integrated with the border features of CSS2. 

For instance which colour or style should be used for the top-left corner: The colour and style of the top border, or those of the left border?

Other issues include clipping. The spec. specifies that the background should be clipped at the rounded border, but what about box contents? If the padding is 0 a rounded corner will inevitably intersect content.

*** Bug 101491 has been marked as a duplicate of this bug. ***

Has anyone of those people who are competent in this matter contacted the people responsible for the specifications. If there are issues to be improved they would  appreciate it, I think.
Implementing this would definitely give a lot of KDE's applications a nicer look. Amarok already uses frames with round borders (is that done with pictures?). Kmail's header-section could need the the round borders as well as many other sharp edged corners e.g. in kopete or KDE documentation.

What about implementing the round corner, but not mention it as CSS feature yet. This way round corners are available to applications and if the specifications get more detailed, the basic functionality is already available and can be used to develop it further.
The basic functionality would simply draw half the radius in the colour of the first border and the second half of the radius in the colour of the other border. If that is too complicated, one could simply make a choice. As most frames consist of the same colour, this would not matter anyway.

Hi guys. I'm working on some algorithms to hopefully replace the Firefox code for borders. I'm writing them in JavaScript at the moment, as it's what I'm used to.
  Once the code is complete, it should be reasonably simple to convert to another language, so you could use the same algorithms to solve the KDE border-radius code if you wanted.

See http://verens.com/demos/borders/test.html for an example, using plain CSS3

I'm pretty close to completing the solid border code. Once that's finished, I'll be adapting that code to also solve double borders, then dashed (the tricky one :) ).

I should have the algorithms completed before the end of the month. I'll be tackling a conversion to Firefox code myself, followed by KDE, but if you want to tackle it yourself, I'll announce when I'm finished.

Very cool stuff! 
Are you going to add anti-alias? 
Have you seen any descriptions for dealing with multiple colors like you do in the example?

Allan, yes.
  If you view the test page in Firefox, you can see the anti-aliasing in effect. I'm using the CSS "opacity" style for the JavaScript, but I'm not sure how to get that working in Konqueror, so Konqueror does not display the test page as it is supposed to be displayed. (Ironically, I can get it /almost/ working in IE on Windows ;) )
  At the moment, anti-aliasing is correct for straight borders, beveling and 1-pixel height sections of curves. I will have perfect anti-aliasing tomorrow (was busy gardening today :) ).
  When translated to the Firefox and KHTML, I think antialiasing will be done using alpha-values. Firefox's API has an RGBA() structure for colours. I'm not sure how KHTML handles it (must admit, I haven't looked yet), but my guess is that there will be no problems applying the same anti-aliasing methods when the time comes.

As for the question of how to address multiple colours - I based the method I use on the existing Mozilla code.
  The W3C proposal does not mention anything about colours, so I guess we're in fresh territory here.
  The mozilla method (for the top-left corner, eg, the colour border is coloured using the left colour up until 45 degrees, and then by the top colour) is the easiest "correct-looking" method.
  A "more-correct" method might be tho gradiate the colour from one side to the other, but I'm not going to touch that one - it's a headache for some poor sucker in the future :)

Back on the anti-aliasing question - I haven't touched anti-aliasing for the background image/colour, in cases where the image is visible to the outer-edge (in dashed lines, eg, or with transparent/0px borders). Again, that's a job for the future (I'm concentrating purely on the borders at the moment).

Has there been any movement on this? Konqueror 4.1.2 still doesn't seem to support border-radius, and there's been 3+ years of silence here.

Created attachment 30842 [details]
border-radius test

It looks like Konqueror 4.2.0 supports border-radius now (although only as -khtml-border-radius). However, the behaviour with large radii and >1 border colour is rather ugly. See the attached test case.

Created attachment 30846 [details]
A screenshot from the above test case

Here's what I'm seeing for the large border radii... nevermind the small delay, I became substantially distracted by bug 181072 in the process of taking the screenshot.

In december 2009, the CSS3 Backgrounds and Borders Module became a candidate recommendation. When a spec becomes a candidate recommendation, browser manufacturers/implementors should drop their prefix:

"
The CSS Working Group recommends that experimental implementations of features in CSS Working Drafts use vendor-prefixed property or value names. This avoids any incompatibilities with future changes in the draft. Once a specification reaches the Candidate Recommendation stage, implementors should implement the non-prefixed syntax.
"
http://www.w3.org/TR/css-beijing/#experimental

So, Konqueror should now support border-radius, not just -khtml-border-radius.

This bug is now contextually very relevant.

regards, Gérard

Hello all,

I am using Konqueror 4.4.2 and testcases with border-radius are supported correctly. 

33 tests recently made public on border-radius:
http://samples.msdn.microsoft.com/ietestcenter/css3/css_harness.htm?url=./bordersbackgrounds/border-radius-style-001.htm

Konqueror 4.4.2 seem to fail only a couple of tests: test 12 and 13.

regards, Gérard

A meta-testcase:
http://ie.microsoft.com/testdrive/HTML5/01BorderRadius/Default.html

Konqueror 4.4.3 passes this test.

regards, Gérard

Another website with several border-radius testcases:

Table of CSS3 border-radius Compliance by Jerry Seeger
http://muddledramblings.com/table-of-css3-border-radius-compliance

At least 6 testcases fail in Konqueror 4.4.3.



Updated link on Microsoft Test Center's border-radius 33 tests:
http://samples.msdn.microsoft.com/ietestcenter/css3/css_harness.htm?url=border-radius-style-001

regards, Gérard

Konqueror 4.4.5 fails these testcases:

http://samples.msdn.microsoft.com/ietestcenter/css3/bordersbackgrounds/border-top-left-radius-values-003.htm

http://samples.msdn.microsoft.com/ietestcenter/css3/bordersbackgrounds/border-radius-shorthand-001.htm

regards, Gérard

57 tests on border-radius, box-shadow, CSS3 background properties (background-clip, background-origin, background-size, background-position, etc.):

http://samples.msdn.microsoft.com/ietestcenter/css3/css_harness.htm?url=border-radius-clip-001 (being the first test)

Konqueror 4.5.5 fails many of these tests.

regards, Gérard

57 tests on border-radius, box-shadow, CSS3 background properties
(background-clip, background-origin, background-size, background-position,
etc.) (updated link):

http://samples.msdn.microsoft.com/ietestcenter/css3/css_harness.htm?type=bordersbackgrounds&url=border-radius-clip-001

Latest Konqueror version 4.6.5 fails many of these tests.

regards, Gérard

Dear user,

KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6.

Please migrate to use a QWebEngine based HTML component.

We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes.

For security issues, please see:

https://kde.org/info/security/

Sorry that we did not fix this issue during the life-time of KHTML.

Greetings
Christoph Cullmann