[sword-devel] engine filters vs CSS

[Greg Hellings]

On Wed, Jan 7, 2009 at 3:14 AM, Peter von Kaehne <refdoc at gmx.net> wrote:
> One of the sore points from last autumn was a discussion about TEI
> encoded dictionaries and how poorly they display in absence of good
> filters - etc. You all remember.
>
> A couple of days ago I played a bit around with CSS, trying to see what
> it could/would do to a TEI entry. I used "abash" from Easton (I think)
>
> The result of a couple of hours work you can see here:
>
> www.crosswire.org/~refdoc/private/abash.html
>
> Look at the source to compare. Also note the absence of many of the
> headings in the source TEI. CSS allows to insert text, which is a
> brilliant tool to render tags with a high level of meaning (vs structure)
>
> There are three cheats/caveats in there:
>
> 1) I did nothing to make the references work. They don't work.
> 2) I wrapped everything in HTML and BODY tags to make my browser play nice.
> 3) I had to delete a couple of lb tags which somehow broke my design. I
> am sure I could find a way to resolve this without deleting them.
>
> As more and more frontends move to fully CSS capable displays I think we
> should consider to leave engine based filters behind and simply use the
> XML provided by the engine in a raw state but slam CSS on top of this.

This is something I have advocated - mostly silently and to myself -
for some time.  Supporting standard CSS options in modules would go a
long way to allowing for the dichotomy to continue to exist between
the OSIS XML objective and the objective of content creators who want
to display their content, like Karl.  It could be a hook to gain some
movement away from ThML, if the users could fully layout their
documents with CSS and just include that in the module and specify the
file name in the .conf.

>
> The immediate advantages appear to me
>
> 1)  very simple to code by people who do not know C++

While the current filters aren't terrible, I agree, this would
simplify things, at least in all the cases I can think of at 4:00 am.

> 2) very flexible display - maybe even on the fly accessible to power
> users of frontends.

Very true, provided the front-ends expose a means of doing this or
provide the user with the location of the CSS file.

> 3) full semantics of underlying XML exposed which might allow other uses
> of these.

Quite possibly - sort of in the way that JSword currently converts all
of its modules to OSIS before transforming them through XSL into the
display format (HTML, IIRC).  The expressiveness of XML and the vast
amount of things that can be done with it would probably be a big
boon.

>
> At this stage a filter would still be required to deal with references
> adequately. I presume a move from CSS to XSL could deal with this too,
> but I have a lot less clue about XSL and how to use it in a browser
> setting, so I did not even try.

In the browser - most of them provide support for applying a
stylesheet.  Whether or not that carries over into the embedded
versions of the widgets in GTK, QT and the like is not something I've
tried.  But even if it's not, having those front ends that want it
link in some sort of XML/XSLT library isn't too much to ask.  Of
course, then there would have to be standard forms of the XSL or the
front end developers would have to provide their own, etc, and they'd
all have to be maintained, same as the current C++ is maintained.
Personally I think that would be easier to maintain and probably more
people are able to help to add support for desire OSIS features, etc,
if there is an XSL than if there are the current filters.  But getting
from here to there would mean reimplementing lots of C++ code into
XSL.

And as for processing the links, etc, even if XSL doesn't have enough
string manipulation to transform references, once an always add-in an
extension function that can do everything the language its written in
can do.

--Greg