Re: Columns and other layouts

On Mon, 28 Apr 2003, Coises wrote:
>
> || 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}

This is effectively a shrink wrapping algorithm with an initial width.

We could special case this without introducing complex minimisation stuff:

   width: shrink-wrap(100%);

...would mean "Size the element at width: 100%, then shrink it as tightly
as possible without increasing the height". (Much like the proposed
'shrink-wrap' keyword would mean "Size the element to an infinite width,
think shrink it as tightly as possible without increasing the height".)


> In practice, the problem is likely to be more complex.

Indeed.


> 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.

That's something to bring up with the UNICODE consortium, I'd say. What
you are basically asking for is for codepoints that represent the order of
breaking points on a line, much like U+00AD SOFT HYPHEN does with word
hyphenation. This (and other content-specific effects) are probably out of
scope of CSS, IMHO.


> || 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}

What does "P.text" mean in that example? Does it select a particular
element? If so, does that mean that when a user comes along with:

   *:hover { font-size: 2em; }

...and hovers over that paragraph, the headers suddenly change 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.)

I don't even have the startings of a clue about how to write a spec that
would allow that kind of expression.


> || 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.

The CSS3 Box Module will probably introduce 'float-displace' (and its
companion 'indent-edge-reset') which should help with this. A little.


> 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...

Both of your ways involve changing the markup, which is not an option,
since it is quite possible that the user will want to apply yet another
style to the document.

Let's simplify the problem.

Markup:

   <p>
    <span id="a"/>
    <span id="b"/>
   </p>

Through various stylings, the "a" element has one width, and the "b"
element another. Now if the width of "a" is wider than the width of "b",
we want "b" to get "a"'s width, and be placed under "a", otherwise we want
them to be placed side by side.

CSS, as it stands now, can't do this, because you have to do the whole
cascade in one step. So the solution needs a kind of "double cascade".
(It's the property co-dependency problem.)

We could implement this by doing the cascade, then appling some
post-cascade conditions:

   /* do the cascade */
   #a { width: ... }
   #b { width: ... }

   /* after doing the cascade, apply some post-cascade conditions */
   @post-cascade {
      /* if the width of "a" is bigger than "b" */
      (#a).width > (#b).width {
          /* make them into two rows */
          #a, #b { display: table-row; }
       }
       /* otherwise: */
      (#a).width <= (#b).width {
          /* make them into two cells */
          #a, #b { display: table-cell; }
       }
   }

Now to ensure that user styles still affect the cascade, you would
then do the whole cascade over again, with the new conditions.

The problem is that now, dynamic effects are expensive. After every
re-resolution of the style rules, the UA has to re-apply the
post-cascade rules and start over. This isn't really an option.

This needs further thought.


> || 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")?

"medium" is the user's preferred font size.


> 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)

That would be 'medium', 'xx-small', 'small', 'large', and 'xx-large'
respectively.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
"meow"                                          /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 28 April 2003 13:57:55 UTC