Closed Bug 208602 Opened 22 years ago Closed 21 years ago

style="width: 100%; height: 100%;" ignored on replaced inline in auto-size table cell

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: khayyami, Unassigned)

References

(
URL
)

Details

(Whiteboard: dupeme [ignore comment 7 through comment 17])

Attachments

(2 files, 1 obsolete file)

Reduced testcase
(deleted), text/html
Details
Same testcase but with <img>
(deleted), text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030507 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030507 The persian font rendering has some problems. Otherwise in some parts you're doing better than IE. If you're interested, I may give you some comparisons. Reproducible: Always Steps to Reproduce: 1.go to http://web.peykeiran.com/net_iran/irnewsbody.aspx?ID=4336 using IE6 2. 3. Actual Results: nothing is shown, the core of the article is empty Expected Results: You see a full page of text
Attached file Reduced testcase (deleted) —
moving to style system
Assignee: font → dbaron
Status: UNCONFIRMED → NEW
Component: Layout: Fonts and Text → Style System
Ever confirmed: true
Summary: You may compare this page with the page shown in IE, to see that no (Persian) font is displayed in Mozilla → style="width: 100%; height: 100%;" ignored on textarea
Whiteboard: dupeme
->Form controls, although beware that 'height: 100%' may not do what you expect (and IE's behavior probably shouldn't be imitated).
Assignee: dbaron → form
Component: Style System → Layout: Form Controls
QA Contact: ian → desale
Attached file Same testcase but with <img> (deleted) —
This is not form controls specific -- any replaced inline behaves the same way. In my opinion, this is invalid, though I suppose we could try to make our quirks cover this case....
Assignee: form → block-and-inline
Component: Layout: Form Controls → Layout: Block & Inline
QA Contact: desale → ian
Summary: style="width: 100%; height: 100%;" ignored on textarea → style="width: 100%; height: 100%;" ignored on replaced inline in auto-size table cell
Is this still a problem in a current build?
Another testcase showing this bug. (yes it is a bug, because it's 100% HTML 4.01 compliant, as is the page as well)
Yes, Boris, it's still a problem in current build(s). Tested with end-of-Feb-'04 nightly...same thing. http://www.brinkster.com/andreas2002/index_rip.htm or look testcase above. P.S. It occurs to me this one is about duplicate: http://bugzilla.mozilla.org/show_bug.cgi?id=10212
Andreas, the rendering on your site is exactly correct per CSS spec (which is what controls layout; the HTML spec does not), and since the site is in standards mode it's not going to change no matter what happens in this bug. The question was whether the original reported problem was still present with the changes to percent sizing we have made in quirks mode.
*Exactly* correct? I don't think so. Try this site with MSIE and tell me whether it doesn't look better there :) Before you contradict...yes this is validated HTML 4.01 Transitional, so it is conform to current standards. It's a fact that style="height:100%" *DOES* still get ignored in Mozilla, as reported by many users. I can't believe this rendering is OK as it is. Whereas I have to admit it's not quite the same as in case #208602, only _similar_. Please take a look at #216847 too: http://bugzilla.mozilla.org/show_bug.cgi? id=216847 . Another similar thing. All problems seem to originate from the very same root: Mozilla ignoring percentage heights like 100%, therefore not stretching the table cells.
> Try this site with MSIE MSIE doesn't even pretend to correctly implement percent width and height per the CSS spec (or height at all per the CSS spec). > I can't believe this rendering is OK as it is. I suggest doing a little reading of the definition of percent heights in the CSS spec, then. The spec EXPLICITLY says that percent heights are ignored if the height of the parent is auto. How much more clear can you get? Please stop spamming this bug with comments that are totally not relevant to it, ok?
OK, if you please stop reacting so rude. Have you taken a look at my code? I haven't EVER used 'auto' in any CSS code I wrote, not in *.css files, nor embedded in HTML. -ae-
the value of the 'height' property defaults to 'auto' per the spec. The fact that you haven't explicitly set the height of the parent means it is 'auto'.
Thank you! This was news for me. OK, I've looked again at my code; however, there should be no 'auto' coming into effect, because I've always specified height, also with the main (first) table. Trying to investigate this a bit more ... thanks so far.
Right, but you keep specifying a height of 100% which again, by definition needs to look at the parent's height. So it gets to the table element, and looks at its parent's height, which is the body element. There is no height explicitly specified there, and thus its value is 'auto'.
MANY THANKS TO CHRISTOPHER! (and apologies for my stubbornness) Sorted it out! No it's NOT a bug. As a Java programmer, I should freakingly well know what a 'parent container' is! And what's the parent container of every table? yes, <HTML> and <body> stuff. "Fix" is utterly primitive. <style type="text/css"> html, body {height: 100%;} ... </style> *BANG* Thanks for the pointer, due to your explanation I was able to sort it out. Might help lots of people having similar problems in other "bug" threads. I bet I won't do this mistake ever again in my code. :-) Thanks to everyone involved for making such an extremely STRICT browser! Everyone would be forced to code strictly accurate, if any browser was as unforgiving as this one! Over and out.
Whiteboard: dupeme → dupeme [ignore comment 7 through comment 17]
Attachment #143320 - Attachment is obsolete: true
I'm going to mark this worksforme -- the width is working, and the height is correctly being treated as auto.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: