Closed Bug 228051 Opened 16 years ago Closed 16 years ago

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

Categories

(Core :: Layout, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 184155

People

(Reporter: jshin1987, Unassigned)

Details

Attachments

(1 file)

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.
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Needless to say, XHTML is rendered in standards mode.
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
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: xhtml file embedded with <object> tag is rendered differently depending on the type of an 'embedding' (parent) file → xhtml file embedded with <object> tag is rendered with a scroll bar even when 'height' is not specified.
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
'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.
Also, there is no concept of vertical "currently available space" in HTML/CSS
layout.

I don't see why this isn't invalid.
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → INVALID
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.)
try this with MS IE and Opera as well as with Mozilla
Could you point me to the part of the CSS spec that mentions available space?
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.




> 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.
> 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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

*** This bug has been marked as a duplicate of 184155 ***
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → DUPLICATE
> 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.
> 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 ;-)

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.
Product: Core → Core Graveyard
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.