Where is the gap under an image coming from?

[Makosuke]

I was working on a relatively simple layout recently, but got confused when Gecko added a small gap under an image that wasn't there in Safari. I messed around some and got it down to a simplified testcase that told me it's in some way related to an inline image getting line spacing below it. Here's an example:

http://steelbluepanic.com/temp/funny-margin-testcase.html

(That's a white blank png in a DIV, margins and padding of both set to zero, red lines added to illustrate.) In my layout all I needed to do was set the img to display as block, at which point everything was nifty. But I like to know why.

I'm sort of guessing this is because the image is treated as if it's sitting on the baseline of a line of text, and so there's a gap below for the descenders; anybody know if this is correct, or is there something else I'm not understanding?

Also, I'm weirded out by the fact that with my more complex layout it did NOT leave that gap in Safari, but did in Camino. Since my simplified testcase DOES show the gap in Safari as well, they were obviously interpreting some inherited style differently, which is odd because I wasn't doing anything that complicated, and I don't see what I could have done to the containing elements (not much) to cause it to leave off that space in Safari.

Any standards gurus wanna point me in the direction of enlightenment?

[angelwatt]

Yup you hit it, at least around the corners. I've come across this myself while helping someone else on this forum. It's a baseline issue.

Remedy, add the following CSS property to the img.

vertical-align: middle;

[SrWebDeveloper]

DIV's are blocklevel and so are images. Nothing is inline here.

Angelwatt's response is right on for a dynamic layout like that.

If it's a static layout you could simply define the the height property in the class for the title to 50px, same as the image. Of course in your example you display a 1px image border, so 51px would be perfect alignment (red box within red box). Using static values forces the browser to align block level elements properly across all browsers. Plus, in a real situation like a header template, more than one image is involved so I'd specify the total height and width in the CSS for your title element and also add vertical-align: top so all images display orderly since image slicing results in that type of layout.

I mention this because people doing templates will find this useful, and what you're doing will remind folks of that.

-jim

[Melrose]

I see the gap in Safari, so I don't quite see the problem as you do, but add this line to your stylesheet and it should do the trick:

.title img {display:block;}

[Makosuke]

DIV's are blocklevel and so are images. Nothing is inline here.Huh? I assume you mean that I should be making the image block-level (which I am) as opposed to that they are by default, which I'm pretty sure they're not.

Regardless, thanks for the tips and clarification from everybody; sounds like my semi-educated guess was correct.

Given the specifics of my actual layout (single full-width banner image) setting display: block makes much more sense than messing with the baseline and leaving it inline, but that clarification will definitely be handy the next time I'm working with a sliced or otherwise multi-image DIV.

[SrWebDeveloper]

Let me rephrase myself... div's are blocklevel and images inside INHERIT that property by default (due to the cascading nature of CSS2).

Block level is defined as having a line break before and after the element, inline means the opposite. Your blank line showed up BELOW (not to the right side) in Safari because it treated the image as block level. I suggested applying static dimensions so the browser to bypass formatting, another user added alignment since you used dynamic heights so the browser would position the image element regardless of the break underneath.

Not that anyone would add style="display: inline" to all images inside of div to align them properly, it's easier just to do the tricks we used here. But technically, that's proper CSS when you need to align multiple images, to override the inheritence and remove all line breaks for cross browser compatibility.

-jim

[Makosuke]

I do appreciate the elaboration, Jim, but I'm still not lining up what you're saying with what I'm seeing. Maybe I'm just being really dense and reading what you're saying backwards, but I do want to understand this.

Am I correct that you're saying that, in this situation, with no display property set in the stylesheet, that the IMG itself is inheriting block from the DIV it's in? If not, I honestly apologize for being dense.

If so, I'm seriously confused, because it sure seems like the IMG is being treated as an inline element. If, for example, I use Safari's Inspector on my example page, the IMG's computed display is inline. Similarly, if I explicitly set it to display: inline, it doesn't change the layout at all.

The space below it isn't coming from wrapped whitespace, it's coming from the space reserved for the descenders in the inline of text that the image appears inline in, because (as angelwatt was saying) the implied vertical-align: baseline setting puts the bottom of the image on the baseline of the line of text it's on. Adding some text beside it illustrates this pretty clearly, and it's why either adding display: block to the image or vertical-align: middle will both "fix" it, in one case by making it a block-level element and in the other by centering the image on it's implied line of text (which, since the default line-height is smaller than the height of the image, leaves no empty space above and below).

Once again, if I'm misreading what you're saying and disagreeing only with myself, my honest apologies. I just like to "get" stuff like this, and I want to make sure what I'm thinking is what's actually happening.

[SrWebDeveloper]

Am I correct that you're saying that, in this situation, with no display property set in the stylesheet, that the IMG itself is inheriting block from the DIV it's in? If not, I honestly apologize for being dense.

You're not dense, and you're right on the money. That's how CSS is supposed to work, but most of the browsers out there have relaxed standards in terms of the rules of inheritence. Safari, as you learned and so do all developers who deal with the frustrations of cross-browser rendering, is not so relaxed.

Since you mentioned there is no whitespace and no text - and you didn't specify a height in the parent div (important) - that line you saw below the image was a block level line feed. Changing alignment or setting static height both override the problem.

I'm pretty confident of this, but this is open to discussion if someone out there disagrees.

-jim

[Melrose]

It's out of my league to debate how the box model works - I still have trouble from time to time. I know enough to validate and make it work is all.

...and don't even start on 'float!'

[radiantm3]

I'm pretty confident of this, but this is open to discussion if someone out there disagrees.

Divs are block elements, but images are inline elements (by default) regardless of whether they are wrapped in a block element or not.

[angelwatt]

Divs are block elements, but images are inline elements (by default) regardless of whether they are wrapped in a block element or not.

And just for evidence, here's a document on which properties are inherited, http://www.w3.org/TR/CSS21/propidx.html

Though this doesn't mean some browsers don't override this or ignore it or have a bug.

[design-is]

It's out of my league to debate how the box model works - I still have trouble from time to time. I know enough to validate and make it work is all.

...and don't even start on 'float!'

I'm with you :rolleyes:

[SrWebDeveloper]

The linefeed I spoke of was from the parent div which had no height specified. Maybe the reason it displayed below the inline image was because that's the natural flow - inheritance says when the parent (blocklevel) is different than the child (inline) the parent wins, as it does also in a tie if I recall. Some browsers handle this situation differently (key: when parent static height is not set, not just block vs inline) so it takes an alignment or static height/width property to resolve the very specific situation. I'm a big fan of using widths/heights in parent settings, it solves so many potential issues with flow across all browsers, then alignment is only necessary to override the default.

This is getting silly, I admit it, but one thing is for sure -- the fixes stated work, regardless of the confusion I might be having as to cause! I think I contradicted myself about 3 times, just trying to grasp what's going on "under the hood". I'm interesting in finding out, if anyone at this point gives a crap and knows for sure. heh

-jim

[macgruder]

The issue is a fairly straightforward one.

Your image is inline. In other words it is being treated somewhat like a big letter sitting on the baseline.

The space underneath is the space that would accommodate a descender in a letter. Type a 'g' in there and you'll see that.

Some people have commented on the cascade, block level elements, and inheritance:

Images are by default inline elements, and display does not inherit, so the cascade does not apply here.

inheritance says when the parent (blocklevel) is different than the child (inline) the parent wins, as it does also in a tie if I recall
This would appear to be wrong. Not all css properties inherit. Font-size does for example, but display doesn't. The display property depends on the selector, and failing a selector it takes the default value.

[modesty]

youre doc type is supposed to be strict, but you didnt type it right, and its not being parsed as strict (or transitional) as firefox. it looks like safari defaults to transitional when theres a typo in the doctype.

anyway set it to transitional, or use the proper strict tag, and it works


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

also need to set the height of the div to 50 in strict, dont need too in transitional

[angelwatt]

youre doc type is supposed to be strict, but you didnt type it right, and its not being parsed as strict (or transitional) as firefox. it looks like safari defaults to transitional when theres a typo in the doctype.

anyway set it to transitional, or use the proper strict tag, and it works


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

also need to set the height of the div to 50 in strict, dont need too in transitional

The DOCTYPE in place is correct as is. There's no need to change it. He's using XHTML not HTML.

[modesty]

The DOCTYPE in place is correct as is. There's no need to change it. He's using XHTML not HTML.

my bad, the problem is the strict tag though. you need to set the height of divs in strict

[angelwatt]

my bad, the problem is the strict tag though. you need to set the height of divs in strict

Well, that's not correct either. The div does not "have to" have height set. There's no specification stating that, but setting the height does override the problem, but breaks for dynamic content. This problem was actually solved a couple days ago with a couple possible solutions. One being setting the vertical alignment (the 2nd post).

[macgruder]

my bad, the problem is the strict tag though. you need to set the height of divs in strict

What? Strict is XHTML. Height is in the CSS.

The reason has already been explained. The document is displaying correctly. There should be a gap under the image, in the same way there would be a gap under a letter.

[modesty]

What? Strict is XHTML. Height is in the CSS.

The reason has already been explained. The document is displaying correctly. There should be a gap under the image, in the same way there would be a gap under a letter.

oh really? set it to transitional then

[macgruder]

oh really? set it to transitional then

Safari and Firefox. Same in both (adding a 'g' to show baseline and inline effect). Remove the 'g' and it does indeed go away, but what we are concerned about here why the behaviour is happening, and the best way to see that is to set strict. It is interesting though that it goes away in transitional. This is probably to do with the interpretation of the baseline in the absence of letters.

As we said, it's displaying correctly: It's strict. It's sitting on the baseline. It's inline. Set the img to display:block and the gap goes away.

[SrWebDeveloper]

It's been established in an XHTML strict environment (which the OP is using, check their source) an inline image placed inside a block level div will result in a text line which is at the baseline, and we see the tiny descender area of that text line. Okay, I'm cool with that as to the "why". Now, about avoiding such issues...

Others picked up on the fact that setting height in the parent DIV resolves the issue - and I want to comment this is probably the more common solution, i.e. much like an informal best practice, compared to overriding image alignment in a strict environment. Specifying parent heights/widths ensures every image, down to the pixel, ends up where it should, spaced statically (and in some cases, absolutely) for headers, footers, sliced images with HTML in a div, etc. which are real world application of these principles.

Just trying to tie a nice little bow around this!

-jim

[macgruder]

It's been established in an XHTML strict environment (which the OP is using, check their source) an inline image placed inside a block level div will result in a text line which is at the baseline, and we see the tiny descender area of that text line. Okay, I'm cool with that as to the "why". Now, about avoiding such issues...

Others picked up on the fact that setting height in the parent DIV resolves the issue - and I want to comment this is probably the more common solution, i.e. much like an informal best practice, compared to overriding image alignment in a strict environment. Specifying parent heights/widths ensures every image, down to the pixel, ends up where it should, spaced statically (and in some cases, absolutely) for headers, footers, sliced images with HTML in a div, etc. which are real world application of these principles.

Just trying to tie a nice little bow around this!

-jim

Yes, but it's hardly a solution in the many environments where the content is database driven, and where simply setting the image to be display:block is already a solution that works without for the need for this kind of once-only setting.

The rationale of the above reads very much like the content that CSS is designed to escape you from ('sliced images' and so forth). If you're going to need to specify div heights and use sliced images then there's little need in this kind of CSS anyway, and you may as well go back to tables and shims.

For those of us who are building content driven community sites, for example, the principles behind why things are happening and the CSS only solution is essential.

In fact, it seems the two CSS solutions here are the ones that actually work whatever the occasion so I'm not sure why the insistence on a more complicated solution that is more prone to error, less simple to change, less robust, and unnecessary.

[SrWebDeveloper]

Well, I said "common" solution, not the end all of solutions. Now I'm off subject. I'll give you and others the final word, this is getting beyond silly now - everyone here recognizes there will be exceptions to all rules/situations, the word common does not mean 100% of the time in terms of solutions, and there is more than one solution at hand even for this issue, in limited scope as it is. Use this thread as an example there are many ways to skin a cat.

-jim

[macgruder]

Well, I said "common" solution, not the end all of solutions. Now I'm off subject. I'll give you and others the final word, this is getting beyond silly now - everyone here recognizes there will be exceptions to all rules/situations, the word common does not mean 100% of the time in terms of solutions, and there is more than one solution at hand even for this issue, in limited scope as it is. Use this thread as an example there are many ways to skin a cat.

-jim

No doubt. But reading through this thread there are 2 solutions given:
1. display: block; (or using vertical-align)
2. setting heights to everything, plus lots of incorrect explanations about the cascade and other things.

Yes, there are many ways to skin a cat, but if there's a simple and easy way, then there is no need to give a second way that is more complicated, doesn't work as well, and is accompanied by incorrect explanations while stating it is more common.

[SrWebDeveloper]

When you give someone the last word, then they blatantly misquote you, that's not right.

I said set the height in the parent div, which is one single CSS style setting based on an image inside a div, the context of this whole thread (not "dynamic" situations like you brought up out of nowhere, just as bad as other users mentioning DOCTYPE and just as bad as me thinking inline images inherited block level div in this example).

The ONLY final, summary advice I ever offered as a common solution was that single height in the parent div. The rest was trying to understand why, and I learned in the process and so did we all, eventually. Now, please, let it rest.

-jim

[macgruder]

No this is what you said:
"Others picked up on the fact that setting height in the parent DIV resolves the issue - and I want to comment this is probably the more common solution, i.e. much like an informal best practice,"

You suggested that the solution of setting the height was regarded as a best practice. Given the fact that this is not a best practice and further that at least two people gave a very simple, informed, and very effective solution that is a best practice: i.e. it works in static situations and dynamic situations and with all/most doc types.

If you proclaim that you are going to 'tie a bow' around a problem and imply that it is a best practice when it isn't then don't be surprised if someone points out that there is a better solution, and don't start throwing around words like 'silly' when they do so.


That's me about done.

[SrWebDeveloper]

Once again, a blatant case of selective quoting (seen as abusive by some):

My previous reply was in response to you saying I said, " 2. setting heights to everything," which is PLURAL, re: all images , re: "everything"

Also, I still technically stand firmly by what I said, which was an INFORMAL best practice for this specific situation (not all) and PROBABLY more common. The closest example I can apply to prove my point is for certain CSS styles with a static WIDTH must be declared to render properly. This situation reminded me of that. If you choose to remove the words INFORMAL and PROBABLY from my statement and interpret that I am saying it's the only way, the best way, and GOD'S WILL, you're entitled to do that, but DON'T SAY I SAID THAT. I am not angry you disagree, I am angry you keep attributing intent based on selective quoting, leaving those words out as you bashed me. I was careful with my language to let people know I wasn't denying the other suggestions! Language really does matter - it sets context.

And for the final time, the OP never included the height in the original CSS, so although you and angelwatt pointed out the problem with dynamic content, don't forget all my comments were about the original OP's code which involved 100% static content. Again, you might disagree, but you can't make it seem my comments were intended for most to all situations without a peep from me.

I would have been more gracious than this if you had just been nicer about it and not focused on a few words in a larger sentence. I wish you the best and you obviously have skills for the coding aspects of web development, the tech stuff, I mean.

-jim

ps: There's nothing else left for you to mis-quote, so you finally have the last word!

[macgruder]

Talk about creating an argument out of nothing. You seem to have totally over-reacted to the fact that someone didn't agree with your attempt to "wrap things up", and to call something an 'informal best practice'. I don't care if you used the word 'informal' or not. It's a meaningless in this context anyway.

Don't try to talk about being 'gracious' when you start using words like 'silly' when people use reasoned arguments (even if you don't agree with the reasoning).

