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!
Created attachment 11511 [details] testcase part - iframetest-child.html
Created attachment 11512 [details] testcase part - iframetest-parent-block.html
Created attachment 11513 [details] testcase part - iframetest-parent-inline.html
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?
"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 ...
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.
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)
Bug confirmed on 4.0.3
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.
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? :-(
> 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).