PNG Optimization (and IE6)
posted by Kravvitz at 6:22 PM on Sun. Feb. 21st, 2010
Categories: CSS, Browsers, IE, Bugs, Optimization 0 commentsLately web page total size optimization strategies and how to make pages degrade gracefully in IE6 have been on my mind. Recently I've started using a few great programs for optimizing PNG files. Among other things, they can in many cases (depending on the number of colors used in the image and the number of opacity levels) convert PNG-24 format images with alpha-transparency to PNG-8 format with alpha-transparency — a feature that PhotoShop doesn't support (but Fireworks does). The program that actually does that is called pngout. It's a command line utility though, so I've been using PNGGauntlet and PNG Monster which are also free and provide a GUI to use pngout (and in the case of PNG Monster, other PNG optimizer utilites as well). I like PNGGauntlet's interface better, but in some cases it outputs files that are larger than the originals, which is not helpful. Also, probably due to it being a .Net app, PNGGauntlet is rather slow to start up.
Besides the smaller file size, another benefit of using images in PNG-8 format with alpha-transparency is that IE6 will render regions with alpha-transparency as fully transparent instead of the ugly grey that it shows by default with PNG-24 images that use alpha-transparency. Watch out for greyscale PNGs though. Just like with PNG-24s, IE6 doesn't natively support transparency in greyscale PNGs either. I've been using TweakPNG to remove unnecessary data chunks (e.g. file creation date) from PNGs for a while, and it's also great for seeing which format a PNG image is actually using.
If you want a tool that will convert a PNG-24 with alpha-transparency to PNG-8 when pngout won't, then check out pngquant, especially the improved version of pngquant by Kornel Lesinski
These tools have been available for a while (it seems both pngout and pngquant were first publicly available in 2002), but don't seem to have gotten the attention they deserve. Look for a future blog entry on partial transparency in IE.
Related Articles
Webkit Inline Element Absolute Positioning Issue
posted by Kravvitz at 10:11 PM on Sat. Dec. 19th, 2009
Categories: CSS, Browsers, Webkit, Bugs 0 commentsWebkit browsers (which include Apple Safari and Google Chrome) and Konqueror
make an absolutely positioned element be positioned below an inline element
sometimes, as if the inline element was a block element. That happens when the
absolutely positioned element is automatically positioned, has display:inline,
and follows the inline element which takes up the full width (or almost the
full width) of the parent element. Take a look at the following five examples.
(To be clear, it's the third and fourth examples that are displayed differently
in Webkit browsers.) Then we'll take a look at some solutions.
Examples
Normal Inline Element
Image Element
this is an absolutely positioned element that's positioned automatically
Full Width Image Element
this is an absolutely positioned element that's positioned automatically
Full Width Inline-Block Element
width:100%
this is an absolutely positioned element that's positioned automatically
Block Element
display:blockSolutions
Some ways to get browsers to handle this more consistently are to give the
sibling inline element display:block (like in the 5th example),
float:left, or float:right. However, the float fix
doesn't work correctly in Opera, Konqueror (tested in 3.5), and Safari 1.0
(I have access to neither 1.2 nor 1.3 currently, but it does work in Safari 2+).
Alternatively, one could give the absolutely positioned element
display:block, but IE5-7 won't render that differently so it's not
the best for cross-browser consistency. Lastly, one could, of course, specify
explicitly where the absolutely positioned element should be positioned (with
the top and left properties, for instance), which often entails giving an
ancestor (which could be the parent, of course)
position:relative to create a new positioning context. So, to
summarize, the first (shown above) and fourth/last fixes are best for
cross-browser compatibility.
Floated Image Element
this is an absolutely positioned element that's positioned automatically
Block Alternative
this is an absolutely positioned element that's positioned automatically and
has display:block
Explicitly Positioned
this is an absolutely positioned element that's explicitly positioned
So it's interesting that in this one area at least a few versions of each of 3 of the 4 major rendering engines have a bug. (Webkit was originally based on the KHTML engine used in Konqueror, so while not exactly the same, they often have the same CSS bugs.) And in case you're interested, here's the relevant section of the CSS2.1 specs.
IE7 Collapsing Bottom Margin Bug
posted by Kravvitz at 9:59 PM on Sun. Dec. 6th, 2009
Categories: CSS, Browsers, IE, Bugs 0 commentsIn IE5.5-7, an element that has "hasLayout" and has a bottom margin will sometimes wrongly collapse its bottom margin through the bottom edge of its parent (but not its parent's parent). This happens when its parent has bottom padding and/or a bottom border (which should prevent the margin from collapsing) but not "hasLayout", and at the same time the parent's parent has bottom padding, a bottom border, and/or "hasLayout".
The solution is simple. Simply trigger "hasLayout" on the parent element or remove the "hasLayout" trigger on the element itself.
A Third Cause of IE miscalculating "left:auto"
posted by Kravvitz at 9:46 PM on Sat. Nov. 21st, 2009
Categories: CSS, Browsers, IE, Bugs 0 commentsIn IE5-7/Win when a left floated element immediately follows an absolutely
positioned element (whose left and right properties are not set to a value other
than the default of "auto") the absolutely positioned element will be shifted
to the right by the total width of the left floated element. (Right floated
elements don't trigger this bug in left-to-right text mode. As one would
expect, in right-to-left text documents, float:right triggers the
equivalent bug, but float:left doesn't.)
left:auto
One solution is to put an element with display:block between
them.
left:auto
Another solution is to add another element there and move either of the existing elements into it.
left:auto
Last but not least, one could just give one or both of the left and right properties a valid value other than "auto" (or "inherit").
right:0
PNG Images, Partial Transparency, and IE
posted by Kravvitz at 8:14 PM on Sun. Feb. 28th, 2010
Categories: CSS, JavaScript and DOM, IE, Bugs, Optimization 0 comments