Closed Bug 240617 Opened 20 years ago Closed 17 years ago

a small div (less than 16px in heigth) is positioned as it had 16px heigth - only in strict mode

Categories

(Core :: Web Painting, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 22274

People

(Reporter: mail, Assigned: roc)

References

()

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 when using DTD: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> a small div (less than 16px in heigth) is psositiones as it had 16px heigth - only in strict mode. (i use php-browser sniffing to give a different top-value for the mozilla browser, or set the div to a larger size) as read in w3c documents, there should be no minimal size of a div. the div is positioned by "position:absolute;" and the value is like "top:280px;" etc. Reproducible: Always Steps to Reproduce: 1.load http://localhost/tektrum.de/produkte.php 2. view source and search for id="line2" 3. do it with ie or opera - there is "top:50px;" in mozilla there is "top:34px;" (code difference via php-browser-sniffing) - the difference of 16px produces the same view - make shure, to watch "tektrum.de/produkte.php" - which is in strict mode
Could you attach a test case or link to an _online_ document? Thanks, that would be great.
Do you mean this one? <div id="line2" class="a" style="left:0px; top:34px; filter:alpha(opacity=50); -moz-opacity: 0.5; opacity: 0.5;"> seen on: http://www.tektrum.de/tt/english/produkte.php Standards compliance mode stylesheet: http://www.tektrum.de/pslcss.php?ipath=../pics/ html,h1,h2,h3 { font-size:16px ! important; overflow:visible; } .a {position:absolute;}
Summary: a small div (less than 16px in heigth) is psositiones as it had 16px heigth - only in strict mode → a small div (less than 16px in heigth) is positioned as it had 16px heigth - only in strict mode
Mozilla's layout is correct. In standards mode, the CSS inline model says that any line box that is nonempty becomes the height specified in the line-height property. See bug 22274 for more information. *** This bug has been marked as a duplicate of 22274 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
ok the online document is: http://www.tektrum.de/produkte.php (not localhost) and you found the code i meant: <div id="line2" class="a" style="left:0px; top:34px; filter:alpha(opacity=50); -moz-opacity: 0.5; opacity: 0.5;"> (i will reduce for a small testcase later !) * i think you mean something different.. .. and i had not described in detail: "...a small div (less than 16px in heigth) is psositiones as it had 16px heigth - only in strict mode..." i have to add: .. and the (1px) div would start 16px obove (-16px) so i dont think this bug is the same as bug 22274 if the box / div would get a minimum heigth by font-size or any other spec., it would not result in this problem, because the heigth of a div would not affect its position * div "line2" has only one image inserted this image is a thin line, and has a height of 1px - the div will also get this heigth of 1px (of its content) if i give this div a style of: "top:50px;" the div (and image) should start at top:50px; but what mozilla does, is to put it on 64px of y, - so i have to correct in mozilla, and set top:34px; - to get real top:50px; * the image is in real 1px * 796px the div is the same ie and opera report via javascript: 1px * 796px alert (document.getElementById("line2").offsetHeight); alert (document.getElementById("line2").offsetWidth); mozilla reports instead: 21px * 172px in other words: mozilla works here, like i would take an image of 16px where the upper 15 pixel are without visual content and only the 1 pixel at the bottom of the image has a drawn thin line - so i would have to position higher above (15px)
> so i dont think this bug is the same as bug 22274 It's _exactly_ the same. > if the box / div would get a minimum heigth by font-size or any other spec., > it would not result in this problem, > because the heigth of a div would not affect > its position No, but it would affect the position of the image, which is what I assume you're actually looking at. > this image is a thin line, and has a height of 1px > - the div will also get this heigth of 1px (of its content) In Mozilla, in standards mode, it will get a height equal to the font height (16px in this case), with the image sitting on the baseline (so 14px below the top of the div if the font ascent is 14px, which is about right for a 16px font). > the div (and image) should start at top:50px; That's where the div starts, yes. The image starts at 64px. Put a border on the div to see for yourself. > like i would take > an image of 16px > where the upper 15 pixel are without visual content That is _exactly_ what the rendering should look like in this case. See bug 22274 for the reasons.
ok - the div-size depends on font-size ! and it's the same bug but - the direction of the additional size (here 15px) is a problem to me. (or in other words the position in the div) _normally size directs to the bottom_ _you said Mozilla's layout is correct._ it confused me to imagine what's going with little images _if you use large fonts_ for some reasons (users with bad eyes) i have now pressed strg+ on mozilla and got some idea why it works this way.. (http://localhost/tektrum.de/produkte.php) (with strong size in the sroll area - text _and_ image) _please tell me (a little tip) if i'm wrong with the following:_ div containers are a great thing for many uses and there is a need to overwrite the _actual condition:_ *1.* font-size in _body_ spec. sizes the div *2.* additional font-size in THIS DIV affects in additional inner space, and moves the image too. *3.* size cannot be overwritten by any heigth or font-size css (a solutionm is a must for some ui designs (or in the future vector graphics in containers..)
Have you _READ_ bug 22274? The comments in there discuss several different solutions to your problem.
thanks ! now _READ_ - bug 22274 - cruel stuff in my opinion the comment of david baron is the "essence": >That doesn't make it a bug. The CSS2 inline box model really only makes sense >this way. The problem is that people are trying to use inline images as >blocks, >which they're not, unless you make them blocks. >It can be worked around by: > * triggering compatibility mode > * using 'display: block' on the images (works in many situations, but not all, >and logically preferred) > * using 'vertical-align: bottom' on the images "display: block" on the images helped me.. ..as understood this is not a temp. workaround and seems to work in future - right ?? ..is it logical, defined, or what makes this images (there container) "inline" not "block" by default ? (especially if they are positioned by "position:absolute" ? ..would it break any specs. if at least "heigth:1px;" would be accepted by the browser ?
want to thank you, as i see now you've done great work to me .. hope there will come a general solution, to avoid that problem, when it comes to great spread use of div's and standard mode - instead of actual table design..
> .as understood this is not a temp. workaround and seems to work in future - > right ?? Yes. > ..would it break any specs. if at least "heigth:1px;" would be accepted by the > browser ? It _is_ accepted. It changes the height of the div. It does not change the height of the line box inside the div, which is what matters here. Setting the line-height of the div to 0 would work, though.
now i see that the solution "display: block;" brings disadvantages.. .. as block elements the images affects all the *actual possible* used center-code around (text-align etc., margin..) ("i would very much like to see the actual mozilla-implementation as a bug - have not seen any disadvantages in the other browser. ;-)") so the best workaround to me is: * to use "vertical-align: TOP;" - IF position is defined from top (to leave the additional space _UNDER / BEHIND_ the image) * yeah - and if position is defined by bottom.. - you.. no ! - than nothing helps, it seems.. if i see all that discussion on the duplicate bug 22274.. (while no real backdraws in the other browsers seen..) it would be the best *STANDARD-SOLUTION* (means for all position cases) to solve it with php-browser sniffing again.. until there is a general BUGFIX in view.. .. but that presupposes to mark this actual mozilla-implementation here as a BUG to find *_ANOTHER WAY_* to go with the specs. (transitional-mode cant be the solution..) that CSS is powerfull for great designs, but this implementation cuts through lots of it. - i think this will become visible when standard mode will be used more..
Your problem is that IE does not implement the CSS inline box model correctly. Please complain to them. note that setting line-height to 0 like I suggested will in fact solve your problem in all browsers involved in this case.
>note that setting line-height to 0 like I suggested will in fact solve your >problem in all browsers involved in this case. that littles the problem, - but there is also added space between image and border (padding does not help) * to find another view i "played oround" with that image-containing divs. * >It _is_ accepted. It changes the height of the div. It does not change the >height of the line box inside the div, which is what matters here. Setting the >line-height of the div to 0 would work, though. .. i tried, it CHANGES NOTHINMG, even if i add this style to the image AND to a surrounding div. "font-size:1px;heigth:1px;line-heigth:1px;overflow:hidden; .." (not tried clip - it should work, buts to coplicated , thougt) if display:inline; applied to the SURROUNDING div, there is no additional space to the border - but then the borders are completely not surround the element.. (see atachment)
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Attached image as described above
when line-heigth:0 applied to element or container it affects "nearly" nothing. when applied to the body instead, all text is printed in 1 single line, in every browser (like printer whitout linefeed). standard would be line-heigth:100%; - but that helps nothing. in that standard-mode i can see no way, - to get shure a generated div will be placed, where you want it. it is ONE THING to comply with the w3c heigth-definitions, ANOTHER thing is to provide a secure LINEAR POSITIONING concept (forgive my english)
the information for line-heigth:0px; you gave me, have i found on some pages, in combination with transitional DTD's they where recommended. but in transitional DTD i had not one of this problems. they came with: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> i would agree: that it all would NOT be a bug, IF one could disable the additional space in STRICT-MODE, witout affecting other preferences (center / floating etc.) otherwise whats with ABOLUTE POSITIONED elements, which are now not really abolute positioned, and also these elements are floating around, when a USER presses STRG+ and no javascript could handle these ABSOLUTE-POSITIONED elements (whitout text). (not talking about the browser-differences) _"ANYWHERE" in this condition IS A BUG_ !
these two parts brought the most: img { vertical-align:top; } .. to avoid added space to position a > img { display: block; } .. to avoid aded space to linkareas (overlapping "onmouseover")
a new bug description: here in strict standard mode (without table's), if an image is inline there is no way, to define the dimension of the image-container (div) (if fonts are larger) if image is block-element, only for that reason you loose the floating possibilitys (to center etc.) if someone really uses divs instead of tables, and decides to go with standard mode in mozilla he looses elemental properties of css as i develop a windows-like div-ui generated by php this what i see now cuts straight through - in my case, the tipps i got here, did not solve - i REALLY TRIED THEM
Attached file testcase
_:_ image (a line) in a div (strict DTD) press strg+- container grows, - like there where text in the box as boris zbarsky told: line-heigth:0 should help, think too that where logical, but it doesnt why ?
.. and if you lay an anker around the image, the "href" in that *absolute positioned* div grows over the image-borders EVEN if you set the div by: heigth:1px; IF line:heigth:0; on any image would avoid all that space, everything where ALLRIGHT, thougth !
universal WORKAROUND for all that image-container FOUND ! .. works perfect by any pixel. by that i found out: the same problems "bring with itself" that the link-sensitive area over <LI> elements runs out over the borders, - when there are large fonts .. on this elements could help the same workaround, thought but another solution is on you, i think i will send my workaround with additional info about the conditions with ths <li> element
Peter Grabner, I think your only problem here is that you are misspelling "height". It's H-E-I-G-H-T. Browsers will not recognise your CSS if you spell it differently.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago17 years ago
Resolution: --- → DUPLICATE
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: