<div class="gmail_quote">On Thu, Dec 2, 2010 at 1:51 AM, Greg Hellings <span dir="ltr"><<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Wed, Dec 1, 2010 at 7:40 AM, Jonathan Morgan <<a href="mailto:jonmmorgan@gmail.com">jonmmorgan@gmail.com</a>> wrote:<br>
> From an application developer's point of view, I'm not convinced that per<br>
> module CSS is a good idea. Here are some reasons:<br>
> 1. I'm not convinced of "well-defined use of HTML+CSS classes". Some things<br>
> may be well-defined, but I know BPBible does a lot of customisation of the<br>
> SWORD generated HTML and uses a lot of custom CSS, and some or all of these<br>
> things might break CSS designed for other apps (and vice versa). I also do<br>
> not like the idea that my changes to either the HTML generated or the CSS<br>
> breaks the display of a module I have never seen.<br>
<br>
</div>I believe the phrase would mean the SWORD library would produce a well<br>
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'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's CSS.<br>
<br>
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'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><br>We use different structure, not just different classes. <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
><br>
> 2. Some of the application specific styles and user choices may conflict<br>
> with the module styles. For example, I know Bibletime has themes, which can<br>
> change colour of foreground text, background, ... I have thought about<br>
> doing a similar thing for BPBible. However, this isn't going to work in<br>
> cases like: our poor user has a dark background, and the module developer<br>
> has decided to mark a particular text feature in a dark purple which is<br>
> nearly illegible.<br>
<br>
</div>I remember Jaak voicing this complaint when I brought up CSS<br>
stylesheets in BibleTime. This is actually an argument FOR having<br>
external stylesheets. I don't see why either of you would think our<br>
case is any different from a web browser in this regard.CSS was<br>
designed specifically to handle exactly the situation you bring up.<br>
In web browsers styles will cascade downwards with earlier styles<br>
overwriting later ones in the following order:<br>
<br>
1) User-Agent stylesheet<br>
2) External stylesheets<br>
3) Internal stylesheets<br>
4) Inline styles<br>
<br>
Often times a user can insert their own styles for accessibility<br>
reasons and I believe those are usually placed at priority 3.5 in that<br>
list. Currently SWORD applications only support (1) and (4).<br>
BibleTime's offer of themes simply changes the values of the<br>
User-Agent stylesheet. My first attempt at creating SWORD modules way<br>
back when I thought that (2) and (3) would be supported since the<br>
library documentation claimed to support ThML, but it ends up the<br>
entire header of the document gets thrown away during import but<br>
inline styles remain intact. As a result, (3) would be difficult to<br>
handle in SWORD without major changes to the entire library and import<br>
system but (2) would be very easy to add simply by honoring a config<br>
option.<br>
<br>
Since the stylesheets within each level cascade with later ones<br>
overriding earlier ones, in order to maintain the specified order, the<br>
following in the HTML header would be all that is required:<br>
<br>
<link rel="stylesheet" type="text/css"<br>
href="/usr/share/bpbible/css/default.css" /><br>
<link rel="stylesheet" type="text/css"<br>
href="modules/ztext/mymodule/css/module.css" /><br>
<link rel="stylesheet" type="text/css"<br>
href="~/.bpbible/css/user-overrides.css" /><br>
<br>
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't we use its full<br>
power?<br></blockquote><div> <br>It seems to me a given that when you introduce more sources of styles you introduce more potential for conflict.<br><br>The reason this is different from what is on the web is that the default browser CSS is fairly similar across all browsers. I know there are differences in text size and padding levels and that some people go to the trouble of using browser reset stylesheets, etc., etc., but that's still a fairly small difference. Here we have multiple applications and I don't think it's reasonable to assume that the base CSS is fairly similar across apps in the same way as it is across browsers. While it is true that users can apply custom stylesheets, I suspect the number that actually do so is fairly minimal, so web developers just have to test on a stock-standard browser build (and do).<br>
<br>If we had HTML modules then I would expect it to be exactly the same as on the web. Since we have higher-level constructs and more rendering options, it is much more likely that there will be transformations that radically affect presentation without affecting text, and module CSS can interfere with this. [If browsers showed as much difference between renderings of the same text as some frontends do, I would be very worried].<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Currently the only way to get styles through to the display layer are<br>
through number 4 - inline styles. As it is, I can already mess with<br>
every one of those settings you're worried about me messing up and the<br>
user can do nothing about it (unless, of course, BPBible strips the<br>
style attribute from ThML sources). So by providing me the ability to<br>
set an external stylesheet, you would actually be fixing what is<br>
currently a usability bug in apps. Thus both you and Jaak are correct<br>
to worry about this issue, but the result of your worrying should be<br>
to enable external styles not disable them.<br></blockquote><div> <br>So what you are saying is that you use something that might break it more so we should officially support something that might break it a bit less?<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> 3. As well as the single verse search results Karl mentions, the parallel<br>
> case comes to mind. If I have multiple books using different style sheets,<br>
> how do I manage that? Do the parallel Bibles end up in different and<br>
> clashing styles? In BPBible I think we even generate different HTML for<br>
> these different places, so there's not even a guarantee that these styles<br>
> will apply cleanly and work. However, if any modules are created that rely<br>
> on these custom styles to look OK, then we will need to have some way of<br>
> making them work in all these different contexts.<br>
<br>
</div>Of course, this depends on how you allow styles to be defined. I<br>
think, again, this is actually an argument _for_ having external<br>
styles available for each module. Currently I can only put my styles<br>
inline on an element. Therefore no matter what you do, without<br>
stripping off the style attribute, I can easily break the display of<br>
your parallel Bibles. If I were permitted an external stylesheet<br>
which I could apply to well defined HTML classes, then the user-agent<br>
could decide what to do based on its own method for parallel display.<br>
BibleTime, IIRC, uses a <table> with each verse in a new <tr> and each<br>
version displayed side-by-side within a <td>. It is likely that<br>
BibleTime would simply not include the external stylesheet of either<br>
module at this point; alternatively they could be included in some<br>
deterministic order - reverse order of their addition to the display,<br>
for instance, that way the version which has been there longest takes<br>
precedence. If a display were using a frameset or iframes, then it<br>
might opt to include the stylesheets.<br></blockquote><div><br>Which bears out my original point: if the display in the CSS is ever required to make the module look right, then it will end up broken in some views where we can't/won't include it. <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); 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).<br></blockquote><div> <br>All I'm pointing out is that more control is not always a good thing, and often doesn't come for free as much as people think/hope it will.<br>
<br>Jon<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Of course all of this ignores BibleCS, which I personally don't mind.<br>
But it probably doesn't honor inline styles any more than external<br>
styles, so I have no interest in it. :)<br>
<font color="#888888"><br>
--Greg<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br>