File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DIV causes extra line break if a background color style is added?

 
Joe Vahabzadeh
Ranch Hand
Posts: 140
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, I've verified this on IE9 and Firefox 10.

I am writing a few classes that will allow for customized reports being displayed to the screen. So, the HTML is generated by a Java program. Some styles are always there, and some are dynamically generated, so the resultant HTML references a .css file, as well as defining additional styles in the HEAD portion.

Here's the CSS I've got:


Here's the HTML I'm working with, note that it has some internal styles :


Now, here's the conundrum.

1) Note the BR tag between each DIV block. That is required because of the absolute positioning. If I didn't include it, the DIV blocks would display over each other (ie: same absolute vertical position), making an unreadable mess.
2) HOWEVER, note the "tint1" for some of the DIV elements. I have a height because if I don't, while the bold of the text remains, the background color setting will vanish!
3) BUT, having added that height, I now have extra space, as if the display was showing a sort of double-spaced format for just that line, and eliminating the BR will cause things to display as I want.
4) FINALLY, if I remove the "tint1" style from the DIV, everything is fine. Well, except that I don't have the background color.

In an ideal world, I'd like to be able to have positioning such that vertical is relative, and horizontal is absolute, in my generated styles, so that I don't have to deal with some of this monkey business.

In the real world, I want to be able to change the background color (noted with the "tint1" style) without having to specify a height attribute in the style, and thus having to worry about whether I should check for an overridden background and have to determine if I need to skip the BR tag.

Why am I getting the behavior I am? How do I solve this problem?

Thanks in advance.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64178
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well first of all, all that absolute positioning is really poor CSS. I'd try to simplify the layout without resorting to absolute positions. The fact, that you need to jump through so many hoops to get what you want is a clear sign that the approach is failing.

I would back-track and try to achieve your layout using non-absolute layout rules and using margins and padding to get the spacing you need.

But that said, tint1 not only applies a background color it also applies dimensions, so why would you expect the background color to be the culprit?
 
Joe Vahabzadeh
Ranch Hand
Posts: 140
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you mean the "width: 100%" when you say it applies dimensions?

I added the "height: 1.25em" because without it, the background color would be ignored.

So, I should probably clarify - the style is causing the issue, not specifically the background color. My intent, however, is only to use the background color if at all possible.

Ideally, I'd like to use neither the height nor the width.

I can, it seems, eliminate the width and have no changes in behavior. Elimination of the height, however, causes the background color NOT to be applied.


As an aside, I'm working on a relative-positioning alternative, though my success has been rather limited so far.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64178
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The refactor is where your effort needs to be spent -- not on trying to "fix" the absolute approach.

It's sort of like a bad drug interaction issue. Drug #1 solves an issue, but causes water retention, so a second drug is prescribed that causes urination, but it has a side-effect of drowsiness, so an amphetamine is described, but that makes the patient jumpy, so an anti-anxiety drug is added, but that has the side effect of depression, so an anti-depressant is prescribed... and on and on and on.

 
Joe Vahabzadeh
Ranch Hand
Posts: 140
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Basically that's what I'm working on . . .

However, sort of digressing, now I'm a little baffled by the behavior in general - or in how DIV interacts when it contains only SPAN items.

I figured that the reason I wasn't seeing the background color when I didn't have "height: 1.25em" inside the "tint1" style is because, for all intents and purposes, the browser treats the DIV as if it has no height whatsoever. The SPAN elements do not alleviate this, although if I put text in the DIV itself, that does work. Why is that? Will I run into the same problem even using non-absolute positioning?


I also didn't catch this before, but it appears that, while "font-*" styles in a DIV element get applied to its children (the SPAN elements), such as font-weight: bold, it seems that "text-*" styles do not. Say, for example, I change one of my CSS styles (which is added to the DIV) to:


I would've expected that there'd be an underline across the entire width of the DIV, or, barring that, at least it being applied to all the text contained in the SPAN subelements of the DIV... but it's not.


Is there some sort of guide somewhere that explains what styles will get applied to the sub-elements, and what won't?
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64178
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe Vahabzadeh wrote:all intents and purposes, the browser treats the DIV as if it has no height whatsoever.

Incorrect. By default, a <div> has a width and height of auto which makes it as wide as its container and as high as it needs to be to contain its content. The major thing that affects this is if the content is taken out of the normal flow with positioning other than static or floating.

Will I run into the same problem even using non-absolute positioning?

No. "Normal" content will give the <div> the height it needs to contain it.

but it appears that, while "font-*" styles in a DIV element get applied to its children

Some CSS properties are inherited, others are not. A good CSS reference will tell which do and which don't.

 
Joe Vahabzadeh
Ranch Hand
Posts: 140
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, got it! Thanks for the clarifications, that helps a lot.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64178
83
IntelliJ IDE Java jQuery Mac Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Too cool!
 
Consider Paul's rocket mass heater.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic