Bug 107705 - CSS2 violation - percentage height of iframe is ignored and substituted with constant instead
Summary: CSS2 violation - percentage height of iframe is ignored and substituted with ...
Status: RESOLVED NOT A BUG
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-19 09:52 UTC by kavol
Modified: 2008-04-08 02:20 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
testcase part - iframetest-child.html (1.22 KB, text/html)
2005-06-19 09:54 UTC, kavol
Details
testcase part - iframetest-parent-block.html (448 bytes, text/html)
2005-06-19 09:54 UTC, kavol
Details
testcase part - iframetest-parent-inline.html (504 bytes, text/html)
2005-06-19 09:54 UTC, kavol
Details
another testcase - comparsion of iframe with img (4.48 KB, application/x-tar)
2006-02-13 11:26 UTC, kavol
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kavol 2005-06-19 09:52:48 UTC
Version:           Konqureor 3.4.0 (using KDE KDE 3.4.0)
Installed from:    Gentoo Packages
Compiler:          gcc version 3.4.3 20041125 (Gentoo 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7) 
OS:                Linux

Hello,

at first, sorry for my English ;-)

I have come across a nasty bug in CSS implementation. The previous versions
of Konqueror worked ok for me (or, if not ok, then at least in the way that
I did not notice the error).

This is quite interesting, while considering that Konqueror now behaves
in the same way as Mozilla ... for which this bug was submitted multiple
times. But Mozilla team does not accept that it is a bug and instead they
say that it is a feature of which users should be very happy. :-(
Please do not behave so incomprehensibly arrogant as the Mozilla team.
And do not allow Mozilla to do the same thing as Internet Explorer before
- to force the developers to ignore standards and implement workarounds
for buggy browser.

I have attached some testcase files and I include a links to the W3C pages
so anyone can verify with the specifications.

At first, look at the definition of IFRAME:
http://www.w3.org/TR/html4/present/frames.html#edef-IFRAME

We see:
<!ELEMENT IFRAME - - (%flow;)*         -- inline subwindow -->
look at the DTD:
<!ENTITY % flow "%block; | %inline;">

- so IFRAME may be used either as block-level element and as inline element.

At first, look at the block-level usage testcase:

The relevant chapter in CSS definition is 10.5 Content height: the 'height' property
http://www.w3.org/TR/CSS21/visudet.html#the-height-property

"<percentage>
... If the height of the containing block is not specified explicitly
(i.e., it depends on content height), and this element is not absolutely
positioned, the value is interpreted like 'auto'.

auto
The height depends on the values of other properties. See the prose below."

Now the interesting part is chapter 10.6.2
http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height

The testcase uses "width: 100%" which is a computed value and therefore
the next part applies:

"If 'height' has a computed value of 'auto' and 'width' has some other computed
value, then the used value of 'height' is:
    (intrinsic height) * ( (used width) / (intrinsic width) )"

Let's look at the definition:
http://www.w3.org/TR/CSS21/conform.html#intrinsic

"Intrinsic dimensions
The width and height as defined by the element itself, not imposed by
the surroundings. CSS does not define how the intrinsic dimensions are found.
In CSS 2.1 it is assumed that all replaced elements, and only replaced
elements, come with intrinsic dimensions."

So, the document within IFRAME comes with some intrinsic dimensions
(within the testcase, the height is IMO simply the sum of the heights of all
lines plus margins etc.) This value should by multiplied by 'used width'
and divided by 'intrinsic width' of the IFRAME. However, I am still getting
the same constant (*) instead of the result of the formula ...

(*) 200 pixels - screen pixels, not device independent px!
- see http://www.w3.org/TR/CSS21/syndata.html#length-units


Now, let's take a look at the inline usage testcase.

The paragraph height has the initial value 'auto'. This means that its height
is computed based on its content. So, this is the same as the situation before,
where <IFRAME> was a child of <BODY> which had not "explicitly specified
height" too; 10.6.2 talks the same about both the block-level and inline elements.


Let's try another trick - to avoid doubts about the value of "intrinsic
dimensions", it may be specified explicitly by adding the width and height
to the root element of the inserted document. The code goes to HEAD section
of iframetest-child.html:

<STYLE type="text/css">
        html { height: 400px; width: 400px; }
</STYLE>

Now, from the layout point of view, the <IFRAME> in the parent document should
behave just like any other "Inline replaced element" of size 400*400 px.
For example, just like image. But if I replace the <IFRAME> with <IMG>
(and supply the image of appropriate size), it is not displayed with the
height of 200 pixels - why not, just like <IFRAME>? What is the difference
between <IMG> and <IFRAME>? Both are (in this second case) "inline replaced
elements" and so they should behave the same!
Comment 1 kavol 2005-06-19 09:54:04 UTC
Created attachment 11511 [details]
testcase part - iframetest-child.html
Comment 2 kavol 2005-06-19 09:54:28 UTC
Created attachment 11512 [details]
testcase part - iframetest-parent-block.html
Comment 3 kavol 2005-06-19 09:54:47 UTC
Created attachment 11513 [details]
testcase part - iframetest-parent-inline.html
Comment 4 Ivan Vadovič 2005-07-17 18:28:00 UTC
The devil lies in the intrinsic dimensions definition, which equal to "The width and height as defined by the element itself, NOT IMPOSED BY THE SURROUNDINGS."

Both width and height of a html document are imposed by the surroundings, that is the viewport. Notice how block level elements stretch all the way to the right and span the whole width of their parent. And so does the root element span the width of the viewport. Height of the viewport also has an impact on the rendered document. The only way to make intrinsic dimensions computable is to set width and height explicitly on the root element itself, as you already pointed. Now, what's the difference between setting the dimensions on the embeded root element and setting the same dimensions on the iframe element?
Comment 5 kavol 2005-10-18 21:25:36 UTC
"Now, what's the difference between setting the dimensions on the embedded root element and setting the same dimensions on the iframe element?"

reusability, for example - what if I want to have the same iframe included in two documents with different sizes? - then the iframe elements will have different dimensions for the same size of the embeded content

or, what if I want to show the whole iframe content, but the parent does not know about the actual dimensions of the iframe content (the file may be replaced irregulary, on another server ...) - so it would be natural to set 100%

I think that the problem with the viewport has an easy solution for most cases - let the specified (percentage) width of the iframe be computed from its parent element (as its whole width) rather then guessing it from the iframe content (if it is not set explicitly on the root element), then this value is passed to the rendering of the iframe content as the "viewport" width; this is in most cases sufficient to compute height and this value may be passed back to the parent, allowing to compute the width and height of the iframe with the CSS formula

It is a little bit tricky, but I do not think that it is in violation with (the spirit of) CSS, because, as you said before, the "best practice" is to have document width set by the viewport and we just define how the viewport of
the embeded document is wide ...

you may disagree and say that this is great violation of CSS, but I say that is no greater violation than if you use fixed value for height

and, in any case, the rendering SHOULD BE THE SAME for the same type of element, so until img gets scaled by percentage and iframe with dimensions  explicitly set on root element does not get scaled, something is rotten ...
Comment 6 kavol 2006-02-13 11:21:32 UTC
I just want to say that the newer Konqueror (3.5) has this problem too ...

Please, note that this problem has two parts - the first one being problem with CSS itself, but the second one (different behaviour for the same element class) is clearly problem of the browser; if the iframe dimensions are set (see the stylesheet within the last part of the original post), they have to be respected.
Comment 7 kavol 2006-02-13 11:26:59 UTC
Created attachment 14667 [details]
another testcase - comparsion of iframe with img

see the height of the inline img element and the height of the inline iframe
element ... both the png and the child html have the size of 400*400 pixels,
but they are rendered differently

(actually, the image has "1:1 pixels" while the html should have "CSS pixels"
but KHTML treats that the same, AFAIK)
Comment 8 FiNeX 2008-04-07 00:40:04 UTC
Bug confirmed on 4.0.3
Comment 9 Germain Garand 2008-04-07 02:32:01 UTC
this bug is actually invalid.

HTML Iframes have no intrinsic dimensions because they host a viewport, that maybe of any size, independantly of the inner document's own size.

There is no css-defined way of selecting the viewport, so you cannot set intrinsic dimensions of an HTML Iframe from the inner document.

Therefore Iframes with auto dimensions revert to standard fallback of 300x150 dimensions.
Comment 10 kavol 2008-04-08 00:09:11 UTC
I wish the developers would actually read the bugreports instead of just calling the bugs "features" ...

I've referred to the CSS standard, I've refined some testcases, and all I got is "you cannot" ... of course I can, and in comment #5 I say how

the bug has two parts - when the iframe content dimensions are not defined and when they are (see comment #6)

as for the first one, I strongly disagree with your conclusion; as I said in comment #5, what you call "standard fallback" really is NOT any better than what I would prefer, if we talk about standards compliance (in fact, it goes against the spirit of CSS ...) and it is a shame to call it "standard" - can you support your words by a reference to CSS2 specification?

however, although very sad and dissatisfied I can live with that solution, because Gecko does this the same stupid way, so implementing it any else would lead to another unnecessary battle of the "browser wars"

as for the second one, the actual (Konqueror 4.0.3) behaviour is to scale the iframe the same way as img (which looks a bit funny because the inner contents are not scaled), so I would consider it FIXED

so, if you really want to close it, the proper state would be "FIXED" (although just partially) rather than "INVALID" ... but it would take too much time to actually examine the testcase, and since KDE 4 epoch the quantity is what matters, not the quality, right? :-(
Comment 11 Germain Garand 2008-04-08 02:20:27 UTC
> I wish the developers would actually read the bugreports instead of just calling the bugs "features" 

? I read your report in full extent of course.

> I've referred to the CSS standard, I've refined some testcases, and all I got
> is "you cannot" ... of course I can, and in comment #5 I say how 

No I can assure you you cannot. Specifying the dimensions of the root element does not help.The root element is contained inside a viewport. The viewport itself is not selectable by CSS. Not at all. 

All you can gather about the viewport from CSS is specified in the CSS3 Media Queries module, and it is read only knowledge.

The 300x150 fallback is of course specified in CSS 2.1 - 10.3.2 and 10.6.2. We are not doing guess work.
 
I'm sorry you are not pleased by the outcome ot this, but we are not making the standards. You may try to plead your case on the w3c mailing lists.

> as for the second one, the actual (Konqueror 4.0.3) behaviour is to scale

Images have most of the time  known intrinsic dimensions. Iframes never have.
Your #7 testcase is rendered with both elements having the size of the viewport because it doesn't have a strict doctype, so your height: 100% on replaced elements percolate down to the viewport. That is a quirk.

In strict mode, 100% height of a container with no specified height will revert to auto, and your element sizes will be different (intrinsic height for the image, default intrinsic height .i.e. 150px for the iframe).