I saw this thread, and saw immediately it was a block issue and that someone had made the correct solution with the display:block and issues about the baseline. Then you added a long and complicated post about cascade which was wrong (nothing wrong with that), then I added a short succinct explanation of the baseline and block to clear things up.

Then finally, you decided to ignore the best solutions from more advanced users - which is disrespectful - when you took it upon yourself to 'wrap things up' with an 'informal best practice' which itself mentioned things like slices etc with the trivial solution of setting a height. (trivial in the context of the original problem). This is what lacks grace.

And now we have
"The closest example I can apply to prove my point is for certain CSS styles with a static WIDTH must be declared to render properly. This situation reminded me of that."

Well, width is not height and their usage is very different, so this does not 'prove your point' at all, and is misinformed and confusing to link the two.

I didn't have any problem with the fact that you decided to post what you felt was a good solution. However, you phrased it in such a way that it was the final say and the best practice, coming after earlier mistaken explanations. Hence, my comment was more direct than it normally would be. Sorry if it upset you. Keep learning and posting, but I'd suggest that until your CSS has improved somewhat to leave it to the readers and other to decide what is the 'wrap up' or 'best practice'.

[SrWebDeveloper]

Unbelievably, you misquoted AGAIN.

Here is the original quote, left intact, in context to what I was talking about at the time --- myself (not others):

