Closed Bug 240617 Opened 20 years ago Closed 16 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)

Product:
Core
Component:
Web Painting
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 22274

People

(Reporter: mail, Assigned: roc)

References

(
URL
)

Details

Attachments

(2 files)

as described above
111.49 KB, image/jpeg
Details
testcase
3.03 KB, application/zip
Details 
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

    
    

    
  
see Bug 240886

    
    

    
  
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.

    
    

    
  
thanks TIMWI !
see #254 at
https://bugzilla.mozilla.org/show_bug.cgi?id=22274

    
  
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 16 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: