228051 - xhtml file embedded with <object> tag is rendered with a scroll bar even when 'height' is not specified.

Status: RESOLVED DUPLICATE of bug 184155

(Core :: Layout, defect)

Description

[Jungshik Shin]

Richard Ishida of W3C recently found this. 

When an xhtml file is embedded in an xhtml file using <object>, Mozilla treats 
as if it's embedded with <iframe> and a scroll bar is generated with the content 
of the embedded xhtml file rendered inside a frame too small to contain the 
whole content of the file. 

When the same xhtml file is embedded in a html 4.0x file using <object>, Mozilla 
doesn't make a frame and just puts the content of the embedded file.

An example :

http://www.w3.org/International/tests/bidi-blocks2-sec.html
is an html wrapper that includes 
 http://www.w3.org/International/tests/bidi-blocks2.html using 'object'.

Now I'm gonna upload an xhtml wrapper that includes the same file with 'object' 
and you'll see the difference.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Any time a document type we render natively is included with <object> we create
an iframe.  So the only question is that of scrollbars, no?

Note that http://www.w3.org/International/tests/bidi-blocks2-sec.html is
rendered in quirks mode.  That means that we treat the 100% height on the
<object> in that file quirkily -- we actually walk up the parent chain looking
for something to size based on.

If the same document is simply changed to a HTML 4.01 strict doctype, we would
treat that height as "auto", as we should (and it would end up being 200px or
something).

For that matter, even changing from 4.0 Transitional to 4.01 Transitional would
trigger standards mode and change the rendering.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Needless to say, XHTML is rendered in standards mode.

Comment 3

[Jungshik Shin]

