Controlling font size accurately across browsers
Andy Dingley
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)
C A Upsdell
> 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; }
Andy Dingley
<""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)
C A Upsdell
> 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
Works for me with IE6. Don't know about IE7.
Martin Geisler
> 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
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.
--
Martin Geisler GnuPG Key: 0x7E45DD38
PHP EXIF Library | PHP Weather | PHP Shell
http://pel.sf.net/ | http://phpweather.net/ | http://mgeisler.net/
Read/write EXIF data | Show current weather | A shell in a browser
C A Upsdell
> Andy Dingley <din...@codesmiths.com> writes:
>
>
>>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
>
> 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.
Andy Dingley
<""cupsdellXXX\"@-@-...@XXXupsdell.com"> wrote:
>Martin Geisler wrote:
>> 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]-->
>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.
C A Upsdell
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.
Jukka K. Korpela
>> <!--[if IE]>
>> <style type="text/css"/>
>> ... your IE rules here ...
>> </style>');
>> <![endif]-->
- -
> 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/
Martin Geisler
Browsers will normally not refetch the stylesheets on every request,
so I don't think performance should be the reason for not using
several files. And if they do, then sending an Expires header (could
be short, like 10 minutes or so) should make them back off.
Martin Geisler
> C A Upsdell <""cupsdellXXX\"@-@-...@XXXupsdell.com"> wrote:
>
>>> <!--[if IE]>
>>> <style type="text/css"/>
>>> ... your IE rules here ...
>>> </style>');
>>> <![endif]-->
> - -
>> 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.
Which is why you can limit which versions of IE will react to it:
<!--[if IE lt 7]>
... something for IE version < 7.
<![endif]-->
Microsoft has some documentation online:
http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp
> I have some difficulties in understanding the "/>" vs. ">" as well
> as the poor lonesome apostrophe, too, but I guess they were just
> typos.
Ups, ups! You're right, those are of course mistakes! I copied this
little snippet from a recent project in PHP of mine, and I didn't
clean it up completely.