[sword-devel] XHTML Rendering of OSIS Reference Doc - Whitespace
Peter von Kaehne
refdoc at gmx.net
Wed May 8 14:57:45 MST 2013
On Wed, 2013-05-08 at 15:15 -0500, Greg Hellings wrote:
> Off the cuff here, it seems the issue is the difference in semantics
> of <div> between OSIS - where it marks a structural division within a
> text which can be of many different levels and layers and in XHTML
> where it represents a box of block-style layout which defaults to
> being the full width of its container.
That is true for the default behaviour of div. There is though now
particular need to stick to default behaviour, is there?
If every div carries enough class information there is nothing stopping
a frontend to make it via CSS inline. And the cut-off, where div changes
from being a block to being inline is one each frontend could choose
itself.
> Our thought was to store information along with each verse which
> includes a pre- and post- verse markup. This would need to become part
> of the OSIS import process, and it would track the "semantically" open
> elements such as <div sID="gen1" /> which, by XML standards are no
> longer open but the OSIS semantics designate that div is open until
> <div eID="gen1" /> is encountered. This would be in addition to the
> actually open XML elements.
If you make this a part of the module we will break continuity and
compatibility of old modules in a big style.
Why not make this a - maybe switchable - function of the engine, handled
on the fly? This would make a lot of sense when returning arbitrary
chunks - parse the chunk and ensure it is balanced, not just in an XML
sense but also in an OSIS sense. Or at least the info for the missing
bits is created and passed on upwards. This would allow keeping modules
as they are.
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130508/1bf80494/attachment.sig>
More information about the sword-devel
mailing list