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)
Tracking
()
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
Comment 1•20 years ago
|
||
Could you attach a test case or link to an _online_ document? Thanks, that would
be great.
Comment 2•20 years ago
|
||
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
Comment 3•20 years ago
|
||
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
Reporter | ||
Comment 4•20 years ago
|
||
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)
Comment 5•20 years ago
|
||
> 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.
Reporter | ||
Comment 6•20 years ago
|
||
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..)
Comment 7•20 years ago
|
||
Have you _READ_ bug 22274? The comments in there discuss several different
solutions to your problem.
Reporter | ||
Comment 8•20 years ago
|
||
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 ?
Reporter | ||
Comment 9•20 years ago
|
||
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..
Comment 10•20 years ago
|
||
> .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.
Reporter | ||
Comment 11•20 years ago
|
||
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..
Comment 12•20 years ago
|
||
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.
Reporter | ||
Comment 13•20 years ago
|
||
>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 → ---
Reporter | ||
Comment 14•20 years ago
|
||
Reporter | ||
Comment 15•20 years ago
|
||
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)
Reporter | ||
Comment 16•20 years ago
|
||
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_ !
Reporter | ||
Comment 17•20 years ago
|
||
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")
Reporter | ||
Comment 18•20 years ago
|
||
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
Reporter | ||
Comment 19•20 years ago
|
||
_:_
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 ?
Reporter | ||
Comment 20•20 years ago
|
||
.. 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 !
Reporter | ||
Comment 21•20 years ago
|
||
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
Reporter | ||
Updated•20 years ago
|
Reporter | ||
Comment 22•20 years ago
|
||
see Bug 240886
Comment 23•19 years ago
|
||
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.
Reporter | ||
Comment 24•19 years ago
|
||
thanks TIMWI !
see #254 at
https://bugzilla.mozilla.org/show_bug.cgi?id=22274
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 17 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•