[jsword-devel] Display formatting question

Sat Apr 26 07:51:06 MST 2008

On Apr 26, 2008, at 1:13 AM, Greg Hellings wrote:

> On Fri, Apr 25, 2008 at 10:38 PM, DM Smith <dmsmith555 at yahoo.com>  
> wrote:
>>
>>
>>
>> On Apr 25, 2008, at 9:28 PM, Greg Hellings wrote:
>>
>>
>> I've been trying to figure this out... when I'm pulling up the text,
>> in the ESV module, in, say, Genesis 1, if I do it one verse at-a- 
>> time,
>> verses without footnotes (4 and 5 being the first examples) appear in
>> grayish text, while those with footnotes (1-3, etc) appear in black
>> text.  However, when I select the whole chapter at one go, all the
>> verse text appears in standard black.  I'm not going to pretend to
>> know how to change things to get it back to normal, but I'm guessing
>> it has to do with the XSL.  The same thing happens with the KJV -
>> (except that now the sample four verses, Gen 1:1-4, are reversed).
>> Verses 1-3 appear as gray when selected individually while 4, with  
>> its
>> footnotes, appears in black.  Selecting the whole chapter gives all
>> black text.
>>
>> Is this a feature or a bug (and if the latter is it in BD/JSword,
>> simple.xsl or in my web browser?).
>>
>> --Greg
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>> Greg,
>> Below are the generated HTML for Gen 1:3 and Gen 1:4. I got this by  
>> doing
>> CTRL-A in Firefox and then viewing selected source. Merely viewing  
>> the page
>> didn't show anything.
>
> Heh, I hadn't even thought of that trick.  Safari wouldn't show me
> anything other than the base HTML page to load the JS.  Thanks for the
> reminder (I've been spoiled with no right-click on the Mac, I forget
> there are context menus sometimes).

I do HTML development for work and the plugins for FireFox are a  
tremendous help. I find that targeting xhtml is easier to get to right.

(Interestingly, our target platform is IE only. But I find these tools  
too valuable to develop in anything but FireFox.)

(I'm seeing a movement to use non-standard attributes in new toolkits.  
I avoid them for that reason.)

I use the following plugins daily:
HTML Validator to validate generated content. (Use a vm, like  
Parallels or Fusion, to run it under Linux or Windows, as it is not  
available on the Mac) (I haven't tried Total Validator, but that is a  
Mac option)
Web Developer (Can do HTML validation, too, but I don't know if it  
will validate generated content.)
FireBug

>
>
>>
>> I've formatted them so that they look good.  I often do this kind of
>> formatting so that I can debug the webpage. It's a manual process  
>> but I find
>> it worth the effort.
>>
>> (Hopefully the formatting will survive our email agents. :)
>>
>> I think the problem is that it is not valid HTML. Here are some of  
>> the
>> problems/issues that I see:
>> 1) The xslt should not output the CSS. It should be removed from  
>> simple.xsl
>> and put into an external css file that's linked in. This will improve
>> performance by keeping the page smaller.
>
> I had expurgated that from an earlier version of simple.xsl and hadn't
> remembered to pull the extra html/head/style parts out.  I've done
> that now - good point.
>
>> 2) The location of the <base> element is wrong. This element is  
>> only needed
>> for modules containing images. For now, just remove it from  
>> simple.xsl
>
> I can't find any mention of <base> in simple.xsl - the only base
> anything I find is the baseURL parameters, and I don't create any base
> tags with the javascript that I can see.  It doesn't seem to be
> causing any damage, though, so I'll put that at a second-priority
> elimination task.

In simple.xsl it is found at the beginning of the template match="/":

   <xsl:template match="/">
     <html dir="{$direction}">
       <head>
         <base href="{$baseURL}"/>
         <style type="text/css">

Also note that you will need to detect whether the language is right- 
to-left and set dir appropriately, otherwise Hebrew, Farsi, Arabic and  
a few other of our modules won't render correctly.

>
>
>> 3) There is a <link rel="stylesheet" type="text/css" href=""
>> title="styling"> after the embedded CSS. This was to allow the  
>> provided CSS
>> to be overridden. It too should be removed.
>
> I pulled that out too, after you mentioned number 1.
>
>> 4) The <table class="verse-text"> ....</table> is not actually a  
>> table. It
>> does not contain <tr> elements with <td> elements. I think you should
>> replace it with <div class="verse-text">...</div>
>
> I initially tried to modify simple.xsl (my previous attempt, mentioned
> above) to just spit out the <tr> and <td> elements, but I had erratic
> success with the placement of the text on the page.  Most of the GWT's
> layout is done with tables, and I have found that div tags are
> notoriously difficult to place correctly using CSS across multiple
> browser support, while tables are much simpler.

For IE to do CSS positioning correctly, it is important to have a  
DOCTYPE as the very first line of the generated output. Otherwise it  
goes into "quirks" mode and uses a different box model.
I find the following websites invaluable for understanding CSS  
Positioning:
http://www.csszengarden.com/
http://www.brainjar.com/css/positioning/
http://www.alistapart.com

