DM Smith <[EMAIL PROTECTED]> writes: > This inspired me to play with the scaling problem: For n choices for > interlinear there are about (n-1)! fragments of CSS that need to be > computed. My goal was to have static CSS be able to show the result.
Actually, it's n^2 possible combinations; it's a basic "select on/off" subset analysis of those features to be provided. Two annotation features, Strong's & morph, make for 4 combinations of CSS layout descriptor (neither, 1 or the other alone, or both). My problem with DM's suggested improvement is that my balls just aren't big enough to mess again with code that took something like 10 days of on-again-off-again hackery to get just right -- comedy is not pretty, and the <span>-handling update to GnomeSword's display code was pretty comical. Do you have any idea of the complications presented by footnotes and xrefs in a re-<span>'d text stream? :-) Seriously, I may look at it again someday, based on this concept, but given that we have no plans to provide for more markup than word + Strong's + morph, then the code is currently a complete implementation. > The problem is that <span> is relatively new (in terms of browser > support) and even FireFox stumbles on rendering it properly And of course (to repeat myself for emphasis) none of this is available when the renderer is not at all CSS-aware, as is the case with gtkhtml3. _______________________________________________ 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
