[email protected] wrote:
Stefan Seefeld <[email protected]> wrote on Thu, 22 Jan 2009
09:52:58 -0500:

* Your layout element may nest (it may appear wherever block-level
elements are expected).

Yes, but I'm not sure this is necessary. For simplicity, we should
perhaps allow it only as a child of <foil>, without nesting, until
somebody comes up with a well-motivated use case for nested <layout>s.
Fine with me.


* Your layout element plays two roles at once:

   - It provides a handle to specify layout (as my 'blocks'), by means
of the 'name' attribute.
   - It provides a handle to associate a template with it, by means of
the 'master' attribute.

 I'm not sure whether mixing the two is really necessary. It might be
clearer to only have them use 'name', but add the optional 'master'
attribute to the top-level foil (or foilgroup) element.

I also think we need only the one equivalent to CSS classes.

I'm no longer sure "master" is a good name for this attribute because
of its analogy to page masters, because I would not want them to be
"slide" masters but rather "slide body" masters. I don't need to
switch slide masters half-way through a presentation; do you?

Yes.

 "name"
is good I guess. <layout name="twocol"> is very suggestive.

This is also why I would steer clear from making "master" an attribute
of "foil"; this would require a user to customize the foil template,
or to use obscure XPath to react to ../@master or even
ancestor::foil/@master.  I think layout specifications belong inside
the foil, not the a foil as such.

So far I haven't done any XSLT customization in this context. But I did use CSS, where it's trivial:

.two-colum left { float: left;}

etc. I don't think having to mess with the foil XSLT template directly is a good idea. But I don't find the above XPath syntax involving ancestor-based selectors obscure at all, so this doesn't really seem necessary either.

Regards,
      Stefan

--

     ...ich hab' noch einen Koffer in Berlin...


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to