We need a -moz-outline-radius feature (similar to -moz-border-radius) to support the round outline required in the spec for radio buttons. We need to outline the radio buttons with rounded corners.

Sure! M14.

Marking dependency on bug 9809.

Style is done. We need to do the rendering. Maybe Don Cone will take care of it?

hangas/german: the '-moz-outline-radius' feature has a dependency on bug 9809. If you want it for beta, you will have to talk to Rod and Troy or lobby the PDT team. Reassigned to dcone for now. The bug may be pushed to a later milestone if the dependency is not resolved.

Actually outline should follow the exact outline of an element, so an outline radius is not necesairy, it should do that automatically

duplicate of bug 15323 ?

The feature has been added, but there are problems that come with this, like rendering outside of the Frame, etc. Rod can you comment on this or tell me what should happend with this now.

This bug has been marked "future" because at this time it has been determined that it is not absolutely critical for RTM (Release To Manufacturing). If the reporter and anyone else believe it is necessary to fix this before shipping Seamonkey 1.0, please describe your issue in the bug.

rods: According to dcone, this has been half-implemented. We cannot ship with a half implemented feature, surely!

Are you sure dcone said it was half-implemented? In my understanding, it was fully implemented but subject to the same clipping problems as the normal outline.

Well, the ordinary outline is just as incomplete, precisely because of these clipping and the repainting problems... Whichever way you look at it, we can't ship with these outline bugs still present. Either outline (and -moz-outline-radius) has to go, or outline has to be fixed.

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

I don't think we can disable outlines: they are used to give feedback when mousing over links. My understanding is that they work for mouseover but not for more persistent uses such as indicating the active and focus states.

I guess I'm several weeks late... Outlines are no longer used for links and they don't seem to work at all anyway. I have been confused by the declarations in html.css. Rod, can you confirm that outlines are disabled? If so, we can update html.css.

Because of the fact that the moz-border-outline is not working very well and this bug was not fixed in time for the implementation of our first two skins, we have found work-arounds for this issue. Leaving this feature out of the product at this point is just fine with me.

Shall we just mark this WONTFIX? *We* don't need it, and in a future version we can get the W3C to find a standards compliant way of doing things.

Why WONTFIX? There is no point in removing the code, the outlines have been disabled. The day 'outline' works, 'outline_radius' will work too and if there is a standard way to do it, we'll adopt it.

I didn't realise any code had been written for this at all. Of course I do not suggest removing code already written. 'outline' has not been completely disabled, BTW, see bug 9816.

As per meeting with ChrisD yesterday, taking QA.

This is required for Mac-style focus outlines.

Note: per the spec, outlines may not be square. Thus implementing this is much more difficult than implementing the equivalent border code, which is guarenteed to only have 4 corners.

leaving as P3/Future

This shouldn't be necessary in order to get the correct outline for a radio button. Outlines don't have to be rectangular, so as long as the outline code is aware of the geometry of the radio button, a simple outline will have the correct shape. Wontfix?

Now that bug 151375 is fixed, outlines draw outside of the current frame. A fix for this bug would be useful for nice focus outlines, esp. on Mac. I notice that the outline radius is not getting stored where it's supposed to, in mOutlineRadius.

Boris asked for a real world case where you wouldn't want the radius to be the same on all four corners. Here it is: http://bugzilla.mozilla.org/attachment.cgi?id=153283&action=view (Boris, sorry for CC'ing you without being asked to)

The problem remains that an outline can have more than 4 corners...

