Summary: | We should implement outline-radius: | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexander H <hmurr> | ||||||
Component: | CSS | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED WONTFIX | ||||||||
Severity: | Enhancement | CC: | abarth, adele, aldomx, bdakin, darin, eric, gustavo, hyatt, intemperie, jerome, josh, macpherson, mitz, mjs, moz, newsletters, peter, simon.fraser | ||||||
Priority: | P2 | ||||||||
Version: | 525.x (Safari 3.2) | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 20807 | ||||||||
Attachments: |
|
Description
Alexander H
2009-04-20 06:55:52 PDT
*** Bug 29988 has been marked as a duplicate of this bug. *** I agree. My alternative suggestion is to make the outline follow it's container's border-radius. That will save us a property to add and it makes sense. Created attachment 43366 [details]
draft implementation
This is my very first incursion into the inner parts of WebCore, so please be picky, and let me know of any bad decisions regarding naming, implementation, code reuse, etc. I am not sure we would want to call the property outline-radius, for instance. Should we use the '-webkit-' prefix for this?
(In reply to comment #2) > I agree. My alternative suggestion is to make the outline follow it's > container's border-radius. That will save us a property to add and it makes > sense. This makes sense to me too. Who's going to review this? Hyatt, Mitz, Simon, Beth? Can you give a link to the CSS spec for outline-radius? Thanks. (In reply to comment #6) > Can you give a link to the CSS spec for outline-radius? > Thanks. No such thing, AFAIK. This is currently only implemented in Mozilla, with the -moz- prefix, which is why I was asking about using the -webkit- prefix. Looks like they are there for a long time now: http://lists.w3.org/Archives/Public/www-style/2000Apr/0033.html Created attachment 43719 [details]
second draft
Second patch, actually drawing the rounded corners correctly, and also for inline elements, in addition to block ones.
Why do we want to implement something that isn't even proposed for CSS3? Is there a compelling use case? (In reply to comment #9) > Why do we want to implement something that isn't even proposed for CSS3? Is > there a compelling use case? The reason I started working on it was that a client wanted to use rounded outlines to mean 'this link is selected' in a webkit browser of theirs. I see value in having rounded corners for outlines, but I am not able to identify this as something authors are really missing (perhaps because outlines are not used too much either). One could fake this using SVG or even an absolute position div with a border-radius, although having webkit-outline-radius is clearly a slicker solution. Without anyone really asking for this I'm not sure we should bother with the complexity though. (In reply to comment #11) > One could fake this using SVG or even an absolute position div with a > border-radius, although having webkit-outline-radius is clearly a slicker > solution. Without anyone really asking for this I'm not sure we should bother > with the complexity though. One of the main uses of outline is for accessibility. I think it automatically discards using SVG... On the other hand, the div proposal is what seems unnecessary for me. Why adding additional markup for faking something that should be rendered by the browser? I think only few ppl thinked about it when all the border-radius fever started. I know maybe it's a pure cosmetique issue, but aren't border-radius, box-shadow, etc... the same? I think the main problem is that not much people knows how to use outline properly, and even it's a common (bad) practice to remove it, but should that move us away from doing things right? I don't think so. Hyatt and I have talked about something like this in the past. Styled form controls (like our styled pop up button) with border-radius, look pretty terrible with the default focus ring. I think a lot of peole making custom controls end up having to turn off the outline all together. (In reply to comment #13) > Hyatt and I have talked about something like this in the past. Styled form > controls (like our styled pop up button) with border-radius, look pretty > terrible with the default focus ring. I think a lot of peole making custom > controls end up having to turn off the outline all together. This case can be addressed (simply) by following the suggestion in comment #2. If we make that work even for inlines that specify border-radius (even if they don’t have a border), then I think it will also address the use case from comment #10. (In reply to comment #14) > (In reply to comment #13) > This case can be addressed (simply) by following the suggestion in comment #2. > If we make that work even for inlines that specify border-radius (even if they > don’t have a border), then I think it will also address the use case from > comment #10. I believe it would, indeed. If there's a consensus, I can try to implement that, instead. Comment on attachment 43719 [details]
second draft
Rejecting patch 43719 from commit-queue.
Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
Last 500 characters of output:
ing/style/RenderStyle.cpp
Done processing WebCore/css/CSSParser.h
Done processing WebCore/css/CSSParser.cpp
Done processing WebCore/rendering/RenderBlock.cpp
WebCore/rendering/style/RenderStyle.h:761: More than one command on the same line [whitespace/newline] [4]
Done processing WebCore/rendering/style/RenderStyle.h
Done processing WebCore/rendering/style/OutlineValue.h
Done processing WebCore/rendering/RenderObject.cpp
Done processing WebCore/rendering/RenderInline.cpp
Total errors found: 4
Comment on attachment 43719 [details]
second draft
Sorry for the bug spam. The style-queue is almost done and it's a little too comment-happy at the moment.
Attachment 43719 [details] did not pass style-queue:
Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
WebCore/css/CSSStyleSelector.cpp:4686: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5]
WebCore/css/CSSStyleSelector.cpp:4688: Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons. [readability/comparison_to_zero] [5]
WebCore/css/CSSStyleSelector.cpp:4693: A case label should not be indented, but line up with its switch statement. [whitespace/indent] [4]
Done processing WebCore/css/CSSStyleSelector.cpp
Done processing WebCore/rendering/style/RenderStyle.cpp
Done processing WebCore/css/CSSParser.h
Done processing WebCore/css/CSSParser.cpp
Done processing WebCore/rendering/RenderBlock.cpp
WebCore/rendering/style/RenderStyle.h:761: More than one command on the same line [whitespace/newline] [4]
Done processing WebCore/rendering/style/RenderStyle.h
Done processing WebCore/rendering/style/OutlineValue.h
Done processing WebCore/rendering/RenderObject.cpp
Done processing WebCore/rendering/RenderInline.cpp
Total errors found: 4
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > This case can be addressed (simply) by following the suggestion in comment #2. > > If we make that work even for inlines that specify border-radius (even if they > > don’t have a border), then I think it will also address the use case from > > comment #10. > > I believe it would, indeed. If there's a consensus, I can try to implement > that, instead. I think that sounds like the right thing to do. Therefore marking current patch r-, in favor of the alternate approach to make the outline follow border-radius. Comment on attachment 43719 [details]
second draft
r- per previous comment
Any news about this one? I'd love to see this solved :) (In reply to comment #21) > Any news about this one? I'd love to see this solved :) Same here. If it makes geometrical sense, I would love to see outline radius adjusted per border-radius as proposed in comment #21 (In reply to comment #22) > (In reply to comment #21) > > Any news about this one? I'd love to see this solved :) > > Same here. If it makes geometrical sense, I would love to see outline radius > adjusted per border-radius as proposed in comment #21 * comment #2 ! IMHO if this is implemented it would be good if what Firefox has been doing since 1.5 was followed see https://developer.mozilla.org/en/CSS/-moz-outline-radius https://bugzilla.mozilla.org/show_bug.cgi?id=593717 (In reply to comment #24) > IMHO if this is implemented it would be good if what Firefox has been doing https://bugzilla.mozilla.org/show_bug.cgi?id=593717 "remove -moz-outline-radius and make outlines follow border-radius" Sorry for the spam, I was just trying to add myself to the CC List to get notified about the progress of this bug, but I couldn't find a save button (like mozilla's bug tracker), a subscribe button or something similar. Marking resolved / wontfix because I believe this bug is obsolete. This bug still occurs, is it really obsolete? > This bug still occurs, is it really obsolete? it is obsolete, see comment 19. The real bug is: "outline should follow border-radius". I don't see this bug filed, but it's basically bug 20807 |