This is getting silly, I admit it, but one thing is for sure -- the fixes stated work, regardless of the confusion I might be having as to cause! I think I contradicted myself about 3 times, just trying to grasp what's going on "under the hood". I'm interesting in finding out, if anyone at this point gives a crap and knows for sure. heh

Now I'm off subject. I'll give you and others the final word, this is getting beyond silly now

I clearly was poking fun at myself, it was self deprecating, as I had not figured out the "why". The silliness was me getting it wrong, me being off subject (not others). You misinterpreted. This is your fault, and it's 100% undeniable. Try as you might to talk your way out of this one, your abusive selective quoting habit now makes you the fool for all to see. Clearly, definitively.

Then you complain I "ignored" solutions from others, which you deem disrespectful. It would be, well, if I had!

Didn't you see me say "the fixes stated work, regardless of the confusion I might be having as to cause!" ???!!!

I told you if you misquoted me again I'd not stand for it. All you had to do was NOT quote me, you would have gotten away with the last word.

MY METHOD IS BETTER - HERE'S WHY

On a technical note, one parent div with static height is less code than leaving it out and applying vertical alignment or display to all the inline images in this static XHTML situation. Forget about "dynamic" this or that, this isn't what the OP was asking. It is 100% factual that my method uses less code to wrap div around images of a known height (OP's original code didn't use dynamic images, he set the height in the img tag).