(In reply to comment #29) > The problem remains that an outline can have more than 4 corners... In most cases it won't. In the cases where it does, we can make all top left corners use the -moz-outline-radius-topleft, all top right corners would use -moz-outline-radius-topright, etc. We'd fix that at the same time that we fix the fact that outlines aren't globbing together.

Consider an outline shaped like so: ___________________ | ____| ___| | |_________________| This outline has 8 corners of 6 different types. I'm not clear on how you plan to implement that with 4 different corner types stored in the style struct...

(In reply to comment #31) How about this? Each corner uses the property associated with the corner of same orientation. TL___________________TR | ____| TL_|BR TL| BR |_________________| BL BR This allows use 2 things: 1) to use -moz-border-radius on individual corners when it matters most -- the rectangular case. For tabbed and segmented widgets we may need individual corner radii for focus outlines. 2) to do something that's not too far fetched for the edge case. For spans containing flowing text it's very unlikely that people will need different border radii for each corner. They would likely be consistent for those cases.

I'm just not sure that it makes sense to label the two different types of corners you called "BR" the same type..

Yes but does that mean we shouldn't allow use of different radii on different corner types at all? Nothing really bad will happen in the overlapping non-rectangular case, and 99.9% of the time people wouldn't be needing different radii then. What's your suggestion? Throw out that capability because of the unclear edge case? (In reply to comment #33) > I'm just not sure that it makes sense to label the two different types of > corners you called "BR" the same type..

No, my suggestion is to clearly think about what we do and do not want to support and then implement it. I have no principal objection to the suggestion in comment 32 (or any other suggestion, really), but I'd like to see some consensus.

Here's an algorithm: -- For each rectangular frame of the element, use the outline-offset and outline-radii to compute the inside edge of the outline for that frame as a closed path. -- Take the union of the interiors of all these closed paths. -- Stroke along the exterior of that union with the given outline-width.

In the example in comment 31, that would create a cusp in the outline in the place where the border goes like: _____ __| right? That said, it's the best way to make sense of the specified outline radii, I guess.

I'm against separate corner specification. I think Aaron's example in comment 28 isn't really a good example because the thing being outlined can't be described using CSS either.

Assuming a small outline-radius, the concave vertices will be right angles.

dbaron: you could do it using a four-value border-radius.

Sounds like we've reached no consensus. Dbaron, you're the final decision maker as far as I'm concerned.

Comment on attachment 153248 [details] [diff] [review] Use code similar to -moz-border-radius in nsRuleNode::ComputeOutlineData Minusing until we figure this out

OK, a 4-value -moz-outline-radius is acceptable to me.

(In reply to comment #43) > OK, a 4-value -moz-outline-radius is acceptable to me. Does this mean this implementation is now relevant again? http://bugzilla.mozilla.org/attachment.cgi?id=153248&action=view It allows -moz-outline-radius, or 4 separate values for -moz-outline-topleft, -topright, -bottomleft and -bottomright. Or is something different meant by 4-value -moz-outline-radius ?

Comment on attachment 153248 [details] [diff] [review] Use code similar to -moz-border-radius in nsRuleNode::ComputeOutlineData This patch is relevant again now that David said a "OK, a 4-value -moz-outline-radius is acceptable to me."

Comment on attachment 153248 [details] [diff] [review] Use code similar to -moz-border-radius in nsRuleNode::ComputeOutlineData I'm not a style system peer so someone else (bz, dbaron) needs to take a look. It looks right though.

Comment on attachment 153248 [details] [diff] [review] Use code similar to -moz-border-radius in nsRuleNode::ComputeOutlineData r=bzbarsky

Robert, on IRC you said we still needed to do something to nsComputedDOMStyle.cpp so that outline radius was reclected in the DOM. Does the review still apply?

Yeah. File a new bug for getComputedStyle not working on -moz-outline-radius.

Comment on attachment 153248 [details] [diff] [review] Use code similar to -moz-border-radius in nsRuleNode::ComputeOutlineData >+// -moz-border-radius: length, percent, inherit This is outline, not border >+ { // scope for compilers with broken |for| loop scoping No need for this here, since there's only one use of |side| in the function.

(In reply to comment #50) > (From update of attachment 153248 [details] [diff] [review]) > >+// -moz-border-radius: length, percent, inherit I already caught and fixed that comment > >+ { // scope for compilers with broken |for| loop scoping > > No need for this here, since there's only one use of |side| in the function. Can I have r+sr= to remove the extra { and } ?