[plt-scheme] Re: Scribble formatting dilemma

For the most part, I do agree with your opinions.
The scribble.css also uses proportional font sizes
just as you suggest.

After some more fooling around, I figured that it is
indeed Firefox's bug .. and a pretty obvious one at that.
If I use -

body { font-size: 80%; }
table p { font-size: 80%; }

Firefox incorrectly renders the body text and the table contents
at the *same* font size. IE renders the table text smaller than
the body text, obeying the cascading of the percentages correctly.

To add to the problem, I think IE is picking roughly the same sizes
for fonts in different families whereas Firefox is selecting different
font sizes for different families - for example at the default
font size, the serif and monospace font is smaller than sans-serif
font.

Anyway - this disucssion has gone beyond the scope of plt-scheme,
so I'll see what the mozilla folks have to say about this.

Thanks for your suggestions.
-Kumar


On Mar 4, 1:22 pm, Neil Van Dyke <n... at neilvandyke.org> wrote:
> My short answer to your question is that I think you will have to dig
> into the CSS to get the font sizes cooperating, but that you will also
> run into some hard constraints of the HTML layout currently used by
> Scribble.
>
> For my long answer, here are some of my opinions on Web page layout.  
> They are somewhat strong, but I know Scheme people are accustomed to
> everyone having strong opinions... :)
>
> Almost no one gets HTML layout right, since the first versions Netscape
> Navigator and IE.
>
> The best way is to start by assuming that the user's default font is set
> to the user's preference for body text on the device in use.
>
> Most important is the user's font *size* preference, although one is
> forgiven for forcing sans-serif, since historically many browsers
> default to serifed, which few people like on current screen technology.
>
> Once you assume the user knows what size font they like, then font sizes
> of headings and such can be defined by percentages relative to the
> user's body font size.  For example, a first-level heading might be
> 200%.  You might to 90%-95% for fixed-width text.  Small print could be 80%.
>
> In tables, generally just use the default body text size.
>
> Embedded pixmaps are not a completely solved problem, but in practice
> they work out OK if you just target them at a roughly appropriate pixel
> size for desktops and laptops.  The portable devices tend to shrink them
> anyway.
>
> Fixed body text column widths should not be used unless you are really
> sophisticated with the JavaScript enough to make it adapt to changing
> font size and browser window width.  The only reason to do this is to
> enforce a *maximum* column width, since HTML is especially stupid about
> this.  (HTML evolution got sidetracked by table-based layout for a decade.)
>
> Minimum body column widths should almost never be specified.  It is not
> your place to say that the user should be required read 10 words (much
> less 800 pixels per line!), even if that means horizontal scrolling
> because the user's device is too small, or they need to use large fonts,
> or they don't wish to have the page consume all their screen real
> estate.  Necessarily fixed-width layout chunks, such as for code
> examples, can be put in a "div" with automatic scrollbar on horizontal
> overflow.
>
> On my TODO list is to develop and publicize an example for that adaptive
> maximum column width problem.  Conceptually, it is trivial.  There is
> just some headache with cross-browser testing of JavaScript.  By
> default, then, until you can't do max widths in a smart way, it is
> better not to do them at all.
>
> Also, I might be doing a little experimental tweaking to Scribble CSS
> and HTML output myself, once I have finished converting all my Scheme
> code documentation over to Scribble.
>
> Neil
>
> --http://www.neilvandyke.org/
>
> _________________________________________________
>   For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme