I have a large commercial site to rebuild, where the design has been
produced by the pixel-counting method. It's also one of those sites
where cramming every space full of content is seen as better than a more
spread-out and usable design that uses some scrolling. Not surprisingly
it's the work of paper-based magazine designers, not web designers.

This leaves me with several conflicting requirements:

- The body text size for the "article" pages should be 1em, for
well-known usability reasons.

- The "index" pages may require pixel-based font sizing control,
because otherwise I can't constrain the text to fit in the available
space. These spaces are fixed pixel widths - they're usually the size of
a bitmap image. Additionally they're often "headline text" which means
few short words and some clunky behaviour for linewrapping.

- It must work cross-browser, including IE6 and IE/Mac


The real problem here is that IE blows the whole lot apart.  With its
well-known problems of an excessive default scaling for ems to pixels, I
can produce a good implementation for the well-behaved browsers (even on
the Mac) but any IE rendering of the page only works when the user's
text size is reduced to "Smaller". This is particularly bad if I attempt
to use <h*> markup, where the differences are particularly visible.

Any suggestions ?

Are there any "CSS hack" based techniques which will let me set a
default size of 1em/100% for web browsers, then an 85% value for IE
only, hidden by some parser hack ?


(I am _not_ interested in a discussion of em vs. pixel sizing - that's a
different issue)

Andy Dingley wrote:
> I have a large commercial site to rebuild, where the design has been
> produced by the pixel-counting method. It's also one of those sites
> where cramming every space full of content is seen as better than a more
> spread-out and usable design that uses some scrolling. Not surprisingly
> it's the work of paper-based magazine designers, not web designers.

> The real problem here is that IE blows the whole lot apart.  With its
> well-known problems of an excessive default scaling for ems to pixels, I
> can produce a good implementation for the well-behaved browsers (even on
> the Mac) but any IE rendering of the page only works when the user's
> text size is reduced to "Smaller". This is particularly bad if I attempt
> to use <h*> markup, where the differences are particularly visible.
>
> Any suggestions ?
>
> Are there any "CSS hack" based techniques which will let me set a
> default size of 1em/100% for web browsers, then an 85% value for IE
> only, hidden by some parser hack ?
>
> (I am _not_ interested in a discussion of em vs. pixel sizing - that's a
> different issue)

body { font-size:85%; voice-family: "\"}\""; voice-family:inherit;
font-size:medium; }

On Sun, 18 Sep 2005 12:33:59 -0400, C A Upsdell
<""cupsdellXXX\"@-@-@XXXupsdell.com"> wrote:

>body { font-size:85%; voice-family: "\"}\""; voice-family:inherit;
>font-size:medium; }

But isn't that (the Tantek Celik hack) just going to work on IE5 ?   I
need to make it work on IE6


(By some bizarre logic, I don't actually need to support IE5 / PC as my
boss won't be testing for that, but he will be carefully testing the
almost unused IE5/Mac combination)

Andy Dingley wrote:
> On Sun, 18 Sep 2005 12:33:59 -0400, C A Upsdell
> <""cupsdellXXX\"@-@-@XXXupsdell.com"> wrote:
>
> 
>
> But isn't that (the Tantek Celik hack) just going to work on IE5 ?   I
> need to make it work on IE6

Works for me with IE6.  Don't know about IE7.

Martin Geisler wrote:
> Andy Dingley <dingbat@codesmiths.com> writes:
>
> 
>
> Wouldn't it be easier to use a documented features of IE then: the
> conditional comments?  Like this:
>
>   <!--[if IE]>
>   <style type="text/css"/>
>   ... your IE rules here ...
>   </style>');
>   <![endif]-->
>
> I find this approach much better than relying on various parsing
> errors in IE to get things right.  Using a comment which will be
> ignored by all browsers except IE is much cleaner.

This requires a separate stylesheet for IE.  There is some advantage to
having everything in one stylesheet.

We'll have to see what IE7 does with this.

On Sun, 18 Sep 2005 17:42:53 -0400, C A Upsdell
<""cupsdellXXX\"@-@-@XXXupsdell.com"> wrote:

>Martin Geisler wrote:
 

>This requires a separate stylesheet for IE.

Not necessarily - I could inline the stylesheet into the page HTML.  All
the pages are auto-generated by XSLT, so this would actually be quite
easy to do  (if <xsl:comment> can generate that fragment)

As a performance issue I want to avoid the number of separate documents
to be retrieved, but I can live with a few lines added to each HTML
document.

Andy Dingley wrote:
> On Sun, 18 Sep 2005 17:42:53 -0400, C A Upsdell
> <""cupsdellXXX\"@-@-@XXXupsdell.com"> wrote: 
> 
>
> Not necessarily - I could inline the stylesheet into the page HTML.  All
> the pages are auto-generated by XSLT, so this would actually be quite
> easy to do  (if <xsl:comment> can generate that fragment)
>
> As a performance issue I want to avoid the number of separate documents
> to be retrieved, but I can live with a few lines added to each HTML
> document.

But this creates a maintenance problem:  a change in the CSS for IE
would then require that all the pages be updated.

Another issue is that order matters with CSS:  when putting CSS in a
single stylesheet, one can put the declarations in just the right order
to achieve the desired results; one cannot readily do so with multiple
stylesheets or with embedded CSS.

C A Upsdell <""cupsdellXXX\"@-@-@XXXupsdell.com"> wrote:
 
- -
> We'll have to see what IE7 does with this.

My bet is that for some n > 6, IE version n will still recognize the
"if IE" hack, yet process CSS more by the book than IE 6 does.
Thus, if the trick relies on "known" misfeatures of IE 6, it will break
down quite often.

I have some difficulties in understanding the "/>" vs. ">" as well as the
poor lonesome apostrophe, too, but I guess they were just typos. The sad
thing is that CSS checkers probably would not catch them, since they are
inside a comment, as far as "standards" are concerned. The construct
<style type="text/css"/> may have interesting effects, and different
effects by old (SGML) HTML rules, by XML and XHTML rules, and by tagsoup
processing.

--
Yucca, http://www.cs.tut.fi/~jkorpela/