W3C home > Mailing lists > Public > www-style@w3.org > April 2003

Re: Columns and other layouts

From: Coises <Randy@Coises.com>
Date: Mon, 28 Apr 2003 04:59:25 -0700
To: www-style@w3.org
Message-ID: <3ukpav011psamrvb9drjdg9apdmcjqm47t@4ax.com>

[Sun, 27 Apr 2003 18:57:59 -0700 (PDT)] Ian Hickson:
>So far, though, nobody has suggested any way of expressing the "simple"
>constraints that Coises gave in his e-mail. The truth is that these are
>actually incredibly complicated, both to specify and implement

Indeed... which, in a way, is one of my points.  One of the things a good
computer language does is map what is elementary in "design space"
to straightforward expressions in "language space."  The design and
implementation of a language that does that may not be simple at all.

Why are "object-oriented" languages (like C++, ECMAScript or Visual Basic)
an improvement on "structured programming" languages (like Algol or PL/1)?
They allow us to express the ideas behind our programs in terms that are
more akin to the ideas themselves.  They also tend to lead us to formulate
our ideas in more robust terms than do structured languages.

Following, I'll try to make some preliminary stabs at how the problems
I suggested might be made manageable by a web page formatting language.
These are not well-researched, and doubtless contain many flaws...
this is just a jumping-off point. 


|| 1. If the centered title at the beginning of this page will fit on one
|| line, it should be shown on one line; if it requires two lines, the break
|| between lines should be such that the two parts are approximately equal
|| in horizontal measure.

There are two approaches to this, depending on the degree of control
desired.

The simple approach --- taking the problem statement literally --- would
be to have a rule such as:

     H1 {!minimize: height, width}

indicating that, after initially laying out the block, the width should be
minimized without changing the height, or any other CSS-2 properties that
are implicitly or explicitly specified.  (Height is minimized by the
standard layout algorithm; it is mentioned explicitly since it would
usually *not* be specified, either implicitly or explicitly --- "auto"
really doesn't count as a specification in this sense, as it effectively
indicates the absence of a specification.  Great care would be needed
to assure such details would result in behavior that is both consistent
and useful.)

In practice, the problem is likely to be more complex.  Usually there are
"good" and "bad" places to break a short sequence of words, like a title
or a heading --- as a page designer, I'd like to be able to specify what
sets of breaks are preferred.  For example, suppose I have this title:

    The care and feeding of foo-bar and its place in a non-bar world

to be placed at the top of a page.  I don't know if it will fit on one
line.  I know I don't want to see this:

    The care and feeding of foo-bar and its place in a
                      non-bar world

(which hopefully everyone can see is just plain ugly).  If I had to have
two lines, I'd probably want:

     The care and feeding of foo-bar
    and its place in a non-bar world

but if I needed three lines, I'd probably want:

       The care and feeding
     of foo-bar and its place
        in a non-bar world

(and certainly not some travesty like:

      The care and feeding of foo-
     bar and its place in a non-bar
                 world

which, again, is just ugly).

Now, were I working in a WYSIWYG medium, this would be easy: I'd just
/look/ at the result and add "hard returns" if I didn't like it.  That
won't work on the web, though: because what I see isn't what my viewers
will see.  I have to step back a level and write my design logic --- not
my conclusions under a particular environment --- into the page.

The answer to this problem, it seems to me, must be the ability to specify
different levels of "comfort" for line breaks.  I know that even when
writing plain text prose like this, I frequently add hard returns just
to avoid bad line breaks --- as in this text, in which my mail program
would have separated "to" from "avoid": that would have made the sentence
subtly harder to read.  At present, we have only three options:
     <BR> --- always break
     &nbsp; --- never break
     space --- optional break

Suppose I could write something like this:

     <H1>
     The care and feeding
     <*BR PRIO=2>
     of foo-bar
     <BR PRIO=1>
     and its place
     <*BR PRIO=2>
     in a non-bar world
     </H1>

