Last Comment Bug 133165 - outline doesn't include larger descendants of inline elements
: outline doesn't include larger descendants of inline elements
Status: RESOLVED FIXED
[Hixie-P3]
: css-moz, css2, testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P4 minor with 3 votes (vote)
: Future
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
: Hixie (not reading bugmail)
Mentors:
http://www.kaply.com/work/bugzilla/13...
: 16051 58456 67966 122232 149695 161237 253593 256259 (view as bug list)
Depends on:
Blocks: css2outline 29566
  Show dependency treegraph
 
Reported: 2002-03-24 15:04 PST by reid
Modified: 2014-04-26 03:30 PDT (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Image showing image in page being cut in half by box (6.09 KB, image/png)
2002-03-24 15:11 PST, reid
no flags Details
testcase (215 bytes, text/html)
2004-04-10 01:19 PDT, Sekundes
no flags Details
fix (8.92 KB, patch)
2004-07-31 18:19 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
dbaron: review-
dbaron: superreview-
Details | Diff | Splinter Review
revised patch (19.10 KB, patch)
2004-08-10 21:39 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
dbaron: review+
dbaron: superreview+
Details | Diff | Splinter Review
Jeffrey Zeldman testcase (659 bytes, text/html)
2004-09-17 02:29 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details

Description reid 2002-03-24 15:04:32 PST
Awhile ago, I found the following somewhere and added it to my userContent.css file:

a:link:hover {
  -moz-outline: 1px dotted blue;
}

It puts a dotted box around links the pointer is hovering over.  In some cases,
the box drawn around the links is the wrong size, though.  This can often happen
with a large image, for example, in which case the box might only draw from the
bottom to halfway up the image, cutting it in half.

I'll try to attach an image showing the problem.

Using nightly from 20020324.
Comment 1 reid 2002-03-24 15:11:31 PST
Created attachment 75885 [details]
Image showing image in page being cut in half by box

The image shows a portion of my Yahoo home page.  The pointer was on the "My
Yahoo" link, so the box was drawn around the image, but it cuts the image in
half vertically.
Comment 2 Christopher Hoess (gone) 2002-03-24 21:45:34 PST
->Style system
Comment 3 Hixie (not reading bugmail) 2002-03-25 15:14:02 PST
this is probably a dup, there are various outline bugs already
Comment 4 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-04-22 20:09:42 PDT
Believe it or not, I don't think we have another bug on this.  Technically the
current behavior is OK, but it's not preferable, and I know I've commented at
length somewhere about how we should be doing this.  I just can't find it.
Comment 5 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-07 13:18:15 PDT
*** Bug 149695 has been marked as a duplicate of this bug. ***
Comment 6 Mike Kaply [:mkaply] 2002-06-07 13:22:15 PDT
This has become a pretty big issue for one of our customers, as it affects focus 
rectangles, which are a pretty big deal.

Can anyone give me a suggestion as to what to look at for this?

We are definitely doing the WRONG thing here.
Comment 7 Eric A. Meyer (dead account) 2002-06-07 13:27:14 PDT
According to the CSS working group, we're doing the RIGHT thing here under CSS2.
 We may not like it, but that's what they've reaffirmed every time I've pushed
on the point (which has been more than once).  No other browser does it, but
according to the WG those browsers are wrong and Mozilla is not.  Hopefully
David can find his lenghty explanation, because I'd like to see it...
Comment 8 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-07 13:31:15 PDT
No, the spec is vaguer about 'outline' than it is for other things.  This is
vaguely related to bug 16051.  See the first paragraph of:

http://www.w3.org/TR/REC-CSS2/ui.html#dynamic-outlines

Some discussions of the topic are at:
http://lists.w3.org/Archives/Public/www-style/1999Jul/0020.html
and the thread following it.  My proposed algorithm was in
http://lists.w3.org/Archives/Public/www-style/1999Jul/0039.html
Comment 10 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-07 13:38:39 PDT
The n.p.m.layout post I mentioned was
http://groups.google.com/groups?selm=slrn7o8b3v.l4s.dbaron%40ice1.fas.harvard.edu
from which you can get to the rest of the thread.
Comment 11 Mike Kaply [:mkaply] 2002-06-07 14:57:24 PDT
I'm confused. I read all these, and I see nothing that indicates that 
we are doing it " correctly" 

The anchor is the entire image, so if the image has focus, the focus 
rectangle should be around the entire image.

What exactly is the motivation for not putting the focus rect around 
the entire image? I don't understand.
Comment 12 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-07 15:01:54 PDT
"the anchor is the entire image" doesn't make sense -- the anchor has a box, and
we're drawing the outline around that box.

Nevertheless, the spec allows us to do something more creative.
Comment 13 Mike Kaply [:mkaply] 2002-06-07 15:31:23 PDT
> the anchor has a box, and
> we're drawing the outline around that box.

OK, now I am really confused.

When an image is an anchor, I can click anywhere on that image to 
execute the anchor. So I would assume that the anchor consists of the 
entire image.

What we are actually drawing a line around, I have no clue. If you tab 
through the images at:

http://www.kaply.com/work/imgfocus.html

you will see that the focus outlines around those images (representing 
the anchors) seems actually rather random. I can see that sometimes it 
could theoretically be the height of the line, but in some cases, it 
is drawing a box around part of the image that does NOT overlap the 
text rectangle. In some other cases, we just lose the bottom.

Should we be using something other than moz-outline for focus 
rectangles?
Comment 14 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-07 15:44:28 PDT
> When an image is an anchor, I can click anywhere on that image to 
> execute the anchor. So I would assume that the anchor consists of the 
> entire image.

The anchor is the content tree parent of the image, so it gets a chance to
handle the event from the click on the image, even if that click is outside the
bounds of the anchor.
Comment 15 Mike Kaply [:mkaply] 2002-06-07 22:28:11 PDT
So do you believe there is a problem here to be fixed?

Or do you believe that focus rectangles on images should just continue to look
like crap?
Comment 16 Hixie (not reading bugmail) 2002-06-08 05:28:14 PDT
This issue is one of the reasons it's called '-moz-outline' and not 'outline'.
So yes, on the long run, I'd think we want to fix it to be nicer.
Comment 17 Mike Kaply [:mkaply] 2002-06-08 06:49:03 PDT
> So yes, on the long run, I'd think we want to fix it to be nicer.

OK, so back to my original question. I have a customer who is refusing to roll 
out the browser because of this problem. It makes tab navigation of their 
intranet look horrible.

Big customer. Huge customer. Largest bank on the planet.

So I would like to make an attempt to fix it.

Any ideas?
Comment 18 Hixie (not reading bugmail) 2002-06-08 07:51:52 PDT
Tell them to stick

   /* remove Mozilla's focus rings for links */
   :-moz-any-link:focus { -moz-outline: none; }

...in their site stylesheet.
Comment 19 Mike Kaply [:mkaply] 2002-06-08 09:56:46 PDT
Doesn't that give them no focus rings?

That breaks accessibility. They want focus and they want it to look correct.
Comment 20 Eric A. Meyer (dead account) 2002-06-08 10:13:30 PDT
Try adding this after Ian's suggested rule:

   a:focus img {-moz-outline: 1px dotted red;}

...or whatever outline styles you prefer.  That ought to outline the image
itself while not outlining the link itself.
Comment 21 Hixie (not reading bugmail) 2002-06-08 11:15:33 PDT
Sorry, I didn't read your original post. If the problem is specifically with
links containing images then yes, they need merely add specific rules for those,
such as:

   /* add focus rings for images inside links */
   :-moz-any-link:focus > img { -moz-outline: inherit; }

However, the best solution would be for us to fix out 'outline' support.
Comment 22 Mike Kaply [:mkaply] 2002-06-08 22:00:31 PDT
I love you guys. These workarounds look great for now.

Thank you thank you a million times thank you.
Comment 23 Mike Kaply [:mkaply] 2002-06-09 06:52:47 PDT
OK, this is strange. I think I can get this workable, but I thought I might let 
you know results so you can can give some advice.

This line:

:-moz-any-link:focus { -moz-outline: none; }

Removes focus from everything, except images! But now images get the TOTALLY 
correct focus outline (not the messed up one)

This line:

:-moz-any-link:focus > img { -moz-outline: none; }

Causes images to not have messed up focus lines, but the focus they have is just 
a focus box around where text would be in the image, not the entire image as 
happened with removing focus for everything.

So it appears that the reason focus around images draws incorrect is because it 
is the intersection of two focus boxes!!!!

So the question is, is there anyway to get the results of the first one (correct 
image boxes around images) without getting rid of all focus.

What I am wondering is if there is something besides :focus that draws the box 
around images since that didn't disappear when focus was set to none.

BTW, I was using userContent.css to modify this.

This is AWESOME stuff. I'm going to learn lots more about this subject. Thanks!
Comment 24 Hixie (not reading bugmail) 2002-06-09 10:24:19 PDT
> This line:
>
>   :-moz-any-link:focus { -moz-outline: none; }
>
> Removes focus from everything, except images!

To be precise, it prevents any links (<a href> elements, <link> elements, and
XLink elements) from having outlines while they are focussed.


> But now images get the TOTALLY correct focus outline (not the messed up one)

The images still get the focus rings because of the following rule in html.css:

 *|*:-moz-any-link:focus img { -moz-outline: 1px dotted invert; }


> This line:
>
>   :-moz-any-link:focus > img { -moz-outline: none; }
>
> Causes images to not have messed up focus lines

Specifically, it cancels the rule from html.css quoted above, i.e. it removes
the outline from around <img> elements that are immediately within <a href>,
<link> or XLink elements that have the focus.


> but the focus they have is just a focus box around where text would be in the 
> image, not the entire image as happened with removing focus for everything.

In fact, it is the outline you get from just the <a href> element, and has
nothing to do with the image itself.


> So it appears that the reason focus around images draws incorrect is because 
> it is the intersection of two focus boxes!!!!

The reason the focus draws incorrectly is that the outline drawing code does not
take the descendent nodes into account. (This bug.)


> So the question is, is there anyway to get the results of the first one 
> (correct image boxes around images) without getting rid of all focus.

No, because CSS has no way of selecting elements based on their contents.
However, if you the author marks the links from which he wishes to remove the
outline, e.g. with a class:

   <a href="..." class="imglink"><img src="..." alt="..."></a>

...then the following CSS would achieve what you want:

   *|*:-moz-any-link.imglink:focus { -moz-outline: none; }
   *|*:-moz-any-link.imglink:focus img { -moz-outline: 1px dotted invert; }


> What I am wondering is if there is something besides :focus that draws the box 
> around images since that didn't disappear when focus was set to none.

There are many bugs in the outline drawing code, one of which is that outlines
are not always correctly removed. This is one of the many reasons why 'outline'
is currently called '-moz-outline' in Mozilla.
Comment 25 Eric A. Meyer (dead account) 2002-06-10 13:58:54 PDT
>However, the best solution would be for us to fix out 'outline' support.

I still don't understand how we can "fix" our outline support without changing
the place borders are drawn.  CSS2 clearly states that outlines are drawn just
outside the border edge (section 18.4), so outline shoudl effectively do the
same things borders do-- there may be a pixel's difference in placement, but
that's it.  Unless we change our border placement so it encompasses larger
descendant elements, outlines won't encompass them either.  Did I miss some
nifty way to justify ignoring this part of CSS2?  Or were you actually talking
about "fixing" out '-moz-outline' support?
Comment 26 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-10 14:05:04 PDT
"The outline is drawn starting just outside the border edge.

Outlines may be non-rectangular. For example, if the element is broken across
several lines, the outline is the minimum outline that encloses all the
element's boxes. In contrast to borders, the outline is not open at the line
box's end or start, but is always fully connected." (CSS2 18.4)

The second paragraph is more specific than the first.

Comment 27 Hixie (not reading bugmail) 2002-06-10 15:14:33 PDT
Right; CSS2 is merely saying that the outline shouldn't be inside the border
edge. Maybe that should be made clearer in a revision of the spec.
Comment 28 Eric A. Meyer (dead account) 2002-06-10 15:21:05 PDT
David, I disagree that what you've quoted (comment 26) covers the case of making
an outline encompass large descendant elements of inline elements in a
non-wrapped line-- or, if you prefer, non-wrapped inline elements-- which this
bug concerns.  I also think you're stretching that second paragraph awfully thin
to get it to cover what you seem to want outlines to do, but borders not to do
(for reasons that continue to elude me).  How would you suggest the outline
should be drawn in this situation:

   <a href="blah" style="font-size: 10px">a heart <img src="heart"
style="height: 20px;"> to you</a>
Comment 29 Hixie (not reading bugmail) 2002-06-11 11:45:33 PDT
like in IE:
          ........
          : _  _ :
          :( `' ):
  ........: \  / :.......
  :a heart   \/   to you:
  '''''''''''''''''''''''

Note that CSS3 now has a property to control where the border is drawn (but it
is always rectangular).

If it is not clear that the above is allowed per the spec, then we should take
this opportunity to clarify this issue.
Comment 30 Jesse Ruderman 2002-06-12 14:37:41 PDT
*** Bug 58456 has been marked as a duplicate of this bug. ***
Comment 31 Jesse Ruderman 2002-06-12 14:52:57 PDT
*** Bug 67966 has been marked as a duplicate of this bug. ***
Comment 32 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-06-22 15:42:25 PDT
*** Bug 122232 has been marked as a duplicate of this bug. ***
Comment 33 Greg K. 2002-07-14 11:25:21 PDT
Reconfirmed using FizzillaCFM/2002071208. Using Michael's testcase, tabbing
through the images results in oddly shaped focus rectangles. Setting All/All.
Comment 34 Kai Lahmann (is there, where MNG is) 2002-08-06 02:17:21 PDT
*** Bug 161237 has been marked as a duplicate of this bug. ***
Comment 35 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-08-18 04:58:58 PDT
*** Bug 16051 has been marked as a duplicate of this bug. ***
Comment 36 rnorberg 2003-02-18 15:03:39 PST
fails on 2003021808 win 2k
Is there any movement on this bug?
Comment 37 Sekundes 2004-04-10 01:19:52 PDT
Created attachment 145796 [details]
testcase
Comment 38 Sekundes 2004-04-10 01:28:29 PDT
note: the current useragent implementations, Opera 7.50 TP 3 and Safari 1.2, 
also have the same bug.
Comment 39 Boris Zbarsky [:bz] 2004-07-29 17:55:11 PDT
*** Bug 253593 has been marked as a duplicate of this bug. ***
Comment 40 Aaron Leventhal 2004-07-29 18:23:46 PDT
Although bug 253593 was marked a DUP of this, it's only recently since bug
151375 has been fixed that foucs outlines on image links have started showing a
problem.
Comment 41 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-07-29 20:01:18 PDT
CSS 2.1 says simply that the outline "may be drawn starting just outside the
border edge".

It also says "In contrast to borders, the outline is not open at the line box's
end or start, but is always fully connected if possible." It's not always
reasonable to do that; consider an outlined inline span that starts at the
bottom of one column and continues at the top of the next column.

A quick fix to this immediate problem would be draw outlines around the
*overflow area* of each frame associated with the content. Let me whip up a
patch for that and interested people can try it out and see how they like the
results.

See also bug 24676 for some thoughts about painting outlines. The algorithm I
suggest in bug 24676 comment 36 is compatible with my idea in the previous
paragraph.
Comment 42 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-07-31 18:18:06 PDT
This patch extends the outline to the exterior of the frame's overflow area, as
described. Seems to work pretty well.
Comment 43 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-07-31 18:19:28 PDT
Created attachment 154890 [details] [diff] [review]
fix

Hmm, what happened to the patch?
Comment 44 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-07-31 18:21:03 PDT
Comment on attachment 154890 [details] [diff] [review]
fix

David, apart from looking at the actual code, I'd appreciate your thoughts
about whether this is the right thing to do at all.
Comment 45 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2004-08-10 17:01:08 PDT
Shouldn't the fallback behavior in nsIFrame::GetOutlineRect inflate by the
outline width?  Also, I'm not happy about the discontinuity -- when the outline
width changes from 0 to 0.1px, GetOutlineRect changes from the rect to the
overflow area.  That seems like a possible cause for hidden bugs.
Comment 46 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-08-10 21:39:29 PDT
Created attachment 155773 [details] [diff] [review]
revised patch

OK, this patch addresses those comments. Basically users of GetOutlineRect
should just do GetOverflowRect which always gets the frame's overflow area (or
the frame's size if the frame has no overflow).

This might actually let us simplify the frame invalidation code in response to
style changes in nsCSSFrameConstructor, but we don't need to do that here.
Comment 47 David Brittain 2004-08-17 00:12:57 PDT
I've set the blocking-aviary1.0PR? flag because a recent regression in drawing
of outlines are being duped against this bug. This is a regression since firefox
0.9.
Comment 48 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-08-17 06:38:24 PDT
That regression was only on the trunk, not on the Aviary branch, so it did not
affect Firefox 0.9-1.0.
Comment 49 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2004-08-22 19:38:17 PDT
Comment on attachment 155773 [details] [diff] [review]
revised patch

I'm not sure I understand what's making the outline be painted outside of the
overflow area rather than inside it -- although I guess that's the overflow
area computation code somewhere.  But does that code only inflate for the
outline around the frame, or around the whole overflow?
Comment 50 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-08-23 10:24:30 PDT
nsIFrame::FinishAndStoreOverflow gets called after Reflow has computed
nsHTMLReflowMetrics::mOverflowArea, which is the union of the overflow areas of
all child frames plus the content area of the current frame.
FinishAndStoreOverflow expands that rectangle with this frame's outline (that
calculation is performed by ComputeOutlineRect). The result is stored as the
frame's new overflow area. nsCSSRendering::PaintOutline paints the outline, if
there is one, on the inside of the frame's overflow area; that is always correct.
Comment 51 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-08-25 18:00:42 PDT
checked in.
Comment 52 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-09-17 02:29:29 PDT
Created attachment 159186 [details]
Jeffrey Zeldman testcase

I think the fixing of this bug causes a bit weird focus rings on
http://www.zeldman.com
Try focusing the top links: "the daily report", "designing with web standards",
etc.

He used a (popular css) technique to hide the original text and instead only
showing the background-image: text-indent: -9999px;
But now Mozilla is drawing the focus rectangle also around the weird
text-indented text.

I'm not sure this is a bug, in fact. But you might want to know this behavior
has changed. 
By the way, IE6 isn't including the text-indented text in the focus rectangle
box.
Comment 53 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2004-09-17 05:16:05 PDT
Interesting. I'm not sure what to do about this.
Comment 54 Hixie (not reading bugmail) 2004-09-18 03:53:50 PDT
Not a bug IMHO, although maybe we should split the outline into two boxes in 
cases like these.

(I've long thought the text-indent: -1000px hack to be pretty bogus, btw.)
Comment 55 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-09-18 04:09:43 PDT
Yes, sorry, for what it's worth, I too don't think anymore this is a bug in
Mozilla. It's actually better.
The text-indent: -1000px css hack is probably just something temporary which
will be replaced when browser support is there for color:transparent or similar
less hacky than text-indent: -1000px.
Comment 56 Anne (:annevk) 2004-09-18 05:11:15 PDT
Actually, people are waiting for bug 215083 to be supported. This is a
workaround for that. (The problem is that 'content' used in that way is a CSS3
property which is not yet in CR.)
Comment 57 Aaron Leventhal 2004-09-22 11:16:05 PDT
*** Bug 256259 has been marked as a duplicate of this bug. ***
Comment 58 gabe 2005-10-11 11:54:16 PDT
thisbug is back
Comment 59 Phil Baines 2005-12-01 05:40:56 PST
Referring to Jeffrey Zeldmans test case; Surly this IS a bug! When the outline is applied to an anchor that is in focus surly it is meant to represent the CLICKABLE area of that anchor? 

This bug means that the outline surrounds much more (or less in some cases) than the clickable area. The negative indented text is not part of the clickable area.  Users will expect it to be representative of the clickable area, and so this will lead to confusion in the Firefox user. This is just common sense.
Comment 60 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-12-01 06:15:54 PST
(In reply to comment #59)
> The negative indented text is not part of the
> clickable area.
Actually, it is.
See the "Jeffrey Zeldman testcase". The negative indented text can be clicked upon (also in Opera9. For some reason, IE6 doesn't show the text).
Comment 61 Phil Baines 2005-12-01 08:24:58 PST
Martijn, that's a fair comment and I admit that I hadn't noticed that. But I still stand by my point because the WHOLE area that gets outlined is not clickable. The text is, sure, but the area between the text and the position of the anchor is not clickable. 

So I would suggest that the solution to be aimed for is probably to have the two separate clickable areas outlined separately. This would solve the problem with websites that use the negative indent to hide text since the outline surrounding the text would also be hidden. 

Thanks though for pointing that out to me! 

Note You need to log in before you can comment on or make changes to this bug.