Forum How do I...?

CSS image float problem

mynhardt
Hey guys

I have to admit when it comes to CSS I'm still a newby.
Someone else wrote CSS styling for the HTML document
using CSS 2.0.

When viewing the HTML template through a browser the images are floating
correctly but when converted to pdf the images are placed
over each other, floating it seems does not occur.

The images are enclosed by div tags. All the css styling used
is supported by Prince according to the documentation.

Help would be greatly appreciated
mikeday
If you send us the document or post a link to it then we can take a look and see what is going on.
mynhardt
We are checking out other possibilities that might have
caused this issue. One is that maybe the images are two big to
be floated next to each other. Never thought of that :oops:.

If we are still having issues I will let you know
Thanx
StoneCypher
It seems you've disappeared, which means that most likely the fitting the container problem was what stopped you. However, for other people who encounter this issue where that is not the case, here are some other possibilities:

1) The clear: property is meant specifically to cause floating to occur a line down. See if it's being applied by the rule or an inherited rule. Remember to check clear not only on that element, but also the element before and/or after it, as appropriate.

2) Technically speaking, if you put float: left on a tag, that implies it is also position: float. However, if you set position: afterwards, behavior is no longer floating behavior. People who attempt to use display: table-cell or display: inline-block to circumvent browser bugs will find that that hack will prevent the correct rendering of the document by the more advanced renderer in PrinceXML, which as a result of its higher support for CSS is unfortunately also more sensitive to badbear hackery. On the bright side, a CSS ninja notes that this is generally easily contained by providing a seperate stylesheet for printing, unless you are in the seventh level of Dante's Inferno, the IT department that has to support HTML printing in browsers. At that point, nobody can help you but Doctor Strychnine.

3) Please remember that container padding is supposed to be applied to contained floating elements. Of the browsers, only Mozilla and KHTML descendants like Safari get this right. PrinceXML gets this right, but if you did your initial development in Opera, which is the browser with the best printing support, you may find Prince's superior support causing unexpected behavior which seems to be a bug. It may be that the containing area is simply smaller than you expect.

4) If you're counting pixels to fit things, please remember that PrinceXML's base style sheet is stricter about whitespace in XML than are most browser stylesheets. Thus, if you find your images fit when the container is set just barely larger than you think it should be, try setting the CSS whitespace control properties, or get the flamethrower and burn the whitespace out.

5) Yell at it really, really loud. That usually fixes things.

Good luck.

John Haugeland is http://fullof.bs/

StoneCypher
6) It may behoove you to read up on pixel scaling in CSS2 and CSS3 print specification, especially if you are attempting to mix relative units like em, ex, percent and so on; whereas they generally behave as one might expect, there are occasional situations in which interactions are inobvious, and thus a familiarity with these rules may clear up several more difficult situations.

These details are frustratingly difficult to track down in the CSS specifications, which are otherwise remarkably easy to read. The fundamental clue is that pixels are in fact considered a relative unit, not a concrete unit; there is the pervasive concept of the scale of a logical pixel to the device, something with which SVG, Flash and Postscript programmers will be intimately familiar. In CSS2, the terms are "specified, computed and actual values."

http://www.w3.org/TR/CSS2/cascade.html#q1

In CSS2.1, a fourth state, inbetween computed and actual values, "used value," was added to clarify the computation process.

http://www.w3.org/TR/2004/CR-CSS21-20040225/cascade.html#q1

PrinceXML has expanding support for CSS3, and so the CSS3 positioning model is probably also worth learning.

http://www.w3.org/TR/css3-page/#renderingpages

Of the media types, print, tv, handheld and projection are almost always logical pixel scaled. (This is why CSS is okay with measurements in fractional pixels.) Screen is beginning to be logical pixel scaled, as an alternative to resizing the base font, which gives better scaling support for pages with naive CSS, and allows the images and so on to scale with the text. Currently, Opera and IE take this approach (Opera has had it for a long time; IE just got it.) Opera deploys this behavior on many platforms, including cellular phones, the Nintendo DS and Wii, and (shudder) Macintoshes, in order to save room on their puny, toy-like screens.

The media type "all" is unlikely to ever be pixel scaled by default in any browser, except in personal configurations, which may be likely for people with visual or perceptual handicaps. The remaining media types, braille, embossed, aural and tty, have no sensible interpretation of scaling and are thus unlikely to ever see pixel scaling in any form.

John Haugeland is http://fullof.bs/