Thanks. without reading the source, I assumed Richard's html wrapper is also an
instance of HTML 4.01 strict (i.e. it'd be rendered in standards mode) so that I
couldn't find any reason why it's rendered differently from his xhtml wrapper. 

Anyway, is there any standard-compliant way to remove that scrollbar and to get
the embedded document take its 'full height'? Apparently, not specifying weight
and height should make Mozilla use the embedded object's 'natural' height and
width. [1] In case of an  html document, what's its natural height? I can't come
up with anything better than its height when it's rendered as if it were inline.
I removed 'height' (and 'width') from <object> tag, but that doesn't make any
difference. Mozilla still put the embedded document in an iframe (which is fine)
of about 200 pixel high with the scrollbar (which is not expected) 

[1] http://www.w3.org/TR/html4/struct/objects.html#h-13.7

Comment 4

[Jungshik Shin]

Not specifying 'height' means that Mozilla has to use 'auto',  right? Then, the
question is why 'auto' ends up being only '200 px' even when the
natural/intrinsic height of the embedded document (anything included with
<object> is a 'replaced element', isn't it? [1]) is larger than 200 px.

As for height=100%, it's relative to the currently available space, isn't it?
Then, why is it 
 '~ 200 px' when the height of the available space is smaller or larger than
that. I'm wondering where '~ 200 px' comes from.

[1]   http://www.w3.org/TR/CSS1#replaced-element
     http://www.w3.org/TR/CSS2#Computing_heights_and_margins
     http://www.w3.org/TR/CSS2/conform.html#replaced-element

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

'auto' ends up as 200px because that's what IE/Windows does, we'd break a bunch
of web pages if we did anything else, and nobody seems to have any better ideas.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also, there is no concept of vertical "currently available space" in HTML/CSS
layout.

I don't see why this isn't invalid.

Comment 7

[Jungshik Shin]

The available space part is not so releavant any way when we deal with 'auto'.
It's only relevant when the height is specified in %. So, the question boils
down to why 'auto' doesn't mean  the intrinsic/natural height of a replaced
element.  'auto' is supposed to take 'the intrinsic height' of a replaced
element, isn't it? What's your interpretation of CSS1 / CSS2 provisions I
refered to in comment #4? 

As for MSIE parity, Mozilla has to be changed if that's that much important.
Exactly the same xhtml file is rendered WITHOUT the scrollbar in both MS IE and
Opera. That is, both MS IE and Opera render  identically whether it's xhtml or
html that includes an xhtml file with 'object'. The following is how Richard
Ishida described it:

Btw, the actual tests pages (eg.
http://www.w3.org/International/tests/bidi-blocks2-sec.html) are in fact
an HTML wrapper page that pulls in an XHTML test page using the <object>
tag.  I would have prefered to have had both files in XHTML, but I found
that the included file doesn't fill the available space in Firebird if
you don't have an HTML wrapper.  (You get a scrollable view about 5/6
lines deep.)

Comment 8

[Jungshik Shin]

Attachment: xhtml wrapper pulling in an xhtml file with object (height not specified)

try this with MS IE and Opera as well as with Mozilla

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could you point me to the part of the CSS spec that mentions available space?

Comment 10

[Jungshik Shin]

I thought I made it clear that this is not so much about the available space as
about the intrinsic height of an embedded html/xhtml file. 

Replaced element is defined in
http://www.w3.org/TR/CSS2/conform.html#replaced-element

And, as for computing the height, see
http://www.w3.org/TR/CSS2/visudet.html#Computing_heights_and_margins

Do you agree that 'object' is a relaced element and that there's a reliable way
to determine the 'intrinsic' height of an html document?  The latter is
certainly debatable, but if not intrinsic, we still can determine 'a' 'natural'
height, can't we? However arbitray that 'natural' height might be, it doesn't
look like it's  gonna  be any more arbitrary than 200pixel.


Anyway, 'the available space' is mentioned in html 4 13.7.1 (referred to in
comment #3):

http://www.w3.org/TR/html4/struct/objects.html#h-13.7.1

html4> Note that lengths expressed as percentages are based on the horizontal or 
html4> vertical space currently available, not on the natural size of the image,
object, or html4> applet.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Anyway, is there any standard-compliant way to remove that scrollbar 

Yes, set 100% heights on all ancestors of that <object>.

> As for MSIE parity

We need IE parity IN QUIRKS MODE.  If IE's buggy in standards mode, that's its
problem, not ours.

> Do you agree that 'object' is a relaced element

Yes.

> and that there's a reliable way to determine the 'intrinsic' height of an html
> document?

Not really... (for example, what happens to positioned content?)

> Anyway, 'the available space' is mentioned in html 4 13.7.1

Frankly, what ever HTML has to say about layout is pretty irrelevant to the way
we render.

In any case, see bug 184155 for where this discussion has gone.  As originally
filed, this bug is invalid, since our rendering is in fact compliant with CSS2.

Comment 12

[Jungshik Shin]

> We need IE parity IN QUIRKS MODE.  If IE's buggy in standards mode, that's 
> its problem, not ours.

  It's not I but dbaron who cited MS IE pairty as a basis for using that magical
200pixel in _standard_ modes (for bout 'height=auto' and 'height=100%').

>> and that there's a reliable way to determine the 'intrinsic' height of an html
>> document?

> Not really... (for example, what happens to positioned content?)

  So, using 200pixel is as compliant to CSS2 as using any arbitray height? If
that's the case, why don't we try to do a bit better than that? OK, that's bug
184155.

> Frankly, what ever HTML has to say about layout is pretty irrelevant to the way
> we render.

   Maybe so, but please tell me why 200pixel is more compliant to CSS than what
most authors 'intuitively' expect agents to do. 

> As originally filed, this bug is invalid, 

  As originally filed, invalid. fine. But, I changed it when reopening. This
should have been made a dupe of bug 184155 at that point.

Comment 13

[Jungshik Shin]

*** This bug has been marked as a duplicate of 184155 ***

Comment 14

[Boris Zbarsky [:bzbarsky]]

> It's not I but dbaron who cited MS IE pairty as a basis for using that magical
> 200pixel

The 200px is needed for auto-height in quirks _and_ standards mode for IE compat
(eg <iframe> with no height set; try what IE does with that in its various
modes).  It's needed more in quirks mode, of course, but there is no good
justification for having the intrinsic height be different in the different modes.

> but please tell me why 200pixel is more compliant

It's not.  It's exactly as compliant as any other number we pull out of out
butts.  The only constraint is that an object with no height set must behave
exactly like a 100% height object in the provided testcase.

> most authors 'intuitively' expect agents to do. 

Authors "intuitively" expect an <iframe> with no height set to be 200px tall,
actually.  And all of standards mode is about what authors _don't_ expect,
thanks to the many IE bugs in CSS rendering.

Comment 15

[Jungshik Shin]

> Authors "intuitively" expect an <iframe> with no height set to be 200px tall,
actually. 
  
Are you serious about this? At least, I and Richard don't. Maybe, we just belong
to the minority ;-)

Comment 16

[Boris Zbarsky [:bzbarsky]]

Perhaps I should correct that.... "Authors intuitively expect all browsers to
render just like IE does."  That statement is true of the vast majority of all
web authors, unfortunately.