Where is the gap under an image coming from?

[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 off

Just 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

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