No subject

module CSS is a good idea.  Here are some reasons:
1. I'm not convinced of "well-defined use of HTML+CSS classes".  Some things
may be well-defined, but I know BPBible does a lot of customisation of the
SWORD generated HTML and uses a lot of custom CSS, and some or all of these
things might break CSS designed for other apps (and vice versa).  I also do
not like the idea that my changes to either the HTML generated or the CSS
breaks the display of a module I have never seen.

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.

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.

I could probably find more potential problems, but these will do for now.

On Wed, Dec 1, 2010 at 3:43 AM, Karl Kleinpaste <karl at kleinpaste.org> wrote:

> Greg Hellings <greg.hellings at gmail.com> writes:
> > 2) I can provide an external CSS stylesheet along with my module.
> > Then I could still use OSIS and, assuming well-defined use of HTML+CSS
> > classes being produced from OSIS by the engine, I could style the
> > module the way I desired.  This would not require terribly much work
> > to be done on the OSISHTMLHREF filter, but both Jaak and Karl when I
> > spoke with them were unwilling to allow inclusion of an external CSS
> > file in a module.  Why? I may have misunderstood but it seemed they
> > were both of the opinion that presentation and appearance is of
> > paramount importance, and they want to control the presentation of
> > material in the applications.
>
> I don't specifically recall such a conversation, but I think you
> misunderstood whatever I may have said.  My perspective on CSS is that
> Xiphos cannot create a dependency on such a thing until we extricate
> ourselves from gtkhtml3, once and for all.
>
> Once we can be certain of always being able to link against a CSS-aware
> environment (xulrunner is there, of course, but we need WebKit for the
> sake of Win32), I don't think I'll even have a strong opinion, one way
> or the other, on whether a module should provide its own CSS.
>
> How to integrate it into display is another matter.  Standard filename
> within the subdir space of the content?  Probably, but not necessarily.
> And that would apply only to full-page (full chapter) displays; how to
> use such a stylesheet for single-verse search results, for example?
>
> The bigger problem with the idea of CSS is that its use will totally and
> finally leave behind all UIs which do not target HTML as their output
> methodology.  I.e. BibleCS has no hope.  I'm not sure which other UIs
> depend on something other than HTML.
>

I'm not aware of any active frontend other than BibleCS that doesn't use
some form of HTML.  Like Xiphos, BPBible's current rendering engine will not
support CSS properly, but BPBible 0.5 will.  And even without CSS, BibleCS
should still be able to display the text OK.

Jon

--485b393aaf7139e08904965974db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable