W3C home > Mailing lists > Public > xsl-editors@w3.org > April to June 2004

marginalia use case issues

From: Victor Mote <vic@outfitr.com>
Date: Wed, 12 May 2004 22:26:55 -0600
To: "'XSL Editors'" <xsl-editors@w3.org>
Message-Id: <20040513042727.21877A2CF9@frink.w3.org>

Dear XSL Editors:

The use case I would like to discuss is pretty well documented by RenderX
here:
http://xep.xattic.com/xep/testsuite/usecases/marginalia.pdf
specifically, the second scenario listed there, which they describe as
duplex marginalia. There are at least two use cases where the solution that
they propose fails, and for which I don't think the XSL-FO Standard (either
1.0 or the 1.1 proposal) allows a solution. My comments assume a lr-tb page
orientation:

1. The artificially-created marginalia "area" created by the maneuver
described there will intrude into any footnotes that are in the same flow.
The desired effect is that the footnote "area" would have precedence over
the marginalia "area".

2. Other fo:float objects, such as drop caps, may be affected by the
clear="both" attribute that is required for the solution, even though they
are never vertically aligned (i.e. they are conceptually in different
columnar parts of the page).

I have some proposals regarding these issues:

Predicate Issue
---------------
All of the above is dependent upon the RenderX extension float="inside |
outside". I would like to propose that this extension, or something
functionally similar be added to the standard.

#1: Footnote/Marginalia Precedence
----------------------------------
The best solution that I can think of here is to add "inside-indent" and
"outside-indent" properties in all places where "start-indent" and
"end-indent" are allowed, which would be mapped internally to either
"start-indent" or "end-indent" depending on the odd-even/right-left value of
the page.

Another possible solution would be to allow the inline progression dimension
properties of the footnote-reference-area (and presumably the
before-float-reference) to be manipulated as part of the creation of a
page-master object.

There may be other solutions as well.

I realize that both float="inside | outside" and
inside-indent/outside-indent are probably of limited use in systems whose
ipd is vertical, but I don't see that they are of any harm either. In
general, it strikes me as being useful for "inside" and "outside" concepts
to be applied to margins and nearly anything else that deals with "start",
"end", "before" and "after" concepts. However, I do not have any use cases
in mind at the moment for such features.

I am not sure, but I think these items would be relatively easy for
implementors to implement, at least if they already handle
text-align="inside | outside".

#2: Other float items
---------------------
The workaround allowing marginalia creates an artificial area in the
region-body for the marginalia. Within this "column", a user probably wants
to keep each float clear of the others. In a situation, such as RenderX's
implementation, where a float can float to the inside or outside (as well as
start or end), floats must use clear="both" to get that effect. The problem
is that there may be other floats on the page, that are *not* in the
marginalia column, but that share either a conceptual float="start" or
float="end" because of the internal mapping that would be done to get from
float="inside" or float="outside". So, for example, if marginalia floats
float to the inside, and the main text has drop caps that always float to
the "start" side, then both of these effectively have a "start" value on
odd-numbered (recto) pages. Assuming the user has kept these in different
"columns", there is no possibility of collision between them, yet the needed
clear="both" in the marginalia floats will not allow them to both be
intersected by a line in the inline-progression-dimension.

The best solution I have come up with so far is a "class" property for the
float object, that would allow these floats to be conceptually segregated.
Then, the "clear" property could list the class(es) that the float should be
kept clear of. Alternatively (but less flexibly), the "clear" property could
simply have an option that allowed it be clear of floats in its same class,
perhaps clear="this-class" or clear="same".

Conclusion
----------
I apologize for the brevity of the above discussion, and the inexactness of
some of my terminology. It is my hope that since you probably spend a lot of
time thinking about these issues, you already know what I am talking about.
If not, and if I have not provided enough detail, please let me know, and I
will be glad to expand as needed.

BTW, thanks for your efforts on the standard. It is *extremely* useful.
Thanks also for your consideration of the above items.

Victor Mote (mailto:vic@outfitr.com)
Enterprise Outfitters (www.outfitr.com)
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice +1 (719) 622-0650, Fax +1 (720) 293-0044
Received on Thursday, 13 May 2004 09:54:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:57 GMT