184155 - OBJECT embedded HTML should get dynamic intrinsic size

Status: NEW

(Core :: Layout, defect)

Description

[Stanimir Stamenkov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021206
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021206

This is somewhat relevant to Bug 70976 but since HTML is handled internally I
thought this is a different issue.

If I embed a HTML document in another HTML one using the OBJECT tag without
specifying explicit dimensions for the OBJECT element and set its 'display:
block' I expect it would get the whole available width and the embedded HTML
document will generate its content according to that. Therefore it would get
intrinsic height as little as only it needs to display the whole content. If I
resize the main document (the embedding one) I expect the embedded document to
be reflowed (if needs) and take up different height eventually.

The current behavior puts some predefined size for the OBJECT element.

Other side issue here is if the embedded document should get the default margins
for the BODY just like when previewed stand alone. I think the BODY margins
should become zero (if not specified explicitly) and only the containing OBJECT
margins should count. (sorry for this off-topic note)

Reproducible: Always

Steps to Reproduce:

Comment 1

[Stanimir Stamenkov]

Attachment: A sample HTML document to be embedded

Comment 2

[Stanimir Stamenkov]

Attachment: HTML document embedding attachment 108620

Comment 3

[Stanimir Stamenkov]

I think if the OBJECT has 'display: inline' should behave like it's an DIV
element (for example) with 'display: inline-block' which holds the HTML content
of the embedded HTML document. I suppose this is related/dependent to Bug 9458
and Bug 18217.

Comment 4

[Stanimir Stamenkov]

The bigger issue here seems when an <OBJECT type="text/html"> has a 'display:
block' layout.

When its generated content is shorter in width than the available width if it
would shrink (just like a table, or like <OBJECT type="image"> without
dimensions specified) or it would take the whole width just if the embedded HTML
was enclosed in a block element in the main document. So a heading or block
element in the embedded HTML would take a width just like it was inlined in the
main document.

The second case is when the embedded HTML content contains boxes wider than the
available width: if it would act like embedded HTML content was inlined
therefore the OBJECT box would get enough wider and affect the main document
layout or it would be given only the available width and scroll bars should appear.

I think the OBJECT box should behave like a DIV enclosing the embedded HTML
content and it would take the whole available width but if it needs more it
would be sized bigger.

Comment 5

[Markus Hübner]

confirming - trunk build 200302211608 on winxp

Comment 6

[Chris Casciano]

"dynamic intrinsic size"... that phrase bugs me.


Myself, I don't think the intrisic width of an embedded html object should
default to fill the containing block. I think if the content of the document is
simply a 25px by 25px image then the instrinic width of the object element would
be 25px + all the margins and padding in the document. So the end result of your
testcase would be something like:

-----------------------------------
|-----                            |
||   |                            |
||   |                            |
|-----                            |
-----------------------------------

I also think that if there was an element in the embedded document that was
larger then the width of the current viewport (or other containing block) for
instance a 2000px wide image, its display should not be truncated to fit but be
as wide as it needs to be to diplay the entire width of the embedded doc.

What isn't clear to me is what the intrinsic width of a "liquid" document is -
e.g. an embedded doc containing paragraphs of text that wrap to fit the space
its given. My first thought would be this is the only case of the 3 where the
width of the containing block would have any impact on the object, but the
problem I have with this is that it really isn't "intrinsic" width at that point
is it.

Q: How do iframe currently behave? or embedded flash movies?

[With the above said, I have not yet looked at the w3c rec's to see if there is
any mention of the intrinsic dimensions of an object.]

Also -> All/All as this isn't exclusive to windows

Comment 7

[Stanimir Stamenkov]

To Comment 6: Yes, indeed the OBJECT size in this case would be not plain
intrinsic. May be that's why I've chosen such horrible bug title... or may be
it's just my bad english :-)

I don't agree that embedded document should always shrink to use only as it
needs. In such case if a block element in the embedded document, which normally
takes the whole available width, has a background color set the background will
not fill the rest of the width in the main (embedding one) document. That's why
I've put header elements with background color set in the test case. The
embedded document should shrink if it is a 'inline-block' or 'inline' (it's a
replaced element): Comment 3.

I was thinking of something like Java AWT components (this one I'm familiar
with). Each component has a 'minimumSize', 'preferredSize', 'maximumSize' and
'size' properties. The components themselves are laid out in a layout with
specified algorithm. The layout can choose to honor or not any of the
'minimum/maximum/preferredSize' and then set the actual 'size' property.

I this case of "liquid" document the layout could query the object for preferred
size, then set desired width and then the object should calculate it's
min/max/preferred height accordingly. Or the layout may choose first to set
fixed height and then to get calculated width.

May be there should be additional 'fixedWidth' and 'fixedHeight' properties
which when set to affect the calculation of the 'min/max/preferredSize'
properties which would be responsibility of the object implementation.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Note that the dependency on bug 80713 is backwards -- an HTML <object> just uses
an iframe internally, so fixing iframes would fix this bug.

Comment 9

[Jungshik Shin]

*** Bug 228051 has been marked as a duplicate of this bug. ***

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 12 votes.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 11

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.