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:
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.
confirming - trunk build 200302211608 on winxp
"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
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.
Note that the dependency on bug 80713 is backwards -- an HTML <object> just uses an iframe internally, so fixing iframes would fix this bug.
*** Bug 228051 has been marked as a duplicate of this bug. ***