Let's see... less code = more efficient code in this situation.

Of course this method is not effective in other situations, but I never said it would be, and the OP's code never was dynamic. For the 100th time!!!!

As to my thoughts about the width being necessary for some CSS to render properly in context to this situation, we've all seen documentation where width must be defined for situations like:


Nesting another div within a centered parent div
Converting containers to list items and using float property
Skip navigation links - MSIE needs anchors to be inside elements with a defined width due to quirks mode rendering issue
CSS rollovers using images or text as buttons - apply width to buttons to ensure the link text isn't cut offJust to name a few. All are situations where a simple width definition solves rendering problems for improved cross-platform compatibility. I've personally had experience with the 3rd (508 Accessibility lists skip nav as a "best practice") and the 4th - as most of us have being its so common. Now do you see a potential connection? I could not explain it any simpler.

You're going to disagree with this no matter what I say, you'll find a way to selectively quote, misinterpret, say I said something else, mock me for actually looking up examples, will insist they don't apply, and will call me names and tell me to get schooled. Let the people following this decide if all that is true, otherwise - put a lid on it.

Over and out (as in out for good)

-jim

[angelwatt]

...
On a technical note, one parent div with static height is less code than leaving it out and applying vertical alignment or display to all the inline images in this static XHTML situation. Forget about "dynamic" this or that, this isn't what the OP was asking. It is 100% factual that my method uses less code to wrap div around images of a known height (OP's original code didn't use dynamic images, he set the height in the img tag).