>  I'm using a GWT
> widget that is supposed to model a vertical flow GUI panel onto which
> widgets are being placed.  I then create, inside of that, a basic HTML
> table element and place into the table element, using innerHTML, the
> output of simple.xsl.

The problem I have with tables is that their generation fixes the  
layout. I am a proponent of separating styling and content, using the  
class attribute to indicate content and not styling. IMHO, CSS should  
be the place to define layout.

>
>
> It seems like an error in simple.xsl that it fails to place any sort
> of <table> <tr> wrapper around the verse if there is only text in it -
> or is that my misunderstanding of what simple.xsl is trying to
> accomplish?  To wrap one set of output in a table and another set in
> nothing seems a bit strange to me.  However, I suppose if you're
> planning to put the results into a div tag, it makes more sense.

It is not an error in simple.xsl. Simple.xsl has BibleDesktop as it's  
only target. When used for another target it will need to be adapted.  
Here are some adaptations I think are good:
Change the output declaration to "xml"

Put the output of the template match="/" in a div and put an 
appropriate class on it. This merely replaces the <body> container 
that simple.xsl uses. Everything from <head> to </head> ought to be 
removed. And obviously the <html> and </html> are not needed.

Where <a href="..."> is output, change it to work with your system.

Don't use , but rather . Change the CSS to reflect that. 
Where is used without an attribute, just eliminate it. Java 
doesn't support so I merely used for the same purpose.

For the abbr template, use <abbr>, which Java cannot handle.

Some of the styling is hard-coded in simple.xsl, such as transChange, 
these should be changed to indicate content with if one doesn't care what kind of transChange or 
, if one does care.

If you are doing client side transformation, you'll need to eliminate  
the JSword extensions as the jar won't be available. This will make  
some of the output ugly. (e.g. Farsi/Arabic numbers won't be shaped  
properly, verse references titles in notes will show up as OSIS  
references.) But if you are doing server side, then leave it in and  
figure out how to make it work.

Finally, I'm frequently improving simple.xsl. For example, I'll be  
checking in some changes soon that will make it work well with TEI. To  
simplify your development, use a program that can do a three-way diff/ 
merge. Emacs has a decent one. On Windows, I like Tortoise's merge  
tool. To make it work you'll need the most recent common ancestor of  
your work and mine. So keep a copy of the version of simple.xsl that  
you used as the basis of your changes. After each merge, mine will be  
the most recent ancestor.

>
>
>>
>> As to the reason that the styling of Gen 1:3 and 4 are different,  
>> notice
>> that Gen 1:3 puts the content into a well-formed, valid table and  
>> the CSS
>> has styling for TD.text and TD.notes, which are used.
>>
>> Gen 1:4 on the other hand has the text in an invalid table. The
>> class="verse-text" is what governs the styling, but because the  
>> construction
>> is invalid, the browser is free to make it's best guess as to how  
>> it should
>> be rendered. I've found that FireFox will put everything that is in  
>> a table,
>> but not in <td> or <th> containers, and put it above the table and  
>> not apply
>> the styling of the table to the elements. I'm not sure what Safari  
>> does, but
>> it looks nearly identical.
>
> Very true, that's the root cause of the problem.  It also answers a
> pressing question I had been trying to figure out as to why my tables
> were not positioning the text properly in some cases.  I had the text
> just jammed up at the top of the page underneath of the buttons.
> However, I stripped off the extra <table ...> tag that you had wrapped
> around the text/notes portions of the template and added an extra <tr>
> <td> ... </td> </tr> around the last <xsl:apply-templates /> in the /
> template.  That has solved the text display problem.  Why the text
> still insists on displaying itself underneath of the buttons along the
> top, without an absolute positioning in the CSS, I have no idea.

I'm not sure exactly what you are referring to. So the best I can do  
is review your layout and make comment on that.

The page you create has a table of two rows. Each row has one cell.

The content of the first row is a table with the two buttons.

The content of the second row is the output of simple.xsl.

Therefore, the placement of the second row is relative to the first  
and the styling of the two rows and their cells is what governs how  
they are padded, spaced, aligned and so forth.

On the table that contains these two rows you have class="text". I  
didn't look in the CSS to see what this is defined as, but it probably  
is not appropriate for the first row. I think that it may be more  
appropriate to put the attribute on the second row. Maybe an attribute  
class="navbuttons" on the first.

Also, you have vertical-align="top" for the first row's cell and  
vertical-align="bottom" for the second row's cell. Since each row  
merely consists of a single cell, these are meaningless unless you  
style the cell to be taller than their content, using the height  
attribute. If they are of value, I find that it is a bit more compact  
to set the attribute on the row rather than the cells.

>
> However, it appears to me that it's now well-formed and valid HTML
> (with the possible exception of table-in-table... I haven't read the
> HTML spec closely enough to know if I can put a table inside of a
> <td>, but I believe I can).

Yes, it is allowed. Pretty much anything can be in a <td> or a <tr>.

Hope this helps.

Keep up the great work!

In Him,
	DM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/jsword-devel/attachments/20080426/89557578/attachment-0001.html 