to say that I'd prefer no break; but if a break is needed, between
"foo-bar" and "and" is the best place to put it; and if more than one
break is needed, the "PRIO=2" places should be tried first?  That would
let me express the same logic I'd use to format a WYSIWYG page in an
environment where IDKWYWG ("I don't know what you will get").

(Yes, I know that's not CSS.  I'm not convinced the answer to all problems
of web page design lies in CSS.  I do think it *must* lie in HTML+CSS that
degrades gracefully under older browsers, or else it's no answer at all.
The code above is meant to degrade to a forced break into two lines ---
hoping that will cover most cases reasonably well under browsers that
don't support the contemplated syntax.)


|| 2. The section headings on this page should be distinctly larger than the
|| paragraph text that follows them, but visibly smaller than the main page
|| heading.  They should all be the same size.  Within those constraints, the
|| section heading size should be chosen so that as many of the headings as
|| possible fit on a single line.

Taking the statement of the problem literally, the last condition
could be replaced by the statement that the font size should be
as small as possible to satisfy the prior constraints (it doesn't say
that's what's wanted, but it doesn't say it isn't, either):

H2 {!range font-size: P.text:font-size++, H1:font-size--}
H2 {!minimize: font-size}

If we take the problem statement to mean that the section heading size
should be (perceptually, not mathematically) about midway between
the text size and the main page heading size, but yet should "give" a bit
to try to squeeze all the sections headings onto one line each, things
definitely get more complicated.

(I think I'll pass on that one for the moment... but I do think it
represents a reasonable bit of design logic.)


|| 3. I have a graphic to be set left, with a couple paragraphs of text set
|| to the right.  There is a caption for the graphic.  If the caption will
|| fit at the right --- beneath the other text and not extending below the
|| bottom of the graphic --- it should be set right and aligned with the
|| bottom of the graphic; if it will not fit, it should be set /below/ the
|| graphic.  In no case should it be to the right yet extend below the
|| graphic, nor should it wrap with some of the caption to the right of the
|| graphic and some of the caption below it.

There are several ideas I have to introduce here.  First is that it would
be helpful to be able to specify that some blocks should never be wrapped
around images, floats, etc.  This is not the same as "clear" --- it's okay
if they fit beside something else: they just should never be wrapped
around something else.  They need to be in a solid rectangular block.

I certainly could have missed it, but I don't think any CSS2 property
or CSS3 module allows me to specify that.

Alas, there is a second, trickier element to this problem: if the caption
is placed beneath the picture, it should be no wider than the picture; but
if it's placed to the right of the picture, it should use the available
space (which could be more or less than the width of the picture).

I can think of two ways to solve this... but I must say, I hope someone
comes up with something better than either of them, because I really
don't like either of my own ideas.

One option would be to use a TABLE for the layout, but have a way
to specify that an element in one <TD> could be moved to another <TD>
under certain conditions.  For example:

<TABLE>
   <TR>
      <TD><IMG ...></TD>
      <TD>
         <DIV>The main text beside the image.</DIV>
         <DIV NOFITROW="move: #captionunder">The caption</DIV>
      </TD>
   </TR>
   <TR><TD ID="captionunder"></TD><TD></TD></TR>
</TABLE>

to indicate that the row containing "The caption" cannot be enlarged to
contain that element: if it's not already big enough, the caption must be
moved to become the first (in this case, only) element in the cell that
has "captionunder" as its ID.

The other solution would be a kind of conditional HTML:

<IF COND="#caption:content-bottom <= #image.content-bottom">
   <IMG ... ID="image" ALIGN=LEFT>
   <DIV>The main text beside the image.</DIV>
   <DIV ID="caption" VALIGN=BOTTOM>The caption</DIV>
<!--ELSE
   <TABLE>
      <TR>
         <TD><IMG ...></TD>
         <TD>The main text beside the image.</DIV>
      </TR>
      <TR>
         <TD>The caption</TD>
         <TD></TD>
      </TR>
   </TABLE>
ENDIF-->

(Of course, VALIGN=BOTTOM doesn't work on DIV, but I trust we all see
that's not the major issue here.  I hate both of these solutions.
Something better is needed, but it's not to be found in my head just now.)


|| 4. I have three classes of text to set on my web page:
||      a. Running Text in Paragraphs: this should be of a size that is the
||         best compromise between being large enough that the user can read
||         it easily, and small enough to keep from making the user page down
||         more than necessary.
||      b. Section Titles: these should be clearly distinguishable from the
||         running text, but not so large as to be jarring.  They should be
||         convenient guides for the skimming reader to find the parts of the
||         text that are most interesting.
||      c. Legal and Technical Notices: these should be as small and
||         unobtrusive as possible without being illegible.
|| What "font-size" should I specify for each class?

The problem here is that no useful meanings are assigned to the font-size
keywords.  What the heck does "medium" mean (other than "larger than small
and smaller than large")?  If the user has a preferred size for running
text (text in paragraphs that goes on at some length), I want to know what
to specify to get that size.  (And I want it to adjust to the font ---
some fonts look huge at, say, 12pt, while script fonts may be barely
legible at the same size.  The font-size-adjust property apparently tries
to get at that, but in practice I can't see how to use it.  Most often, I
care about the subjective appearance of text, not the actual metrics.  How
do I say, "Show this in the user's preferred script font at a size that
matches the surrounding text in appearance"?)

What I'd like to see here is a set of font-size keywords that have
normative meanings related to their use in page design.  For example:

     running-text:  the user's preferred size for text in paragraphs
                    (recommended where ease of reading should be maximized
                    balancing the size of text with the required space)

     fine-print:    the smallest size in which the font remains legible
                    (recommended for legal notices, etc., which are
                    normally not read by anyone but need to be present)

     small-text:    a size recognizably smaller than running-text but
                    still easily legible (recommended for captions,
                    quoted material, footnotes, etc.)

     key-text:      the user's preferred size for text that should be
                    maximally legible in short phrases, where space is not
                    generally a consideration (recommended for quotes from
                    a following paragraph, "teasers," section headings,
                    etc.)

     headline:      the largest font-size the user would generally prefer
                    to see (recommended for <H1> elements)

If one needed <H1>-<H4> elements plus key quotes, a definition something
like this:

     H1     {font-size: headline}
     H2     {font-size: percept(2/3,key-text,headline)}
     H3     {font-size: percept(1/3,key-text,headline)}
     H4     {font-size: key-text; font-weight: bold}
     P.quot {font-size: key-text; font-style: italic}
     P.text {font-size: running-text}

might do the trick.  (The "percept(m/n,x,y)" notation is meant to indicate
some way of saying "a value which has the perceptual effect of being about
m parts in n from x towards y.  The above distributes the font sizes for
the four heading types between the headline size and the key-text size so
as to appear to be an even gradation to the viewer.)

The standard would /not/ define the numeric relationships between these
sizes: it would be up to the user agent to support definition of these by
the user, and to supply reasonable defaults where the user has not made
individual selections.  The values might be different for different fonts.
What the standard /would/ indicate is how they should normally be used, so
that users can set values for each and expect that properly-authored pages
will use the sizes they find most comfortable.

(In practice it might be desirable to have a level of qualification
that would let the author be sure that the H1 and H4 sizes chosen are
far enough apart to make the intermediate levels distinguishable, and
possibly to scale down the H2 and H3 sizes if the headline size is too
much larger than the key-text size.  Once again, I'm going to pass
on constructing an illustration of that at the moment.)
-- 
Randall Joseph Fellmy aka Randy@Coises.com
Received on Monday, 28 April 2003 07:59:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:21 GMT