Let's see... less code = more efficient code in this situation.
...

Though I hate to add to this discussion I had to disagree with the above portion. All of the solutions given took one line of code. Your solution wasn't any less code than the other solutions. Also the OP was just a very small test case. It's hard to say where this code was being used, and thus which solution given is the "absolute" best (whatever that may mean).

As a small side note. When I used the word 'dynamic' some post ago I was talking more in fluid designs, not fixed heights/widths of images. I just mention this to clarify my usage of the word, and I don't think it really effects anything here.

[SrWebDeveloper]

In the simple one image situation, of course.

"This situation" refers to parent block level div with inline image(s), to clarify my point.

The "more advanced" CSS guru the entire time was saying to use directives on the images (plural) themselves, referring to more realistic real word scenario (which upset him when I "wrapped it up"). As a best practice, if one always did this in this situation, it wouldn't matter how many inline images when their heights are static and known - that's the fundamental point I'm making. It should not be lost in all this.

I conceded long ago in a fully dynamic situation or others, this advice would not apply. I apologize if I did not make this clear, thought I had.

-jim

[angelwatt]

In the simple one image situation, of course.

"This situation" refers to parent block level div with inline image(s), to clarify my point.

Just to kick a dead horse one more time. Below are solutions given by you and I, both applying to one or more images inside the div and both taking "one" line of CSS. (Though in my original post I didn't specifically state my solution in this detail, I just had the property and not the CSS selector.) So just referring to the simplified test case the OP gave how would your solution be more efficient? I may have missed something in the discussion that addresses this. Or possibly you thought I was suggesting adding the style to each image individually.

My solution:
#somediv img { vertical-align: middle; }
Your solution:
#somediv { height: 50px; }

[SrWebDeveloper]

Okay, beyond the test case as I've hinted all along, the developer might not necessarily want to apply the same alignment to all images within the div. The OP's issue was ONLY about the text descender gap, so any suggestions made here should have taken BOTH into consideration - a "best" solution. I applaud you on your consolidation using descendent selectors to streamline the CSS in response to the length of the code, but your method fails to recognize any implications.

Considering implications beyond the test case constraints played into my recommendation all along, angelwatt. "GURU man" hasn't proven to me he considered other implications as he never posted a CSS example like yours.

You think I'm picking at straws, grasping for dear life just to prove myself right? Maybe some folks here need to think about this some more - the simple, elegant solutions posed might not be the "best". I've still got some pride, ya know!

-jim

[macgruder]

"I clearly was poking fun at myself, it was self deprecating, as I had not figured out the "why". The silliness was me getting it wrong, me being off subject (not others). You misinterpreted. This is your fault, and it's 100% undeniable. Try as you might to talk your way out of this one, your abusive selective quoting habit now makes you the fool for all to see. Clearly, definitively."

Given your total confusion of things CSS, there is no 'clearly' when you say anything. Nice Ad Hominem fallacy (the fool is the person who has to resort to Ad Hominem to try to make a point). "this is getting silly" is 'clearly' pocking fun at yourself. Riiiight.

"You misinterpreted. This is your fault, and it's 100% undeniable." Another nice fallacy.


No, your solution is not less code, because you have to change it whenever someone changes the image size. This is thus more code, and less scalable, needing additional code if the situation is dynamic. And certainly not less code than:

{display:block}

This is the whole point. Setting heights on DIVs is trivial in the context of the problem presented - why?

So let's see:
Set height: works, if the situation is not dynamic and the image is not changed, and doesn't answer the question presented.
display block/baseline solution: works in dynamic situations, continues to work when the image size is changed, and explains the question presented. (yeah, yeah - will also trivially apply to individual images

Now, you tell me what an objective person would say is the 'best' solution here.

You seem totally desperate to present your solution as 'better' despite your admitted limited understanding of CSS. You admit your code applies only to non-dynamic code (the OP doesn't state whether the situation is dynamic or not).

And comments like this to someone who clearly knows what they are talking about: "I applaud you on your consolidation using descendent selectors to streamline the CSS in response to the length of the code, but your method fails to recognize any implications." Jeez. Demonstrate some knowledge first. Before then don't tell clearly knowledgeable people that they have failed to recognize something. Obviously, Anglewatt was referring to this test case, (and realized the developer equally might not want the height of the div fixed.)


Stop being so paranoid that people are deliberately misquoting you, and trying to make you look foolish. Forums don't convey the nuance of spoken conversation, yet they are a conversation, so there is no need to take everything so literally. (go back to the earlier part in the thread where realizing you didn't really understand the CSS I gently stated 'this would appear to be wrong).You presented a weaker solution to the problem at hand - I simply stated that it wasn't the best one (and it seems that other clearly knowledgeable people such as "angelwatt" agree) - yet you get all upset about nothing. At least you learnt something here.

"You think I'm picking at straws, grasping for dear life just to prove myself right? Maybe some folks here need to think about this some more - the simple, elegant solutions posed might not be the "best". I've still got some pride, ya know!"
Well, the simple elegant and scalable solution here is the best (the trivially easy solution of setting the height is worth a mention). But I appreciate the jest in which this comment was made. :)

[SrWebDeveloper]

Someone has to close this, somehow. Guess it'll be me, complete with parting shots AND concessions.

I'll skip over the personal stuff, but the stuff where you quote selectively is something you need to work on (I'll address my weaknesses later in this reply). If I said "I will shoot the President in a video game called Escape from New York tonight." you'd quote me as "I will shoot the President tonight." and report me to the SS for interrogation. Forums might be troublesome for inflection and tone, but they do document the words. Leaving out words, i.e. context, MATTERS. Okay, moving on to substance...

Now I know you think I'm clueless at CSS, but when I originally said the image was block level after examing the OP's CSS, I thought I was sure but didn't quite recall why. Just now, after dinner, it hit me. I saw some CSS years ago that set the margin-bottom to 0 pixels which fixed formatting issues similar to the OP's situation when it was a mostly a NS and MSIE world.

The original CSS used by the OP (who mentioned the margin setting in his comments, getting my brain working):

div.title img {
margin: 0;
padding: 0;
border: solid red 1px;
}

This *should* have made the image BEHAVE as block level (even if not reported as such). This is why I said what I said at the time, not out of complete ignorance.

The solution is to remove the extra <br>, and declare the image a CSS block-level element with margin-bottom: 0px. This way, excessive space beneath the image baseline is removed in all instances, and all browser engines are happy campers. Source (http://hownow.brownpau.com/archives/2002/05/images_as_blocklevel_elements/)


Above is just a quote shared on alot of sites about methods of making images block level that factually supports what I recalled originally. The solution quoted is actually a hack for non MSIE browsers circa 2002, but I think this reveals how some Gecko engines certainly react (even now), and the OP listed Gecko based browsers if you recall. Lightbulb finally on in my head, but of course I forgot then that images are indeed inline by default in CSS. I should have questioned myself then, ugh.

So, yep, I still screwed up, heh. ;)

(wondering out loud if margin setting to 0, Gecko browser, etc., has made you re-think your answer to the OP's question)

Now about my solution - I know your scalable solution includes dynamic situations, and I concur, but that's not even remotely related to the test case (mine is), so it should be dismissed (respectfully) from this topic. Mine seems to be holding up after much scrutiny in the context in which I presented it (for test case and similar real world). And, dammit, sometimes it is as simple as adding a static height, just the same way developers simply add static width to resolve rendering issues cross platform (and I included examples, all documented and well known, you "learnt something" there). Other solutions might implicate other changes intended by the developer, and the one single change mine makes, which you noted via "the developer equally might not want the height of the div fixed", is not in question because the entire exercise was to bottom justify the image in the div! Setting div height does PRECISELY that so it meets the demand of the test case. I even suggested 51px originally so the two red borders even align perfectly (one inside the other, pixel perfect).

You've not challenged these very specific and technical aspects convincingly in my opinion - you only challenged ME.

Probably too drained to do so -- like me, eh? ;) I understand.

Ya know, there really is nothing wrong with suggesting to users that even though the test case is very limited, the basic principles can be applied and using such and such code in those situations might make life easier. I am sorry you thought I was being disrespectful at the time, but it really wasn't intended that way. I apologize, with bowed head, for how it might have come out.

Okaaay. I'm going to let us both off our virtual hooks, we'll agree to disagree, let others read, decide, barf, whatever.

You and I should both just shut the !#$$!! up now. I'll start!!!!! :) <--- kidding with ya!!!! (been a long day)

-jim

[macgruder]

You've not challenged these very specific and technical aspects convincingly in my opinion - you only challenged ME.

It's precisely that your solution would not work with dynamic sites that I challenged. It was only your interpretation that you personally were being challenged. (for example, interpreting the word 'everything' to mean literally everything as opposed to a stressed first syllable and thus meaning something like 'all divs in situations like this'.) and some insistence of dealing with the semantics of the use of 'informal' and 'probably' etc to say you were misquoted or whatever.

I have no problem with your solution. The main thing is that is so uninteresting and really irrelevant to the original question. The original problem was a very subtle issue about baselines and block level. Of course, setting the height makes it go away but that's not what the original problem was about. It was worth a 'of course, setting the height here also works' .


Okaaay. I'm going to let us both off our virtual hooks, we'll agree to disagree, let others read, decide, barf, whatever.

You and I should both just shut the !#$$!! up now. I'll start!!!!! :) <--- kidding with ya!!!! (been a long day)

That seems the most sensible thing said in a while, so we'll leave it at that :)

[SrWebDeveloper]

Thank you for your insightful opinions and input for the technical aspects discussed in this topic.

-jim