Re: flowing around both sides of a float Re: float:center (was: Re: Alignment property proposal)

On Mon, Dec 31, 2007 at 02:42:46AM -0500, Ambrose Li wrote:

> The question posed was whether there are use cases in *typography*,
> not in web pages. [...]
> W.r.t. whether examples in web pages exist, of course they don't exist;
> They need "float: center" to exist

Of course.  The relevance of mentioning how web sites today do pull
quotes is to show that pull quotes can be done even today.  Looking at
how pull quotes are done today helps us to judge how much benefit
allowing flowing both sides of a float brings.

Columns and floats that overlap multiple columns are in a more advanced
state of specification/implementation in CSS than the proposal currently
being discussed of allowing a single block to flow both sides of a float
(it exists as a draft spec that is to some extent implemented in e.g.
firefox, compared to a thread in this list with no proposed spec text or
implementation), and there is a more obvious call for columns to be
implemented; so chances are that there will be additional approaches to
pull quotes (including the standard layout approaches of pull quotes
used by magazines) available by the time that flowing a single block
down both sides of a float would be ready for use by CSS designers.

All I've said above and what I say below about (in)frequency of a single
block of text flowing both sides of a float and what I write about
reading difficulty and implementation difficulty doesn't show that having a
single block of text flowing both sides of a float has no use, it merely
shows that it has little use.

> As posed, there are uses cases, and there are many
> use cases even and I don't know why this is not obvious, since it is
> very commonly done in typography (and in fact I was shocked to find
>  that there is no "float: center" and this was a couple of years ago).

James Elmore says he recalls seeing examples of a single block of text
flowing both sides of a floated block; I don't recall seeing any.
I invite readers to sample a few newspapers/magazines or any other
publication you think you might find pull quotes or other floated
blocks, and report on how many you find using what approaches to pull
quotes or other floated blocks (images, tables, etc.), preferably also
commenting on the overall care of typography in that publication.

I'm at home right now, and don't have many publications on hand.  Of the
3-4 publications I looked at [two of them are related and might employ
the same designers, hence "3-4"], all had block floats, but I didn't
find a single example of a single block of text flowing both sides of a
float.

OTOH:

  - I did find one publication (in chinese) that had instances of a
    text block flowing both sides of non-block floats.  (I might perhaps
    mention that this is a local paper serving chinese readers in an
    English-speaking country, and one might well question whether the
    publication is likely to employ a skilled/knowledgable typographer.)

  - As noted, I only looked at 3-4 publications.  Other readers are
    invited to expand the sample.

  - More importantly, all the publications I looked at have multi-column
    layouts.  Multi-column is an excellent format for print media and
    e-books (which have a slow refresh rate making scrolling
    impractical), and will probably work well with many web-sites once
    CSS columns are widely implemented (presumably using horizontal
    scrolling instead of vertical scrolling), but I'd guess that there
    will still be some sites that will want vertical scrolling of an
    essentially single-column layout (not counting navigation bar or the
    like) with a column taking up most of the available width; so fairly
    wide on at least desktop displays, which James Elmore described as
    the best case for the proposal ("This works best with wide columns
    and small floats").  A few counter-points:

      - Having a wide column of text is generally not recommended by
	typographers.  (Though from memory I believe Mary Dyson's
	experiments suggest that they do have advantages.)

      - CSS designers often don't know how wide the main column or the
	float will be (uncertain display/window width, and width of the
	float can depend on user stylesheet or browser preferences);
	which at least suggests that the user agent ought to be able to
	influence where the text goes.

It's past my bedtime and I'm getting sleepy, so I should stop now.

I did say I'd write more about reading difficulty.  I mainly just
wanted to cite a typography book that recommends against it.  I don't
have the book handy to check, but I believe that the book in question is
   author={James Felici},
   title={The Complete Manual of Typography},
   year=2003,
   publisher={Peach Pit Press},
   address={Berkeley, CA}

I also said I'd mention some implementation difficulties.  They aren't
insurmountable, but they do seem to me to be a lot of work for a feature
of rather limited use.  That's not to say that it should never be
implemented, just that it should be a long way down the todo list.

I've already mentioned that bidi causes problems: you need to apply the
bidi algorithm before you know which bits of the line go which side of
the float, which in turn affects what words are included in the line
(e.g.  it can affect whether the words you initially fed to the bidi
algorithm actually end up fitting on one line), which in turn means you
either sometimes need to start again with a different set of words and
make sure you don't loop indefinitely, or you need an incremental
version of the bidi algorithm.  Without having checked, I'd guess that
it can be done incrementally, but I believe no-one's done that work yet.

Another issue is that the designer may well want the start half of the
line to be justified even though the block of text as a whole is not
justified (cf the common practice in print of justifying only the lines
of a block that are shortened by the presence of a float).  From a spec
point of view, this means considering whether/how to allow specifying
this behaviour.  From an implementor's point of view, you
want new code to justify a partial line that might not even be a
contiguous portion of the input text (thanks to the interaction of bidi
and splitting up a single line), unlike the existing case of splitting a
paragraph into lines (which actually isn't affected by bidi).  Doing
justification makes it more important to do optimal line breaking.  (The
horible line-breaking we see with justification in existing browsers is
probably an important reason why one rarely encounters pages with
justified text these days.  The problem gets worse / more noticeable
with narrow text regions as would occur when splitting a line into two
with a float in the middle.)


(I hope my sleepiness hasn't left too many non sequiturs in this post.)

pjrm.

Received on Monday, 31 December 2007 15:24:42 UTC