Closed Bug 531818 Opened 15 years ago Closed 15 years ago

If an <a> tag surrounds an <img> then <a>.getBoundingClientRect() ignores <img> height

Categories

(Core :: DOM: CSS Object Model, defect)

Product:
Core
Component:
DOM: CSS Object Model
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: miker, Unassigned)

Details

(Whiteboard: [firebug-p2])

Attachments

(1 file)

Test Case
567 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)

If an <a> tag surrounds an <img> then <a>.getBoundingClientRect() ignores <img> height.


Reproducible: Always

Steps to Reproduce:
The following code illustrates the problem:
<html>
<head>
    <script>
        function doit() {
            var el = document.getElementById('testlink'),
                rect = el.getBoundingClientRect();
                
            alert(rect.width + ' x ' + rect.height + ' ... result should be 267 x 110');
        }
    </script>
</head>
<body onload="doit();">
    <a id="testlink" href="http://www.google.com">
        <img src="http://www.google.com/logos/logo.gif" style="width:276px;height:110px;border:0;" />
    </a>
</body>
</html>
Actual Results:  
The height of the <a> tag does not match the <img> tag

Expected Results:  
The height of the <a> tag should match the <img> tag

This is related to a Firebug issue:
http://code.google.com/p/fbug/issues/detail?id=2534
Component: General → DOM: CSS Object Model
Product: Firefox → Core
QA Contact: general → general
Boris, I cc-ed you in case this bug can have impacts beyond Firebug.
Whiteboard: [firebug-p2]
This is the right behavior.  getBoundingClientRect returns the size of the bounding client rect of the CSS boxes for the element.  It does NOT include the overflow.  Put a background on the <a> in this case (and make the image "visibility:hidden" or transparent or whatever) to see what the boxes for the <a> look like.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Note that depending on how the highlighting is supposed to work in Firebug the Firebug bug cited in comment 0 may be invalid too.  I know what _I'd_ want out of highlighting in that case is to not include the full extent of the <img>, if I'm selecting the <a>.
(In reply to comment #4)
> Note that depending on how the highlighting is supposed to work in Firebug the
> Firebug bug cited in comment 0 may be invalid too.  I know what _I'd_ want out
> of highlighting in that case is to not include the full extent of the <img>, if
> I'm selecting the <a>.

Maybe this is a difference between what Firebug users expect inspect to do and what getBoundingClientRect() provides.

I would expect that when I select the <a> in Firebug's HTML view, then Firebug will highlight the area of page where the <a> tag is active. I want that as a Firebug user to visually verify the maximum extent of my link. Then I can use the mouse on the page to look at details of the link extent.  The current result makes no sense and has no value to me: it only causes me to think Firebug or Firefox has a bug because the area highlighted for the <a> tag is too short or at least too low on the page.
> then Firebug will highlight the area of page where the <a> tag is active.

This is, generally speaking, not a rectangle at all.  Heck, it's not in this testcase... or in this one:

  This is <a href="something">Some<br>
  text</a>

If the "where is the <a> active?" thing is really what you want, you probably want to take the union of all client rects (_not_ bounding client rects!) for all the DOM descendants of the <a>, not its bounding client rect at all.

As I said, what I generally want out of highlight functionality (and what DOM inspector provided) is some idea of what the layout boxes for the element look like.

Let's put this another way.  If <a> is replaced by a <span>, would you expect the highlight area to change?  If so, why?  If not, why does what you describe for <a> make sense for <span>?

In any case, none of that has to do with getBoundingClientRect directly...  Should probably move that to the Firebug bug.
You might also want to look at bug 202942, fwiw.
(In reply to comment #6)
...
> 
> As I said, what I generally want out of highlight functionality (and what DOM
> inspector provided) is some idea of what the layout boxes for the element look
> like.
> 
> Let's put this another way.  If <a> is replaced by a <span>, would you expect
> the highlight area to change? 

Yes.

> If so, why?  

Because I think of <a> as containing anything while I think of <span> as a text enclosing thing that an <img> would spill out of.  I guess this is also true for the other folks here.

> If not, why does what you describe
> for <a> make sense for <span>?

Sounds like the common sense ideas of <a> does not match its actual character as a span-like thing.

> 
> In any case, none of that has to do with getBoundingClientRect directly... 
> Should probably move that to the Firebug bug.

Evidently. Though we don't know what to do now, other than repeatedly explain this to users.
(In reply to comment #8)
> Because I think of <a> as containing anything while I think of <span> as a text
> enclosing thing that an <img> would spill out of.

Ah, and from a DOM/CSS standpoint they're completely identical.

> I guess this is also true for the other folks here.

Which other folks?  It wasn't obvious to me that the bug report here was <a>-specific, nor that the Firebug bug was....

> Sounds like the common sense ideas of <a> does not match its actual character
> as a span-like thing.

For some values of "common sense", that's possible.

> Evidently. Though we don't know what to do now, other than repeatedly explain
> this to users.

If you really think the behavior for <a> should be completely different from everything else (which I would find confusing, myself, but maybe that's ok) then you could always special-case <a> and do something different for it, right?
(In reply to comment #9)
> (In reply to comment #8)
> > Because I think of <a> as containing anything while I think of <span> as a text
> > enclosing thing that an <img> would spill out of.
> 
> Ah, and from a DOM/CSS standpoint they're completely identical.

Which is news to me...

> 
> > I guess this is also true for the other folks here.
> 
> Which other folks?  It wasn't obvious to me that the bug report here was
> <a>-specific, nor that the Firebug bug was....

Right, because you knew that <a> and <span> are similar. Other folks, including me, the reporter on the firebug bug, and Radcliffe thought this was <a>-specific because we did not expect that <a> and <span> where similar. We don't use <a> and <span> in similar ways. I bet this is a surprise to most web devs.

...
> > Evidently. Though we don't know what to do now, other than repeatedly explain
> > this to users.
> 
> If you really think the behavior for <a> should be completely different from
> everything else (which I would find confusing, myself, but maybe that's ok)
> then you could always special-case <a> and do something different for it,
> right?

As far as Firebug inspect goes, we cannot change it. It is doing the right thing here, even if we are surprised. If we want a "link area debugging tool", then we need to create one.
It seems to me that when you want to visualize the layout of an element, you should use getClientRects on the element. When you want to visualize event targeting, you should use something else --- I think it would be enough to collect up all the getClientRects of the element and all its descendants, include text node descendants. Text nodes don't support getClientRects, but you can create a Range covering the text node and call getClientRects on that. But if you want to include all the anonymous stuff, or be fast, we might need to create a new inspector API for this.

Maybe the thing to do would be to show the layout area and the event targeting area at the same time, e.g. boxes for the layout area and a translucent overlay for the event targeting area.
(In reply to comment #11)
> It seems to me that when you want to visualize the layout of an element, you
> should use getClientRects on the element. 

Now here do you mean the union of getClientRects() or the result of getBoundingClientRects()? (we can cover this in the newsgroup see below).

> When you want to visualize event
> targeting, you should use something else --- I think it would be enough to
> collect up all the getClientRects of the element and all its descendants,
> include text node descendants. Text nodes don't support getClientRects, but you
> can create a Range covering the text node and call getClientRects on that. But
> if you want to include all the anonymous stuff, or be fast, we might need to
> create a new inspector API for this.

The Firebug inspect needs interactive speeds.

> 
> Maybe the thing to do would be to show the layout area and the event targeting
> area at the same time, e.g. boxes for the layout area and a translucent overlay
> for the event targeting area.

Yes, that sounds like it would be the right direction. 

I will ask about this on the layout newsgroup.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: