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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
