xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Muench" <smue...@us.oracle.com>
Subject Re: [proposal] Better look and feel
Date Mon, 03 Jan 2000 19:09:14 GMT
One simple trick is to not use <pre> for sourcecode
but instead use an XSLT named template for format
code blocks as:

 -> Monospace font
 -> With <BR> tags everywhere the sourcecode has

This way, HTML wrapping works but if the window
is wide enough, the line breaks reflect what the
source code has.

I posted a sample of this solution on xsl-list in
the last week if that comes in handy...

Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
----- Original Message ----- 
From: "Thomas B. Passin" <tpassin@mitretek.org>
To: <general@xml.apache.org>
Sent: Monday, January 03, 2000 10:58 AM
Subject: Re: [proposal] Better look and feel

| Stefano Mazzocchi wrote"
| >I personally love the xml.apache.org web site but there is still
| >something we can do to improve it.
| >
| <snip/>
| >2) the table used have fixed size. While this allows faster page
| >rendering, it is very painful to adopt when source code fragments
| (using
| >HTML <pre>) are used. This screws up the pages in a very unpleasant
| way.
| >
| It is important to minimize the need to scroll horizontally to see
| unwrapped lines. Too bad it's confusing to word-wrap source code.  But
| you can't really control what font sizes users will be using (even with
| CSS you can't be sure), so a perfect solution is impossible.  One
| approach - provide a button that opens a new window with the source code
| nicely formatted.  Then the user has the choice to see a better
| formatting if desired.  This can be better for printing, too.
| >There are solutions:
| >
| >- adopt flexible tables: slower to render but better looking, also for
| >distributed HTMl documentation.
| >- adopt frames: much faster to render, they same bandwith, they
| simplify
| >the stylesheets. Problem is the use of javascript to allow updating of
| >two frames with a single menu click. And browser "back" is also
| screwed.
| >
| No problem having javascript update two frames at once - but they
| shouldn't be the same frame that contains the javascript or the script
| will get overwritten (probably before it's finished).  I have sometimes
| used a very small (like 2-pixels high) frame to contain the javascript.
| The browser back button is more of a problem, but you should be able to
| tinker with the top-level history- using javascript- to get it right.
| Or ignore it and provide good navigation features for people to use when
| they find out the back-button acts weird.
| >??? any suggestion?
| >
| >
| >3) the DTD used to write and generate the documentation should be
| >site-wide. I propose to start a "DTD project" that should take care of
| >DTD definition. when a project has particular needs, it should propose
| >them to the project rather than write their own style.
| >
| >This allows better DTDs to be developed and styles to be reused on a
| >site-wide basis.
| >
| >Please, vote.
| I would vote a +1 for (3) if I had a vote.
| >
| Tom Passin

View raw message