Sizing of <pre> and {@code with current jdk8 css

[Martin Buchholz]

You're not the only one annoyed by the giant sample code font.  I agree
with you that the "regular" text should be regular text size, and the
sample text not too much different - that's why we have different fonts!
 CSS owners, please fix!


On Mon, Jul 22, 2013 at 4:14 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> I have been working on javadoc for the JDK 8 lambda streams feature and
> ran across some interesting quirks in the current default javadoc css.
>
> We have been using the construction
>
> <pre>{@code
>    ...
> }</pre>
>
> for block examples. We add the {@code} to the normal <pre> block to avoid
> having to use html entities within the sample to escape the "&" and "<"
> characters. This makes the examples easier to read in the original source
> file.
>
> The formatting of a <pre> block and a <pre>{@code block is slightly
> different as a result relative sizing and nesting.
>
> The <pre> tag sets the font-size to 1.3em (stylesheet.css, line 31)
>
> The <code> tag (emitted by {@code}) sets the font-size to 1.2em
> (stylesheet.css, line 55)
>
> When nested the effective size is default * body (76%) * 1.3 (pre) * 1.2
> (code).
>
> It would be nice if {@code} nested inside <pre> didn't increase the size.
> Using relative sizes is generally going to be weird whenever nesting occurs
> especially if it can occur in more than one order.
>
> Could <pre> and <code> be made to use the same size?
>
> Might it be better to use "<pre>{@literal ... " than "<pre>{@code ..." as
> {@literal doesn't add any styles?
>
> Out of curiosity:
>
> - Why is the default body size 76% of the default text size? The 100% size
> is supposed the user's comfortable reading size. Other than for "fine
> print" why would we want to force a size smaller than that?
> - An explicit font selection is made for body copy but none is made for
> code/pre text. Why not? Choosing a code font would allow better matching of
> the size of the body copy and mono space text. It would appear that for
> Arial/Courier that a 1.05em ratio is somewhat better than the 1.2em
> currently used.
>
> Thanks,
>
> Mike
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20130724/a6c11a3d/attachment.html