[Bug 6003] New: New type of lists

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6003

           Summary: New type of lists
           Product: XSLFO
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: XSL-FO 2.0 Requirements
        AssignedTo: xsl-editors@...
        ReportedBy: j.tosovsky@...
         QAContact: xsl-editors@...


At present, if definition lists are necessary, <fo:list-block> or <fo:table>
elements are used.

In case of list-block the term is inserted into <fo:list-item-label> while
definition itself into <fo:list-item-body>. As for processing of
<fo:list-block> element a value of label witdh is required, it is set manualy
or computed (for the best results a quite complex formula is required).

In case of table the term is inserted into the first cell while definition into
second one. If nested definition list are necessary, nested tables are used.

These solutions have drawbacks - indentation in both cases is equal to the
width of term. If several levels of indentation are used, available width for
text itself very quickly decrease. We also never get nice design as indentation
of each level hasn't the same value. In case of <fo:list-block> such value can
be set manualy and hence it is possible to ensure the same value for each
level, but this idea goes against the automation.

In TeX different system is available:
Term is followed by definition (separated by space), but second line is
indented by arbitrary value - not according the width of term:

Term Definition. If definition
  is long, it continues on se-
  cond line a litle bit inden-
  ted. Nested term:
  Nested term Definition of
    nested term keep the same
    value of indentation.

I haven't found any drawbacks, but advantages only:
- much nicer design (imagine terms in bold)
- no problems with width of term
- enough width for definition text if several nested levels

This system seems to be idealy suited for automated processing so its
implementing should be high priority by my view.

I can imagine following structure:
<fo:definition-block start-indent="3em" provisional-label-separation="1em">
  <fo:definition-term>
     <fo:block>Term</fo:block>
  </fo:definition-term>
  <fo:definition-body>
     <fo:block>Definition</fo:block>
  </fo:definition-body>
</fo:definition-block>

Three new elements and two current parameters are enough to XSL-FO processor to
build such output I think. It could improve design of many documents! Please
consider this carefuly.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6003





--- Comment #1 from Vincent Hennebert <vhennebert@...>  2008-09-01 09:32:00 ---
I'm not sure new XSL Formatting Objects are needed to achieve such a layout.
This can be done by something like the following:
    <fo:block-container>
      <fo:block start-indent="3em" text-indent="-3em">
        <fo:inline font-weight="bold">Term Definition.</fo:inline>
        <fo:leader leader-length="1em"/>
        If definition is long, it continues on second line a little bit
indented. Nested term:
        <fo:block-container>
          <fo:block start-indent="3em" text-indent="-3em">
            <fo:inline font-weight="bold">Nested term.</fo:inline>
            <fo:leader leader-length="1em"/>
            Definition of nested term keeps the same value of indentation.
          </fo:block>
        </fo:block-container>
      </fo:block>
    </fo:block-container>

The block-container is used to reset the reference for start-indent. A solution
without the block-container is to set start-indent and text-indent resp. to 6em
and -6em, and so on, but obviously that requires to know the depth of the
definition list (might make the XSLT stage a little bit more complicated).


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6003


Tony Graham <Tony.Graham@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #2 from Tony Graham <Tony.Graham@...>  2009-05-27 10:11:46 ---
As noted in comment 1, it is possible to achieve the effect you describe using
XSL 1.1 features.

As such, the XSL FO SG has determined that no change is required for XSL FO
2.0.

This ticket is closed as 'invalid' only because that's the best description
that we can use among the resolutions supported by Bugzilla.

If you are satisfied with this determination, please change the status of this
issue to CLOSED, otherwise you are able to reopen this issue and provide
further explanation.


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6003


Jan Tosovsky <j.tosovsky@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED




--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.