[sword-devel] Markup Options

[Ben Morgan]

Hi Greg,

On Thu, Dec 2, 2010 at 1:51 AM, Greg Hellings <greg.hellings at gmail.com>wrote:
>
> I believe the phrase would mean the SWORD library would produce a well
> defined set of HTML elements with classes attached to help preserve
> the semantic meaning.  It would then be up to the consumer of that
> HTML - the application - to provide its own CSS.  Adding extra CSS
> classes as per an application's specific desires ought to be as easy
> as extending the filter and just adding a few extra lines of code for
> each particular case.  Extraneous CSS classes can readily be ignored
> simply by not having a corresponding definition in the app's CSS.
>
That's well and good, and would cover a good chunk of customizability needs
- but it only works up to the limit of CSS.


> BPBible does lots of customization, BibleTime does as well, and
> certainly other apps do customize to some extent.  If the filters were
> good and easily extensible (and any of the XML processing technologies
> would work in that regard), BPBible's customizations could either be
> readily incorporated to the engine to benefit others who desire them
> or maintained in BPBible directly without having to throw out the base
> filters.  And, of course, BPBible would continue to maintain its own
> stylesheets.
>
BPBible's customizations are somewhat complicated and rely heavily on other
parts of the SWORD API or other data (e.g. showing two xrefs in an xref
block and putting the rest in a separate link, producing user friendly xref
text, colorcoding quotes in the ESV by speaker (experimental in 0.5),
replacing strongs numbers with greek lemma/transliterated). This is best
suited to the current way things work I feel. BPBible's filters inherit from
SWORD's ones, so the base filters are not thrown out as such.


> > 2. Some of the application specific styles and user choices may conflict
> > with the module styles.  For example, I know Bibletime has themes, which
> can
> > change colour of foreground text, background, ...  I have thought about
> > doing a similar thing for BPBible.  However, this isn't going to work in
> > cases like: our poor user has a dark background, and the module developer
> > has decided to mark a particular text feature in a dark purple which is
> > nearly illegible.
> ...
> That way the application provides the default appearances, the module
> can provide overrides to the default if it desires, and the user can
> provide overrides which take the highest priority.  Yes, if a module
> specifies Black background and the user has said they want all text to
> be in dark grey, that would be difficult to read.  But this can happen
> easily on the web already and somehow we are all able to manage.
> Since we are using identical technology, why can't we use its full
> power?
>
I agree the mechanism is simple enough; the ramifications are potentially
not. Personally, I would mostly prefer that modules cannot provide their own
stylesheets. On the web, every site has its own style; in print, each Bible
has its own style. But when different Bibles are gathered together (say a
print 4-version Bible) they all use the same formatting. Just so with our
software - a consistent look throughout different Bibles is important, and
having each module specifying what font it wants and size and colour has too
much potential to lose consistency throughout the application.

Your particular problem, Greg, where you wanted to duplicate the look and
feel for modules as compared to existing systems, would be better
addressed I feel by allowing the user to specify their own stylesheet,
rather than per-module styling. This would still maintain a consistent look
and feel across all modules.


> > 3. As well as the single verse search results Karl mentions, the parallel
> > case comes to mind.  If I have multiple books using different style
> sheets,
> > how do I manage that?  Do the parallel Bibles end up in different and
> > clashing styles?  In BPBible I think we even generate different HTML for
> > these different places, so there's not even a guarantee that these styles
> > will apply cleanly and work.  However, if any modules are created that
> rely
> > on these custom styles to look OK, then we will need to have some way of
> > making them work in all these different contexts.
>
Adding support for external stylesheets actually gives the application
> and user MORE control, not less, and still allows the module creator a
> sane way of specifying styles without having to resort to inserting
> their styles as style attributes on every single ThML element they
> want stylized (and would also allow the creation of OSIS modules where
> the style is influenced by the module creator instead of only by the
> engine and user agent, provided the applications can agree on
> well-defined mapping between OSIS and HTML).

I'm all for giving the application and user more control; I'm just not
convinced we should give module creators this level of control. I fear
per-module stylesheets would be somewhat brittle, liable to be targeted at a
particular frontend (which is what Jon was saying above), and likely to
reduce the consistency in the interface. That said, I can see there could be
a few cases where it might be necessary - say if a publisher insisted that
their Bible look the way their print one does - but I would prefer
consistency to each Bible looking like their print counterpart.

God Bless,
Ben
-------------------------------------------------------------------------------------------
Multitudes, multitudes,
    in the valley of decision!
For the day of the LORD is near
    in the valley of decision.

Giôên 3:14 (ESV)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101202/da9c6db9/attachment.html>