[Docutils-develop] Re: floating objects (was Re: Boxes)

[Beni C. <cb...@te...>]

On 2003-02-19, David Goodger wrote:

> [David Goodger]
> >> That's definitely a "sidebar".  According to `DocBook: The
> >> Definitive Guide
> >> <http://www.docbook.org/tdg/en/html/docbook-x.html>`_,
> >>
> >>     sidebar =8B A portion of a document that is isolated from the
> >>     main narrative flow
>
> [Beni Cherniavsky]
> > Quoting below that:
>
> What's your point, with the extra quoting?
>
To highlight some extra nuances of the definition that you refered to, in
contrast to which I wanted to put my ideas, for those that didn't read it.
I guess now it could be omited with no harm.

> >     DocBook does not specify the location of the Sidebar within the
> >     final displayed flow of text. The wrapper may float or remain
> >     where it is located.
>
> The "sidebar" directive could grow "float" and/or "fixed" options
> if necessary.
>
> > It feel a little bit too limited; I feel similarly about "topic".
> >
> > Currently reST has no general way to specify that something (e.g.
> > table) should be floated.  While this is a presentation issue, it is
> > sits on top of a content issue: most things are intended to be
> > presented in-line while some things are well suited to be floated
> > (some writers can fall back on putting the later inline too).  I
> > think a generic "float" directive, with arbitrary content should be
> > added. I don't mind the name but I want generic semantics - it would
> > wrap arbitrary content, without a requirement that it has 1-2
> > titles, contians no topics, etc.
>
> I think that individual directives should grow "float" options if and
> when required.  Alternatively, setting objects "afloat" could be a
> presentation decision of the Writer or the target software.
>
If you go this way, then you don't really need "topic"/"sidebar"
distinction.  A sidebar becomes a topic with a float option.

> A directive with arbitrary content seems too complex to me.  Assume it
> contained three paragraphs; would each grow a "float" attribute or
> would they have to be wrapped by an auxiliary floatable container?  I
> think the latter.

Definitely the later.

> In which case, just tack a "float" option/attribute onto the container
> and allow *it* to have (reasonably) arbitrary content.
>
> Not all objects *can* float.  In the publishing environments I've
> used, only "formal" objects (those with titles and/or numbers, such as
> "Table 1" or "Figure 2") are floated; referring to floating "informal"
> (untitled/unnumbered) objects from the main text would be problematic.
> I remember one publishing environment where *all* formal objects were
> floated -- to the top or bottom of the page, usually -- for aesthetic
> reasons.
>
Good point, didn't consider the issue of refering well enough.

--=20
Beni Cherniavsky <cb...@tx...>

Do not feed the Bugzillas.