Hi Greg,<div><br><div class="gmail_quote">On Thu, Dec 2, 2010 at 1:51 AM, Greg Hellings <span dir="ltr">&lt;<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">I believe the phrase would mean the SWORD library would produce a well</div>
defined set of HTML elements with classes attached to help preserve<br>
the semantic meaning.  It would then be up to the consumer of that<br>
HTML - the application - to provide its own CSS.  Adding extra CSS<br>
classes as per an application&#39;s specific desires ought to be as easy<br>
as extending the filter and just adding a few extra lines of code for<br>
each particular case.  Extraneous CSS classes can readily be ignored<br>
simply by not having a corresponding definition in the app&#39;s CSS.<br></blockquote><div>That&#39;s well and good, and would cover a good chunk of customizability needs - but it only works up to the limit of CSS.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
BPBible does lots of customization, BibleTime does as well, and<br>
certainly other apps do customize to some extent.  If the filters were<br>
good and easily extensible (and any of the XML processing technologies<br>
would work in that regard), BPBible&#39;s customizations could either be<br>
readily incorporated to the engine to benefit others who desire them<br>
or maintained in BPBible directly without having to throw out the base<br>
filters.  And, of course, BPBible would continue to maintain its own<br>
stylesheets.<br></blockquote><div>BPBible&#39;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&#39;s filters inherit from SWORD&#39;s ones, so the base filters are not thrown out as such. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
&gt; 2. Some of the application specific styles and user choices may conflict<br>
&gt; with the module styles.  For example, I know Bibletime has themes, which can<br>
&gt; change colour of foreground text, background, ...  I have thought about<br>
&gt; doing a similar thing for BPBible.  However, this isn&#39;t going to work in<br>
&gt; cases like: our poor user has a dark background, and the module developer<br>
&gt; has decided to mark a particular text feature in a dark purple which is<br>
&gt; nearly illegible.<br>
...
</div>That way the application provides the default appearances, the module<br>
can provide overrides to the default if it desires, and the user can<br>
provide overrides which take the highest priority.  Yes, if a module<br>
specifies Black background and the user has said they want all text to<br>
be in dark grey, that would be difficult to read.  But this can happen<br>
easily on the web already and somehow we are all able to manage.<br>
Since we are using identical technology, why can&#39;t we use its full<br>
power?<br></blockquote><div>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. </div>

<div><br></div><div>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.</div>

<meta charset="utf-8"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
&gt; 3. As well as the single verse search results Karl mentions, the parallel<br>
&gt; case comes to mind.  If I have multiple books using different style sheets,<br>
&gt; how do I manage that?  Do the parallel Bibles end up in different and<br>
&gt; clashing styles?  In BPBible I think we even generate different HTML for<br>
&gt; these different places, so there&#39;s not even a guarantee that these styles<br>
&gt; will apply cleanly and work.  However, if any modules are created that rely<br>
&gt; on these custom styles to look OK, then we will need to have some way of<br>
&gt; making them work in all these different contexts.</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Adding support for external stylesheets actually gives the application<br>
and user MORE control, not less, and still allows the module creator a<br>
sane way of specifying styles without having to resort to inserting<br>
their styles as style attributes on every single ThML element they<br>
want stylized (and would also allow the creation of OSIS modules where<br>
the style is influenced by the module creator instead of only by the<br>
engine and user agent, provided the applications can agree on<br>
well-defined mapping between OSIS and HTML).</blockquote><div>I&#39;m all for giving the application and user more control; I&#39;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. </div>

<meta charset="utf-8"><br clear="all">God Bless,<br>Ben<br>-------------------------------------------------------------------------------------------<br>Multitudes, multitudes,<br>    in the valley of decision!<br>For the day of the LORD is near<br>

    in the valley of decision.<br><br><div>Giôên 3:14 (ESV) </div></div><br></div>