Hi, Finlay, a few days ago, said : "However, there is no reason we can have heaps of CSS in the templated koha. It just goes into files that are read in through <TMPL_INCLUDE NAME="stylesheet"> tags." I agreed, but, i'm less sure now... I explain : css has 2 goals : one important, and one less. * the 1st goal, as finlay said, is to separate content from style. The <TMPL_INCLUDE> solution respects this. * the 2nd goal is to lower data traffic between server and client : the html does not contain many "style tags" as they are all in the css, and the css, when extenal, is CACHED, and passed only once to the client ! If we use css inclusion in htm file, we loose the 2nd goal. But... it we use a <link rel="stylesheet" type="text/css" href="style.css">, we must put the style sheet in htdocs scope, not in cgi. Thus, we need a /template/<theme>/<lang> in both cgi and htdocs. what do you think of this ? do you have a problem with having a /template... in htdocs as well as in cgi-bin ? do you think we can forget "data traffic optimization" ? I *vote* for the <link rel="stylesheet" type="text/css" href="style.css"> solution, having a good traffic optimization and a /template/... in htdocs. I know that *chris* has the *same* opinion (irc) Note anyway I agree that a theme/language should use always the same css. Maybe, every language for a theme will use the same ! Note also i'm working on default/en/style.css, so expect it soon on cvs ! It will respect completly the look of the actual koha, so migration from non-css to css can be done on the fly. -- Paul
paul POULAIN wrote:
I *vote* for the <link rel="stylesheet" type="text/css" href="style.css"> solution, having a good traffic optimization and a /template/... in htdocs. I know that *chris* has the *same* opinion (irc)
Chris suggested that we could put the css in the cgi-bin dir, but it doesn't work, coz style.css apache does not how to "execute" style.css. Thus, it confirms that style.css must be in htdocs scope if we want "external" css. -- Paul
paul POULAIN wrote:
paul POULAIN wrote:
I *vote* for the <link rel="stylesheet" type="text/css" href="style.css"> solution, having a good traffic optimization
I agree.
and a /template/... in htdocs. I know that *chris* has the *same* opinion (irc)
I originally had the same opinion... but after testing various options I see no advantage in having htdocs/template/<theme>/<lang> (if that is correct understanding of what is meant above). I now vote for: <serverroot>/<theme>/<lang>/ ./style/ ./*.css ./catalogue/ ./*.html ./*.tmpl ./members/ ./*.html ./*.tmpl ./images/ ... and so on at discretion of theme author.... I think that Dorian suggested that some time ago. Does that make sense? R.
On Wed, Oct 09, 2002 at 09:59:48PM +1000, Roger Buck wrote:
I now vote for:
<serverroot>/<theme>/<lang>/ ./style/ ./*.css
./catalogue/ ./*.html ./*.tmpl
./members/ ./*.html ./*.tmpl
./images/
... and so on at discretion of theme author....
I think that Dorian suggested that some time ago.
Does that make sense?
Mostly, except for the location of *.css files. (I confess that I'm almost entirely ignorant about CSS, so I'll ask you to put up with naive questions, and to enlighten me when I'm wrong.) As I understand it, stylesheets specify colors, fonts, and all of those little presentation details. In particular, AIUI, stylesheets do not specify content. So why would the *.css files go in <theme>/<lang>? How are the French link colors different from the Italian or German colors? Okay, so the Japanese and Cherokee versions of the web page will obviously use different fonts. But most everything else will be identical across languages, right? Perhaps there should be theme-wide CSS and a separate per-language CSS? I'm mainly concerned with duplication ("Pragmatic Programmer" tip #11: Don't Repeat Yourself). If default/en/style/foo.css and default/jp/style/foo.css are separate, and need to be kept in sync, they _will_ drift apart. The same thing applies to language-specific templates. Of course, this applies mainly to the source. In the installation, it might be more efficient to have duplication. That is, have serverroot/default/en/style/foo.css and serverroot/default/jp/style/foo.css be automatically generated from source/foo.css, source/foo_en.css, and source/foo_jp.css. This should be done by 'make install' (which of course implies that there should be a Makefile). -- Andrew Arensburger This message *does* represent the arensb@ooblick.com views of ooblick.com I feel more like I do now than I did before I started.
Andrew Arensburger wrote:
On Wed, Oct 09, 2002 at 09:59:48PM +1000, Roger Buck wrote:
I now vote for:
<serverroot>/<theme>/<lang>/ ./style/ ./*.css
./catalogue/ ./*.html ./*.tmpl
./members/ ./*.html ./*.tmpl
./images/
... and so on at discretion of theme author....
I think that Dorian suggested that some time ago.
Does that make sense?
Mostly, except for the location of *.css files. (I confess that I'm almost entirely ignorant about CSS, so I'll ask you to put up with naive questions, and to enlighten me when I'm wrong.)
You're right, but you're wrong...
As I understand it, stylesheets specify colors, fonts, and all of those little presentation details. In particular, AIUI, stylesheets do not specify content. So why would the *.css files go in <theme>/<lang>? How are the French link colors different from the Italian or German colors?
You're right, here...
Okay, so the Japanese and Cherokee versions of the web page will obviously use different fonts. But most everything else will be identical across languages, right? Perhaps there should be theme-wide CSS and a separate per-language CSS?
you're wrong here : we can't embeed 2 style sheets in the same html page (not sure of this!) you're wrong too because you can link "pictures" (mostly backgrounds or buttons) in css, and you may need them in differents sizes depending on the language.
I'm mainly concerned with duplication ("Pragmatic Programmer" tip #11: Don't Repeat Yourself). If default/en/style/foo.css and default/jp/style/foo.css are separate, and need to be kept in sync, they _will_ drift apart. The same thing applies to language-specific templates.
You're right there. Thus, 2 points + and 1 point -. Not sure of the best decision. Maybe a question for our next irc meeting ? -- Paul
you're wrong here : we can't embeed 2 style sheets in the same html page (not sure of this!)
We can. If the second stylesheet contains duplications (i.e., both set different styles for <H1>) the second stylesheet overrides the first. It's a good method of creating 'sub-areas' within a site where the style is somewhat different, while still including the same main stylesheet on every page. The only thing I'm not sure of is browser support. I think we'll find it good in any browser with good CSS support in general, though. -- Owen ---- Web Site Developer Nelsonville Public Library http://www.athenscounty.lib.oh.us
On Wed, Oct 09, 2002 at 05:59:25PM +0200, paul POULAIN wrote:
As I understand it, stylesheets specify colors, fonts, and all of those little presentation details. In particular, AIUI, stylesheets do not specify content. So why would the *.css files go in <theme>/<lang>? How are the French link colors different from the Italian or German colors?
You're right, here...
Actually CSS2 style sheets can specify some text content, though I don't think anyone uses this "feature", & I think it's a bad idea to do so in any case. IIRC, the standard has an example of this using the Q element as an example. Regarding the notion of "presentation details", one thing I always mention is that it is grammatically wrong to underline links in Chinese pages. No one cares, but the underline is a punctuation mark, meaning the underlined word is a proper noun. "Presentation details" may be important for a language we don't know about. (The W3C guys seems to not realize this fact about "presentation details", and is thus making HTML less Chinese friendly; it also proposes features which are completely useless for languages they are designed for. But that's another story.) -- Ambrose Li ``A good style should show no sign of effort; what is written should seem a happy accident.'' ~ Somerset Maugham
Hi Just to confirm 1/. you can have more than one CSS (thats the cascading part or cascading style sheets :-) 2/. you can have images referenced from your CSS as backgrounds for Div's and I think Spans, although they don't work in all browsers unfortunatly. For CSS info we recommend http://www.richinstyle.com/ 3/. Netscape 4.7 is very bad at styles, and thats what we use at Horowhenua library for the OPAC's I think, which is why there is very little "modern" HTML in their templates. 4/. Personally I'd be completly redoing the templates and CSS to suit a particular library as part of any commercial install, so I don't think it's a big issue. Cheers Rachel _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
4/. Personally I'd be completly redoing the templates and CSS to suit a particular library as part of any commercial install, so I don't think it's a big issue.
I would think any library with an established web site would want to integrate Koha into their existing look. Forgive me if this is a stupid question, but just how much of the HTML & CSS does the templating system control? All of it? Or just certain aspects? -- Owen ---- Web Site Developer Athens County Library Services http://www.athenscounty.lib.oh.us
4/. Personally I'd be completly redoing the templates and CSS to suit a particular library as part of any commercial install, so I don't think it's a big issue.
I would think any library with an established web site would want to integrate Koha into their existing look.
Forgive me if this is a stupid question, but just how much of the HTML & CSS does the templating system control? All of it? Or just certain aspects?
I think it is/should be all of it - and as Fin works for me hopefully that's where he's heading :-) Cheers R _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
Warning: This is long and for some extended CSS2 info only :) Andrew Arensburger wrote:
On Wed, Oct 09, 2002 at 09:59:48PM +1000, Roger Buck wrote:
I now vote for:
<serverroot>/<theme>/<lang>/ ./style/ ./*.css
./catalogue/ ./*.html
[--snip--]
... and so on at discretion of theme author....
I think that Dorian suggested that some time ago.
Does that make sense?
Mostly, except for the location of *.css files.
I felt the same way initially... but I spent a lot of time testing various options on a working test system. After three days of testing it proved to be a clear "stand out" best option YMMV :)
(I confess that I'm almost entirely ignorant about CSS, so I'll ask you to put up with naive questions, and to enlighten me when I'm wrong.)
In addition to searching the web for .css info: Something to read... Cascading Style Sheets: Designing for the Web , Second Edition Hakon Wium Lie, Bert Bos 0201596253 JUL 06, 1999 Something to play with... http://www.price-media.demon.co.uk/cascade.html
As I understand it, stylesheets specify colors, fonts, and all of those little presentation details.
"CSS2 is a style sheet language that allows authors and users to attach style (e.g., fonts, spacing, and aural cues) to structured documents (e.g., HTML documents and XML applications). By separating the presentation style of documents from the content of documents, CSS2 simplifies Web authoring and site maintenance. CSS2 supports media-specific style sheets so that authors may tailor the presentation of their documents to visual browsers, aural devices, printers, braille devices, handheld devices, etc. This specification also supports content positioning, downloadable fonts, table layout, features for internationalization, automatic counters and numbering, and some properties related to user interface." Source: http://www.w3.org/TR/REC-CSS2/ This may go a little beyond what you were thinking about in terms of fonts and colours - it includes whole page layout and delivery method?
In particular, AIUI, stylesheets do not specify content. So why would the *.css files go in <theme>/<lang>? How are the French link colors different from the Italian or German colors? Okay, so the Japanese and Cherokee versions of the web page will obviously use different fonts. But most everything else will be identical across languages, right? Perhaps there should be theme-wide CSS and a separate per-language CSS?
I'm probably not telling you anything new but: The idea is that .css can be used to easily and efficiently deliver the _same__content_ in a large variety of ways. I think you actually have to work with it for a while until you see how powerful it is.
I'm mainly concerned with duplication
[--snip--] A single style sheet could still be used if that were prefered... even if it were necessary to symlink or copy. I just don't think that should be the default. On the other hand, the flexibility of using one or more .css for each <theme><lang> offers designers substantial savings in terms of development/update/modification time... (IMHO)... For example, compared with editing one or more .html or .tmpl. files, the use of .cs makes it trivial for a designer to turn off/on site-wide underlining (see prev. message here from Ambrose Li). As per previous message from Rachel, there _are_ problems with browser compatibility - especially Netscape 4.0. On the other hand, I have participated in a .css project of some scale (education assessment exercise) where it was a requirement that all page layout and style was performed by use of .css only (no tables etc)... and where the requirement was complete compatibility with an early version of NS4. So long as you don't go "css crazy", I believe (from experience) that using css is surprisingly effective... and browser compatibility is _always_ an issue - no matter what design approach you choose. .CSS is a bit like wine... starts out tasting like poison but most people who persevere soon develop a taste for it <grin> R.
Andrew Arensburger schrieb:
Mostly, except for the location of *.css files. (I confess that I'm almost entirely ignorant about CSS, so I'll ask you to put up with naive questions, and to enlighten me when I'm wrong.)
As I understand it, stylesheets specify colors, fonts, and all of those little presentation details. In particular, AIUI, stylesheets do not specify content. So why would the *.css files go in <theme>/<lang>? How are the French link colors different from the Italian or German colors? Okay, so the Japanese and Cherokee versions of the web page will obviously use different fonts. But most everything else will be identical across languages, right? Perhaps there should be theme-wide CSS and a separate per-language CSS?
I'm mainly concerned with duplication ("Pragmatic Programmer" tip #11: Don't Repeat Yourself). If default/en/style/foo.css and default/jp/style/foo.css are separate, and need to be kept in sync, they _will_ drift apart. The same thing applies to language-specific templates.
We yet have a solution for this problem, it's very easy: Finlay Thompson wrote:
language specific. Anything that is not language specifc can go in the /<theme>/<all>/ directory. I dont think there will be anything not theme specific.
So a stylesheet for more than one language of a theme would go in <serverroot>/<theme>/all/styles/veryimportantstyle.css It can be included with <link rel="stylesheet" type="text/css" href="/<theme>/all/styles/veryimportantstyle.css"> A style which is specific to a single language would go in <serverroot>/<theme>/<lang>/styles/lessimportantstyle.css It can be included with <link rel="stylesheet" type="text/css" href="/<theme>/<lang>/styles/lessimportantstyle.css"> You may substitute '<theme>/<lang>' by '<TMPL_VAR NAME=themelang>'. Note: this structure is also valid for other things than styles, e.g. images. A background-image, which is the same in all languages of the default-theme would be in <serverroot>/default/all/images/somebackground.jpg A text-image, which of course is different in every language goes in <serverroot>/default/en/images/englishtextimage.jpg <serverroot>/default/de/images/germantextimage.jpg The link in the english template leads to englishtextimage.jpg and the link in the german template to germantextimage.jpg. BTW: generally textimages make the translations more difficult and should therefor be avoided. dorian
Dorian Meid wrote:
BTW: generally textimages make the translations more difficult and should therefor be avoided.
As the problem is the same in every language, katipo promised to create background image where we put the text. KATIPO => is it done, and if yes, where is it ? -- Paul
paul POULAIN schrieb:
Hi,
Finlay, a few days ago, said : "However, there is no reason we can have heaps of CSS in the templated koha. It just goes into files that are read in through <TMPL_INCLUDE NAME="stylesheet"> tags."
I agreed, but, i'm less sure now... I explain : css has 2 goals : one important, and one less. * the 1st goal, as finlay said, is to separate content from style. The <TMPL_INCLUDE> solution respects this. * the 2nd goal is to lower data traffic between server and client : the html does not contain many "style tags" as they are all in the css, and the css, when extenal, is CACHED, and passed only once to the client !
If we use css inclusion in htm file, we loose the 2nd goal. But... it we use a <link rel="stylesheet" type="text/css" href="style.css">, we must put the style sheet in htdocs scope, not in cgi. Thus, we need a /template/<theme>/<lang> in both cgi and htdocs.
what do you think of this ? do you have a problem with having a /template... in htdocs as well as in cgi-bin ? do you think we can forget "data traffic optimization" ?
We don't need a <theme>/<lang>/ structure in the cgi-tree. The scripts in the cgi-tree are the same for all themes and languages. We allready have a <theme>/<lang>/ structure in the htdocs(serverroot)-tree. Roger Buck wrote:
As I NOW see it, the web space file system might look like:
<serverroot>/<theme>/<lang>/ ./images ./includes ./styles ./jscripts ./help ./catalogue ./members ./whatever...
This means that each theme is effectively almost a virtual server in terms of file structure (I think I have this right Dorian?). This would require a change in current CVS thinking.
So style.css goes to <serverroot>/<theme>/<lang>/styles/ and you can include it with <link rel="stylesheet" type="text/css" href="styles/style.css"> or with <link rel="stylesheet" type="text/css" href="/<TMPL_VAR NAME="themelang">/styles/style.css"> Where is the problem? dorian
Hi Dorian, Paul, and everyone else, I think Dorian has it right here. I have to admit to not having tried this, but I cant see why it wont work. Dorian wrote:
So style.css goes to <serverroot>/<theme>/<lang>/styles/ and you can include it with <link rel="stylesheet" type="text/css" href="styles/style.css"> or with <link rel="stylesheet" type="text/css" href="/<TMPL_VAR NAME="themelang">/styles/style.css">
That should work really well. An Paul, the templating mechanism is completely invivisible to the browser: HTML::Template will get the correct theme/path setting and put it into the page before it gets sent to the browser. The stylesheet just has to be in the right place in the filesystem under the <serverroot> (htdocs directory). The stylesheet line above could even be in the top include :-) On the matter of filesystem structure:
<serverroot>/<theme>/<lang>/ ./images ./includes ./styles ./jscripts ./help ./catalogue ./members ./whatever...
This means that each theme is effectively almost a virtual server in terms of file structure (I think I have this right Dorian?). This would require a change in current CVS thinking.
This is exactly right. In terms of the existing cvs tree, there has been one strange development.... All the templates, includes, images etc should be in the above structure under either: koha/koha-tmpl/intranet-tmpl/ or koha/koha-tmpl/opac-tmpl/ The strange thing is that the koha-tmpl tree is in the koha main branch. It should probably have been in koha-html :-( I didnt notice fast enough to change it. Maybe later? As for the old koha-html cvs tree: it dies. slowly, perhaps painfully. But most of that stuff will be replaced by the new koha-tmpl stuff. We will know when koha is properly templated when non of the koha-html files is needed. Finlay
finlay@wilbur.katipo.co.nz wrote:
Hi Dorian, Paul, and everyone else,
I think Dorian has it right here. I have to admit to not having tried this, but I cant see why it wont work.
Dorian wrote:
So style.css goes to <serverroot>/<theme>/<lang>/styles/ and you can include it with <link rel="stylesheet" type="text/css" href="styles/style.css"> or with <link rel="stylesheet" type="text/css" href="/<TMPL_VAR NAME="themelang">/styles/style.css">
That should work really well. An Paul, the templating mechanism is completely invivisible to the browser: HTML::Template will get the correct theme/path setting and put it into the page before it gets sent to the browser. The stylesheet just has to be in the right place in the filesystem under the <serverroot> (htdocs directory). The stylesheet line above could even be in the top include :-)
yes. The problem, for me, was that templates are not on <serverroot> because, as stated later, the templates where not in koha-html. Now everything is clear...
On the matter of filesystem structure:
<serverroot>/<theme>/<lang>/ ./images ./includes ./styles ./jscripts ./help ./catalogue ./members ./whatever...
This means that each theme is effectively almost a virtual server in terms of file structure (I think I have this right Dorian?). This would require a change in current CVS thinking.
This is exactly right. In terms of the existing cvs tree, there has been one strange development....
All the templates, includes, images etc should be in the above structure under either: koha/koha-tmpl/intranet-tmpl/ or koha/koha-tmpl/opac-tmpl/
The strange thing is that the koha-tmpl tree is in the koha main branch. It should probably have been in koha-html :-(
I didnt notice fast enough to change it. Maybe later? As for the old koha-html cvs tree: it dies. slowly, perhaps painfully. But most of that stuff will be replaced by the new koha-tmpl stuff. We will know when koha is properly templated when non of the koha-html files is needed.
That's what i noticed and troubled me a lot... now, it's clear... -- Paul
participants (8)
-
Ambrose Li -
Andrew Arensburger -
Dorian Meid -
finlay＠wilbur.katipo.co.nz -
Owen Leonard -
paul POULAIN -
Rachel Hamilton-Williams -
Roger Buck