First usage and experimenting

I wonder what people think of using a new topic to store the style sheet for the site. I created a new topic called TWiki.StyleSheet and entered standard CSS tags.

I then created a new skin which had no html (it was simply the TEXT variable) and called it view.code.tmpl

I then modified the edit.tmpl to include the link to the stylesheet at bin/view/TWiki/StyleSheet?skin=code

I think this could be used to include a javascript as well (ie create a javascript function and call it as an include on another page)... you could start to even use this to make templates etc...

Hmmm... building the wiki using the wiki... cool!

-- AdrianLynch - 08 Nov 2001

Yes, I have also done it myself. I was cautious and put the css rather as an attachemnt, but we can do it your way

Can it also work with ?raw=on rather than ?skin=code ? With the skin you run the risk of TWiki interpreting some CSS syntax as TWiki syntax...

-- ColasNahaboo - 08 Nov 2001

What I did to avoid that (and it's not very elegant) was add /* <verbatim> */ at the top of the topic and the appropriate closing tag at the bottom...

This means when viewed with the code skin, TWiki renders the page using <pre> tags but these are surrounded by the CSS comment tags /* & */ and thus ignored.

If I specify the ?raw=on it displays raw text however in a textarea which could confuse things as well. I'll look into it further...

-- AdrianLynch - 08 Nov 2001

This is a great idea for administration, I wonder how much of a security risk it might be though. For our intranet setup this is not a concern though so I love the idea.

-- MattWilkie - 08 Nov 2001

Is there currently anyway to retrieve a topic as plain text via the web. Ideally like ?raw=code or similar, so that it would display the unmodified text file, with no additional html? Also possibly without any meta data. This would then allow retrieving a topic to use it for javascript/css etc without the weird /* <verbatim> */ syntax above.

-- AdrianLynch - 08 Nov 2001

Click "More" at the bottom of this page, then look for the "Raw" checkbox under the "View previous topic revision" -- doesn't that do what you want? (I think this is new with the 20010901 release.)

-- RandyKramer - 09 Nov 2001

No, that presents the raw text within a text area. Even with a blank skin (ie with just %TEXT% in it) it will still render the form and textarea tags... What I suggest is exactly and only what you type into the textarea be returned. This means you can enter CSS and JavaScript tags without extraneous tags been added.

After looking at the Twiki::View source I would expect the best and most consistant method for calling this would be ?raw=code. You could then have a twiki variable in the preferences that specifies the topic to use as a style sheet ie. set TWIKICSS = Twiki.StyleSheet or this could be specified in a template or user preferences.

-- AdrianLynch - 09 Nov 2001

Further looking into this, I reformatted the style sheet page so that it has no spaces between the style tags and no spaces in front of each element. This way TWiki does not try to render any <p&gt: and <li> tags. This means I do not need to use verbatim and /*.

Style Sheets seem to suit twiki perfectly, Is there any plan to use CSS1 exclusively for formatting? I expect it would simply things as it reduces the number of variables and 'formatting style' spread across the twiki code, plugins etc...

It also means each web or user could use it's own style sheet, or just extend on the default...

-- AdrianLynch - 18 Nov 2001

FUN! This is a cool alternative. I'd been noodling around with CSS on regular templates. Doing away with tables and stuff took a little getting used to, and I didn't get that much done. I recently started emailing a couple of hardcore CSS coder/designers to see if they'd volunteer "a couple hours max" to maybe design or adapt a basic pure CSS2 TWiki template.

See also: TWikiUsingCSS for one CSS general discussion start... There are a bunch of good CSS discussions from here and there in Codev, to gather as well. Will post back!

-- MikeMannix - 22 Nov 2001

Have a look at MozillaSidebar - I've used a (fairly basic) embedded stylesheet on the WebSidebar page that gets added to Mozilla sidebars. You can still see how the page looks even if you don's use MozillaBrowser.

Sidebars are very nice - you can flick between webs very easily, and I'm going to add some extra features such as WebFastIndex and a search field, right in the sidebar. They end up acting as a cache of recently modified pages, avoiding some use of the Back button.

Q: Do sidebars exist in a user-definable fashion in InternetExplorer?

-- RichardDonkin - 09 Feb 2002

Answering my own question - there are sidebars in InternetExplorer but they require 'real code' - fortunately you can define something that looks very like a separate sidebar, using an embedded stylesheet. Have a look at WebSidebar to see the formatting, and suffix ?skin=plain to see it 'for real'.

-- RichardDonkin - 13 Feb 2002

Linking style topic contents in twiki.tmpl

• I am experimenting with that for the pattern skin (see Other testpages: on page). Problem: how to prevent error messages when the to include topic does not exist? -- ArthurClemens - 16 Jan 2004
• If instead of using static files the CSS was served from topics via a script then you could get the script to return a default/blank CSS file for topics that doesn't exist. btw, I've been watching the progress of pattern skin and those pages look gorgeous! -- SamHasler - 16 Jan 2004
• Thank you. In twiki.tmpl use %INCLUDE{MyCSSTopic}%, but that returns a default error when the topic does not exist. Trying to evaluate with SpreadSheetPlugin gives mixed results: in most browsers the INCLUDE is expanded before evaluation (Safari does a good (?) job). I want to see if I can use the same principle to remove/add top and footer bars. -- ArthurClemens - 16 Jan 2004
• Sorry you've lost me, surely INCLUDES are done on the server side?
  The solution I'm thinking of would use something like @import url("%SCRIPTURL%/css%SCRIPTSUFFIX%/%STYLETOPIC%"); where there was a css script to serve the STYLETOPIC as a CSS file with the correct content type heading. -- SamHasler - 16 Jan 2004

-- SamHasler - 16 Jan 2004

surely INCLUDES are done on the server side?

Yes, but why not put this in a tmpl file? Like this:

<style type="text/css" media="all">
      @import url("%PUBURL%/skins/pattern/pattern_base.css");
      @import url("%PUBURL%/skins/pattern/pattern_special.css");
</style>
%INCLUDE{"%STYLETOPIC%" warn="off"}%

this example

And looking up %INCLUDE% I just saw I can use 'warn="off"' to suppress the warning message. This solves my problem.

-- ArthurClemens - 16 Jan 2004

Yeah sure, if you want a simple life

Just a thought, are there any security implications to this. What could someone put in the header of a html file that might not want them to?

-- SamHasler - 16 Jan 2004

This is what I'm using in SeeSkin master twiki template (example generalized for any skin):

<link rel="stylesheet" href='%CSSSOURCE%/%EXTSTYLE%' 
   type="text/css" media="screen,projection" />
<style type="text/css"><!-- %INLINESTYLE%  --></style>

and these set in Preferences:

      * Set CCSOURCE = %PUBURLPATH%/%PLUGINWEB%/%SKIN%
      * Set EXTSTYLE = ss-default.css
      * Set INLINESTLE = body {background-color: %WEBBGCOLOR%} etc..

INCLUDEing a CSS topic works but I don't do that because a) the styles are inline, adding needless bloat to every page served, b) include impacts performance.

The stylesheet is attached to the plugin skin topic. You could reference the physical path to a regular topic containing CSS in CCSOURCE and EXTSYTLE (untested) but there is non-ccs text in the META records which could get in the way.

INLINESTYLE is for short light-weight re-definitions, for example changing the background color and base font-familiy according to the current web, user (or even topic).

It's a pain to download the stylesheet, make changes, upload the stylesheet, refresh; lather, rinse, repeat. It's very tempting to just overload INLINESTYLE (resist! resist!). Still it does allow css development without needing file-level access to the server. And if you use Mozilla with the "Edit Styles" 'marklet you can adjust styles before downloading to make permanent edits.

-- MattWilkie - 16 Jan 2004

While most of your discussion here is still over my head, I thought I'd interject one comment about Matt's approach described here. When defining the INLINESTYLE in preferences, it seems to have the side affect of applying that styling to the preference topic.

• As long as there is no <style> around the definition, it is only text. -- ArthurClemens - 16 Jan 2004

In regards to the edit cycle, I've been very pleased with using either jEdit or Crimson Editor which allows me to edit my templates and css sheets right from by server (assuming simple ftp access). This makes if very easy for me to tweak a style sheet and see the results immediately.

-- LynnwoodBrown - 16 Jan 2004

Matt:

I prefer to put overriding styles in style topics, so you can evaluate their effect immediately: just put some test text in the topic and you can see what the style does.

>INCLUDEing a CSS topic works but I don't do that because a) the styles are inline, adding needless bloat to every page served,

you are also including the custom style inline, see the source of a SeeSkin page:

&lt;style type="text/css"&gt;<!--
   #logochar{color:#ead9cc} #menu{background-color:#ccab90} body {background-image:url(/pub/Plugins/SeeSkin/maphew-main.png); background-position: left bottom; background-repeat: no-repeat; background-attachment: fixed; background-color: #f7f6e5;} #content {border-color:#wad9cc;}
-->&lt;/style&gt;

... adding bloat to the html too, so I don't see any performance improvement here.

yes, but much less bloat than if the complete stylesheet were inline. The inline styles are <300 characters while the linked stylesheet is nearing 10,000. --MW

If %INLINESTYLE% would be a topic that was linked with

<link rel="stylesheet" href='...

The solution would be to get the full url path of the to include topic, so that can be used to link (but then you can't use <style> around the style, and cannot evaluate it in the topic ).

-- ArthurClemens - 16 Jan 2004

Trying to link the topic file with <link rel="stylesheet" >

I have written some code to get the full path of a topic (see example).

• I assume you need this because a stylesheet topic may be in any web, not necessarily the same web as the topic to be displayed. So you can't just use %SCRIPTURL%/view/%WEB%/%STYLETOPIC% as the stylesheet may be specified as BlueStyle or skinweb.BlueStyle.
  Oh, you're not trying to do what I thought you were, you're trying to link to the .txt file for the topic as it exists on the file system. Doesn't that remove any security that ALLOWTOPICVIEW provides? Why not have a variable %TOPICURL{"..."}% to provide a link to the topic using the view script that will accept topic or web.topic and use the mechanism I've outlined below? -- SamHasler - 19 Jan 2004
• Another thought, how does your code (could we have a look at it?) handle multiple topics with the same name? If there was one in the same web as the topic to be displayed and one in another web would it always find the one in the same web? -- SamHasler - 20 Jan 2004

Problem now is that the topic has a line of %META%, that the

<link rel="stylesheet"...

This is the case when the %META% information is at the top of the topic; if it is at the bottom, the stylesheet gets linked normally. And that would solve all problems! Is there a way to force the %META% info to the bottom?

-- ArthurClemens - 17 Jan 2004

I see (GenericMetaDataStoreForTopics) that some meta data is stored at the top of the topic, and some at the bottom. As long as there is meta data at the top, the (efficient) linking of CSS topics will not work.

-- ArthurClemens - 17 Jan 2004

Update: what does work is when you put <-- /* */ --> around %META%, with newlines before and after meta, like this:

<!-- /*
*/ -->
h1, h2, h3, h4, h5, h6 {
color: #444;
}

• Use /* */ to exclude meta from the style sheet
• use <-- --> to exclude meta from the html page

This way meta can be at the top of the topic file, AND the rest of the file gets rendered as style.

But... the writing procedure of META needs to be updated to cater for the extra comment tags, otherwise the comment tags end up as copy in the topic text.

-- ArthurClemens - 17 Jan 2004

The best strategy seems to me to change the write procedure in Meta.pm, to put all META contents at the bottom. Reading GenericMetaDataStoreForTopics it appears that using META both at the top and at the bottom of the file was an arbitrary decision, so why not change it?

Question: the sub write in Meta.pm is called twice with each save (due to sub saveTopic in Store.pm), and some regex wizardry is going on that is above me, in the "new line is required at end":

# Prepend/append meta data to topic
sub write
{
    my( $self, $text ) = @_;
    
    my $start = $self->writeStart();
    my $end = $self->writeEnd();
    $text = $start . "$text";


    $text =~ s/([^\n\r])$/$1\n/;     # new line is required at end
    $text .= $end;
    
    return $text;
}

How to change this procedure to put the META at the bottom, and possibly how to prevent that it is called twice?

-- ArthurClemens - 17 Jan 2004

Arthur, you were reading too hastily. I acknowledged that I had to place some style inline, in order to do things like use WEBBGCOLOR%, but emphasized the need to keep it as light as possible. The inline style is under 300 characters while the external linked sheet is nearing 10,000. While not optimal it is still a great improvement.

Moving metadata to the end and embedding in comment markers as you describe seems workable. Limited inline styles would still be necessary to make use of variables which change from web to web and topic to topic.

-- MattWilkie - 19 Jan 2004

I believe the placement of certain metadata at the top of the document is not entirely arbitrary. The most commonly used bits are placed at the top because reading the first line(s) of a text block is a bit quicker than going down and reading the last line(s). But I don't think it matters that much, nor do I know if the rest of the META code can deal properly with all the information moved to the bottom. Here is a rewrite of the procedure to append both bits at the bottom. No guarantees that it'll have the desired results! I haven't looked at the TWiki code in ages and don't have time to right now, so this is just a quick hack-job.

# Append meta data to topic
sub write
{
    my( $self, $text ) = @_;
    
    my $start = $self->writeStart();
    my $end = $self->writeEnd();

    $text =~ s/([^\n\r])$/$1\n/;     # new line is required at end
    $start =~ s/([^\n\r])$/$1\n/;     # new line is required at end
    $text .= $start . $end;
    
    return $text;
}

With respect to the regex magic: here's how you decompose that expression: In the $text variable "$text =~", substitute "s/" any non-newline character "([^\n\r])" at the end of the text "$" with "/" the first parenthesized thing matched "$1" (i.e. the non-newline character) and then a newline "\n", period "/;". In plain English, if there isn't a line break at the end of the topic text, it adds one.

-- WalterMundt - 19 Jan 2004

I've been looking at the code and I think Adrian's ?raw=code idea might work with a few changes to the view script. It should be possible to disregard skins and templates and just serve the raw content of the topic with the correct content-type. This is basicaly the script approach I was thinking of above, but just making it an extension of the view script. I think this is a better approach than trying to comment out the meta data. I'll let you know how I get on.

-- SamHasler - 19 Jan 2004

I took some inspiration from the way the rss skin is handled and decided to implement it as a skin instead. I created a view.css.tmpl that just contained %TEXT% and altered the view script to not put the form around raw text for the css skin.

Here's a patch from BeijingRelease

 
*** twiki20030201/bin/view     Thu Jan 30 09:21:25 2003
--- twiki/bin/view     Mon Jan 19 13:40:57 2004
***************
*** 151,164 ****

      if( $viewRaw ) {
!       my $vtext = "<form><textarea readonly=\"readonly\" wrap=\"virtual\" rows=\"%EDITBOXHEIGHT%\" cols=\"%EDITBOXWIDTH%\">";
!       $vtext = &TWiki::handleCommonTags( $vtext, $topic );
!         $text =~ s/&/&amp\;/go;
!         $text =~ s/</&lt\;/go;
!         $text =~ s/>/&gt\;/go;
!         $text =~ s/\t/   /go;
!       $text = "$vtext$text</textarea></form>";
!       if( $viewRaw !~ /debug/i ) {
!           $text =~ s/%META[\:A-Z]*{[^\}]*}%[\n\r]*//gos;
!       }
      }

--- 151,167 ----

      if( $viewRaw ) {
!         if( $skin !~ /^css/ ) {
!             my $vtext = "<form><textarea readonly=\"readonly\" wrap=\"virtual\" rows=\"%EDITBOXHEIGHT%\" cols=\"%EDITBOXWIDTH%\">";
!             $vtext = &TWiki::handleCommonTags( $vtext, $topic );
!             $text =~ s/&/&amp\;/go;
!             $text =~ s/</&lt\;/go;
!             $text =~ s/>/&gt\;/go;
!             $text =~ s/\t/   /go;
!             $text = "$vtext$text</textarea></form>";
!
!         }
!         if( $viewRaw !~ /debug/i ) {
!             $text =~ s/%META[\:A-Z]*{[^\}]*}%[\n\r]*//gos;
!         }
      }

To view a topic as CSS you need to pass the parameters ?raw=on&skin=css&contenttype=text/css. It might make sense to force the content-type to text/css for the css skin but I was looking for the simplest patch possible as a proof of concept.

See also comment above about getting the full url of a topic.

-- SamHasler - 19 Jan 2004

Sam, that is interesting. Only I do get to see the %META% with http://www.dekko.nl/cgi-bin/twiki/view/Sandbox/BlueStyle?raw=on&skin=css&contenttype=text/css:

html body {
background-color:#ECF2F9;
color: #444;
font-family: "Georgia", "Times";
font-size: 90%;
}
h1, h2, h3, h4, h5, h6 {
color: #444;
}

As for the code for getting the full url, I use $homeDir from TWiki.cfg. With the variables $homeDir, $dataDir and $defaultUrlHost you can compose the path up till the web. That you can pass with %TOPICPATH{Myweb.MyTopic}% or just pass the topic and use the current web (see for instance example 1 and example 2).

-- ArthurClemens - 21 Jan 2004

I believe it is a security hazard to have the $dataDir open to the browser. I don't know the nature of the hazard. See TWikiInstallationGuide Step 1, bullet 5.

-- MattWilkie - 21 Jan 2004

Arthur, can you confirm that the if( $viewRaw !~ /debug/i ) clause appears outside the if( $skin !~ /^css/ ) clause as above. I think I migth have edited the topic with it inside and then re-edited it to the same revision with it outside.

I agree with Matt on the security issue. Hopefully it's a non-issue as if we can get the view method to work as I think is more intuitive from the outside as to what it is doing and doesn't have the same security implications.

-- SamHasler - 21 Jan 2004

Yes, that was it. The method looks like:

if( $viewRaw ) {
      if( $skin !~ /^css/ ) {
         my $vtext = "<form><textarea readonly=\"readonly\" wrap=\"virtual\" rows=\"%EDITBOXHEIGHT%\" cols=\"%EDITBOXWIDTH%\">";
         $vtext = &TWiki::handleCommonTags( $vtext, $topic );
            $text =~ s/&/&amp\;/go;
            $text =~ s/</&lt\;/go;
            $text =~ s/>/&gt\;/go;
            $text =~ s/\t/   /go;
         $text = "$vtext$text</textarea></form>";
      }
      if( $viewRaw !~ /debug/i ) {
         $text =~ s/%META[\:A-Z]*{[^\}]*}%[\n\r]*//gos;
      }
    }

And this works fine. I guess I now have to use %URLPARAM% to pass the parameters to the %STYLETOPIC%?

-- ArthurClemens - 21 Jan 2004

You should just need to add something to the stylesheet that will resolve to:

@import url("http://www.dekko.nl/cgi-bin/twiki/view/Sandbox/BlueStyle?raw=on&skin=css&contenttype=text/css");

when it gets to the client, like:

@import url("%TOPICURL{"BlueStyle"}%?raw=on&skin=css&contenttype=text/css");

assuming you can re-write TOPICPATH into TOPICURL and taking into account the multiple topic issues I highlighted above.

-- SamHasler - 21 Jan 2004

@import url("../Web.Topic?skin=text?raw=on&skin=css&contenttype=text/css"); works fine now. Good work! I will attach the view patch later.

I guess this method will work also to dynamically include javascript files.

-- ArthurClemens - 21 Jan 2004

It should work for javascript, you might want to change the content type to something like contenttype=text/javascript. Perhaps a more generic skin name than css is needed?

Is there any way to avoid having @import url("?raw=on&skin=css&contenttype=text/css"); when no %STYLETOPIC% is specified?

-- SamHasler - 21 Jan 2004

Using a wrong or empty %STYLETOPIC% would be ok, I think it doesn't generate an error. See http://www.dekko.nl/cgi-bin/twiki/view/Sandbox/PatternTestPageWithWrongInclude?skin=newpattern.

-- ArthurClemens - 21 Jan 2004

If the base is http://www.dekko.nl/cgi-bin/twiki/view/Sandbox/PatternTestPageWithWrongInclude does that mean that @import url("?raw=on&skin=css&contenttype=text/css"); will be importing the raw topic as a css file? My IE history doesn't show it but what about other browsers? Will it make any kind of request to the server or will browsers ignore it?

I think you're right, it probably isn't an issue. I just raise it in case something does crop up.

-- SamHasler - 21 Jan 2004

i don't believe there are an issues with browsers; however, apache will put an entry in error_log about being unable to find the file. this is something i am willing to live with for the capabilities and features provided. and, one way to solve the problem is simply to ensure that %STYLETOPIC is valid.

i wonder if this will present any interaction problems with CacheAddOn ?

-- WillNorris - 21 Jan 2004

Does this also work with <link rel="stylesheet" href'STYLETOPIC%?raw=on&skin=css... etc> ? I'd rather not have to use import for everything if I don't have to.

-- MattWilkie - 21 Jan 2004

Yes, it works:

&lt;link rel=stylesheet href="%<nop>STYLETOPIC%?raw=on&skin=text&contenttype=text/css" type="text/css" media="screen"&gt;

( I've changed view.css.tmpl to view.text.tmpl)

-- ArthurClemens - 21 Jan 2004

I'd like to be able to use <verbatim> tags to make the ccs/javascript more readable when viewing the topic without haveing to have enclosing "/*" & "*/" comments.

It would be useful if there was a way to put in ccs/javascript comments so that they didn't appear when the page is viewed, but get converted to proper comments when using the text skin. So that you could have TWikiML that appears correctly when viewing, and is inside a comment in the served page.

• what about OverridePreferenceSettingsInTopics for the skin variable on the css topic to get per-page skins? ( technique also mentioned in MultipleWebs ) -- WillNorris - 22 Jan 2004

Another solution might be to make the text skin act like an include, so that %STARTINCLUDE% and %STOPINCLUDE% could be used.

Is it worth updating the progress fields in the WebForm?

-- SamHasler - 22 Jan 2004

Implementation

Summary of the above:

The proposed patch of the view script allows to call a topic with a skin=text parameter: .../MyTopic?raw=on&skin=text. With this skin=text no textarea form is build around the text, while metadata is left out as well.

• attached patch file to view script. Use MyTopic?raw=on&skin=text&contenttype=text/css to get the text without meta data.
• attached template with only %TEXT%. This template is needed as it is called in the line above with "skin=text"
• When used with the dynamic preference variable STYLETOPIC as described in OverridePreferenceSettingsInTopics, you have per topic control of the style sheet you attach. STYLETOPIC can be set in each topic using Set STYLETOPIC = SomeTopicWithCSSDescription
  • SomeTopicWithCSSDescription has css without <style></style> around it.
• In twiki.yourskin.tmpl, use:

<style type="text/css" media="all">
      @import url(%STYLETOPIC%?raw=on&skin=text&contenttype=text/css");
</style>

<link rel=stylesheet href="%STYLETOPIC%?raw=on&skin=text" type="text/css" media="screen">

• Example

Extending to include custom javascripts

• Create a variable JSSCRIPTTOPIC in WebPreferences
• In twiki.yourskin.tmpl, add this line:

<script src="%JSSCRIPTTOPIC%?raw=on&skin=text"></script>

• Create a topic with javascript code. Don't put <script></script> around it.
• Set the script to a topic by defining in the topic Set JSSCRIPTTOPIC = MyTopicWithScript
• Example

-- ArthurClemens - 21 Jan 2004

I seem to remember reading somewhere that (some?) browsers don't cache URLs with ?'s in them. Can anybody please disprove/verify this? It'd be a shame to go through all this only to find out the browser still fetches the stylesheet for every page.

-- MattWilkie - 23 Jan 2004

IE does cache them. It also caches the ?t=xxxxxxxxxx edit pages. Was the t=xxxxxxxxxx needed just for IE or for all browsers?

-- SamHasler - 26 Jan 2004

On Mac OS X, both Safari and Netscape cache the page as well.

I think this patch should go into the next beta release.

-- ArthurClemens - 08 Feb 2004

Patch accepted, and committed into CVS. Had to apply the patch with the -l flag because your editor messed with the tabs in the original before you ran the diff...might want to be careful of that in the future.

-- WalterMundt - 13 Feb 2004

Re caching - RefreshEditPage (the ?t=nnnnnnn feature) was added mainly for Opera, which aggressively caches almost everything. Some other browsers don't cache pages with ? in the URL, but it depends on the browser setup, and of course proxy caches in the middle can affect things. There are some links in BrowserAndProxyCacheControl that discuss caching in general and how it works. Google:cache+busting will give hints on how to prevent links being cached, so if your planned URLs fit into those patterns you may find some browsers don't cache the style sheet.

If necessary, we could generate 'cache for a long time' headers for stylesheets, as with the BackFromPreviewLosesText fix, which cause IE and most other browsers to almost always cache the page.

-- RichardDonkin - 16 Feb 2004

I'm thinking we need a new script called text to handle this which would handle the raw and skin without having to define it (could probably do away with the skin and hard code it). Which means we need some other method of defining the content-type of the topic. I was thinking it could allow you to put your own in, and prepend "content-type: plain/text\n\n" if you don't.

I'll try and code something soon unless anyone can point out a problem with this approach.

(As an enhancement we could do something similar to PageType, or extend it to cover content-type.)

-- SamHasler - 20 Feb 2004

Documentation note: when you include a style topic in another web you must use the slash syntax Myweb/MyStyleTopic, for instance:

   * Set STYLETOPIC = Extranet/ClientStyle

no, that does not work: you must reference the topic file with dot dot slash:

   * Set STYLETOPIC = ../TWiki/ClientStyle

-- ArthurClemens - 15 Feb 2004

That's not very friendly, perhaps we do to implement the %TOPICURL{"..."}% variable I suggestedhere.

-- SamHasler - 16 Feb 2004

But that is not expanded in <head>.

• reworded my comment above. -- SH

-- ArthurClemens - 16 Feb 2004

Set the SpecProgress & ImplProgress to 50% from 100% due to Richard's comment above.

-- SamHasler - 17 Feb 2004

Re the dot dot slash requirement, it is rather unusual to reference the topic in this manner. I would suggest that you change this to TWiki.ClientStyle, as in

   * Set STYLETOPIC = TWiki.ClientStyle

-- ThomasWeigert - 19 Feb 2004

I've written a patch to get the relative file path of a topic. Use ../Web.MyTopic to get: ../Web/MyTopic.

In the style definition you use: @import url("../Web.Topic?skin=text?raw=on&skin=text&contenttype=text/css");

Diffed against TWiki.pm from TWiki20040119beta.

-- ArthurClemens - 19 Feb 2004

Nice Arthur. RELATIVETOPICPATH is a much better name/function than TOPICURL.

How would users defining STYLETOPIC on their home page affect this? Is it possible to load stylesheets for both the users setting and the topic's setting? Which should have presidence?

-- SamHasler - 19 Feb 2004

I think we should mirror normal CSS behaviour: you can always define a personal style sheet. So in TWiki the user preference should always be final. This is in fact dependent on implementation in OverridePreferenceSettingsInTopics, but currently this is the order in Prefs.pm.

-- ArthurClemens - 19 Feb 2004

How do normal CSS personal stylesheets work? Do they replace all other stylesheets or do the stylesheets get combined with the personal stylesheet overriding other stylesheets. The way the STYLETOPIC variable works we would get the former but I had assumed the latter was the case for personal style sheets in browsers. If I'm wrong then I don't see a problem.

So if a topic has a STYLETOPIC = DraftTopicStyle to make the background blue, and a user in thier home topic has set STYLETOPIC = SanSerifFontStyle then when that user views that topic they would not see the blue background. Is that what we really want?

-- SamHasler - 20 Feb 2004

Hmm, actually I've never worked with user style sheets before. But reading a bit it seams reality is complex:

Sort by origin
Rules with normal weight declared in author's style sheet will override rules with normal weight declared in user's personal style sheets
Rules with increased weight declared in user's personal style sheet will override rules with normal weight declared in author's style sheet
Rules with increased weight declared in author's style sheet will override rules with increased weight declared in user's personal style sheets
Author's and user's rules will override UA's default style sheet.

source: CSS Frequently Asked Questions - The HTML Writers Guild

This is not the mechanism we have now.

But I would definitely vote for user styles take preference over autor styles, because there might be a sound reason (visual handicap for instance). How this is implemented depends on the tmpl skin - in the PatternSkin I am developing, I load the topic style as secondary style (the first style belongs to the skin appearance and is not changable in a topic):

      @import url("%PUBURL%/skins/extranet/base.css");
      @import url("%RELATIVETOPICPATH{%STYLETOPIC%}%?raw=on&skin=text&contenttype=text/css");

This approach means that the style

#main {
   width: 70%;
   margin-left: 15%;
   margin-top: 0;
}

... in base.css can be overridden in the personal topic style by redefining or adding attributes, such as:

#main {
   background-color: yellow;
}

But of course in your own skin you could always import only one style and make that a user (topic) preference.

-- ArthurClemens - 20 Feb 2004

I'm not sure if that applies in this case, we are only creating author stylesheets. However, if you look at the last line of point 5:

5. Sort by order specified
If two rules have the same weight, the latter specified overrides ones specified earlier. Style sheets are sorted out as follows:

The STYLE attribute (inline style) overrides all other styles
The Style element (embedded style) overrides linked and imported sheets
The LINK element (external style) overrides imported style
The @import statement - imported style sheets also cascade with each other in the same order as they are imported

What I would like is for the topic and user topic stylesheets to be imported. You could argue that if the user wanted to use thier user topic setting to have a "user stylesheet" that they should do it in thier browser but if we do load both then the user can customise the look of the site from whereever they are connecting from and whatever browser they are using.

-- SamHasler - 20 Feb 2004

I notice this topic has been re-used for a new patch. To avoid confusion, I'd prefer it in the future if new patches == new PatchProposals. Simply make a new proposal and attach the new patch to it. Then mention the new proposal in the topic of the related one, if necessary.

If you have a patch that's updated but affects the same code, then you should do one of two things:

• If your patch was already accepted, post a new patch that only has the updates (e.g. diff from the old-patched-version to the new-patched-version. Using a TWikiAlphaRelease from after the patch was accepted as the base for your changes gives you this for free.)
• If not, you should just update the patch in the PatchProposal topic, resetting the patch from PatchAdjustmentRequired to PatchProposal if applicable.

Don't worry about it this time; I'm gonna commit the new patch sometime soon. There is a small error in it, however. Can you spot it?

-- WalterMundt - 21 Feb 2004

Yes, there is this error:

+               $theRelativePath = $theWeb . "/" . $theRelativePath;

should be

+               $theRelativePath = $theWeb . "/" . $theStyleTopic;

Overlooked after copy paste. I've updated the patch attachement.

And I will post in the future as you outlined.

-- ArthurClemens - 21 Feb 2004

Okay, patch is committed. I had to patch in the changes manually because you're using a TWiki.pm from before the doc comments were put in, or I would have done this sooner.

-- WalterMundt - 23 Feb 2004

If you have a topic that INCLUDES other topics, omit the raw=on in the @import.

-- ArthurClemens - 07 Apr 2004

Forget this, I can't get this including multiple topics to work. I think the topics are not expanded fully at the time the import of the topic is being done.

-- ArthurClemens - 07 Apr 2004

While I was playing around with this I fixed up and commited to cvs updates to the current default templates that use css. So from the next time that twiki.org is updated your customised TWikiStyle and TWikiLayout topics will have effect throughtout all scripts. you will be able (as is exampled in SvenDowideitStyle) to change the rendering of TWikiDiffs, and everything else that has a css classname. As time goes on we will add classes for everthing else, and the TWikiLayoutTopic will be able to be used to totally redefine the look of twiki.

-- SvenDowideit - 09 May 2004

TO DO: refactor stuff above...

/*
<verbatim>
*/
body {
   color:black;
}
etcetera
/*
</verbatim>
*/

body { background-color: black }

body { background-color: black }
h1,h2,h3,h4 { color: black }

   * Set STYLETOPIC = MyWeb.MyTopic

   * Set STYLETOPIC = MyTopic

   * Set STYLETOPIC = MyTopic

Discussion continued

I noticed in the data log file that the style sheet topics are loaded for each topic. We have seen that the browser does cache the stylesheets, but my guess it that twiki renders a new topic every time, and since this is a newer version the browser cached stylesheet is overwritten. This would mean performance is as bad as including a stylesheet in a topic.

-- ArthurClemens - 09 May 2004

I recon that the stuff in #TWikiRevInfo should be removed from teh template, and moved into WebToolBar. Also, It seems that I can't set the TWIKISTYLETOPIC to a url (we have a company stylesheet i wanted to use) and I also can't INCLUDE it on my StyleTopic as the INCLUDE code disallows it, and when I add it like text/plain, it gets html-ised

there are some bad layout bugs that I introduced in the conversion - tick boxes all over the place are the wrong size - hopefully someone who knows about this stuff can fix it

the gap between the WebTopBar and the begining of the topic text is way too large

I'd like to make sure that we use the same CSS tags through all the skins we publish in the release (eg id="TWikiMain")

I'd like to use some TWikiVariables in th StyleTopic, but when I don't use the verbatim tag, or make the layout a mess, I get list element html in my css. this is yeck. maybe we should have a TopicType meta-field that then changes the view renderer

• These variables are not evaluated when the style sheet topic is imported. Made a FAQ entry in de doc above. -- ArthurClemens - 10 May 2004

(working hard to get something ready)

Note: I am not making these chages now as I am not good at UI, and so need a second opionin

-- SvenDowideit - 10 May 2004

I've been thinking that it would be useful to have variables expanded for a while now. It would allow many usefull features like taking web colour settings and using includes to break the stylesheet appart. I don't know why I didn't allow it in my patch but I think I had to remove (ir not copy) a line to get it to not do it so it shouldn't be too hard to turn it back on (Sorry I don't have access to a working install of TWiki at the moment to test something). It might be usefull to also treat the entire topic as an include and ignore everyting before/after STOPINCLUDE/STARTINCLUDE so that the code can have a header and be enclosed in verbatim tags when viewed as a normal TWiki page.

-- SamHasler - 10 May 2004

because the current implementation is limited to using a topic to define CSS, and then allows 4 of them (thats a total of 5 ViewCgiScripts called per topic view) I'd like to suggest that we change it a little.

• Wouldn't the browser cache them after the first topic? -- SH

• • This is what I (we) thought first. The page does get cached by the browser. But at the same time a page view is generated by twiki, making the cached version useless. -- ArthurClemens - 22 Jul 2004

can we change the 4 TWikiPreferences to:

• • Set STYLETOPIC = ../Web.Topic?skin=text

      * Set TWIKILAYOUTURL = http://company.com/companystyle.css
      * Set TWIKISTYLEURL = http://twiki.org/p/pub/TWiki/TWikiPreferences/TwikiStyle.css
      * Set USERLAYOUTURL = %RELATIVETOPICPATH{%TWIKILAYOUTTOPIC%}%?skin=text&contenttype=text/css
      * Set USERSTYLEURL = %RELATIVETOPICPATH{%TWIKISTYLETOPIC%}%?skin=text&contenttype=text/css

this would allow us to use topics while developing the style sheet, and then move them to much faster attachments when done.

• Sounds reasonable to me. -- ArthurClemens - 21 Jul 2004

• this make me want to know why there is no %ATTACHURLPATH{}% that works for an attachement on another topic!

• prehaps full topic as CSS could be implemented when TWiki has a cache out of the box? -- SH

-- SvenDowideit - 21 Jul 2004

        /* NOTE: THESE LINES WILL BE REMOVED FROM THE CURRENT TEMPLATE WITH CAIRO RELEASE */
        /* FOR TESTING PURPOSES ONLY */
        /* Default TWiki layout */
        @import url("%RELATIVETOPICPATH{%TWIKILAYOUTTOPIC%}%?skin=text&contenttype=text/css");
        /* Default TWiki style */
        @import url("%RELATIVETOPICPATH{%TWIKISTYLETOPIC%}%?skin=text&contenttype=text/css");
        /* Custom overriding layout */
        @import url("%RELATIVETOPICPATH{%LAYOUTTOPIC%}%?skin=text&contenttype=text/css");
        /* Custom overriding style */
        @import url("%RELATIVETOPICPATH{%STYLETOPIC%}%?skin=text&contenttype=text/css");

        /* Default TWiki layout */
        @import url("%TWIKILAYOUTURL%");
        /* Default TWiki style */
        @import url("%TWIKISTYLEURL%");
        /* Custom overriding layout */
        @import url("%USERLAYOUTURL%");
        /* Custom overriding style */
        @import url("%USERSTYLEURL%");

• • Set TWIKILAYOUTURL = ../Codev/%TWIKILAYOUTTOPIC%?skin=text&contenttype=text/css

commited to SVN - can someone please add this to the docco above (or i'll do it later when i wake up) (TourTime)

-- SvenDowideit - 25 Jul 2004

I have split up TWiki styles and user defined styles in twiki.pattern.tmpl. TWiki styles are included in %TMPL:DEF{"twikistyle"}%; user styles in %TMPL:DEF{"userstyle"}%. Because not all templates should be overridden by user styles, for instance Edit and Attach.

So you get:

In %TMPL:DEF{"twikistyle"}%:

        /* Default TWiki layout */
        @import url("%TWIKILAYOUTURL%");
        /* Default TWiki style */
        @import url("%TWIKISTYLEURL%");

        /* Custom overriding layout per web or per topic */
        @import url("%USERLAYOUTURL%");
        /* Custom overriding style per web or per topic */
        @import url("%USERSTYLEURL%");

-- ArthurClemens - 25 Jul 2004

There is a possible "gotcha" with relative URLs: You can access the same topic with the following URL pathes: /cgi-bin/view?topic=Web/SomeTopic or /cgi-bin/view/Web?topic=SomeTopic or /cgi-bin/view/Web/SomeTopic. For each URL path, relative URLs will be anchored differently. The base tag should take care of this, but not all browsers might support that.

Also, there are drawbacks when storing CSS in topics:

• Speed. TWiki tells browsers not to cache TWiki topics
• Access Statistics get skewed because several topics get accessed to view a page. Besides lying about activity, it impacts tools that depend on the access statistics like BlackListPlugin

A simple solution is to store CSS as attachments to Skin topics. This avoids above drawbacks at the cost of a relatively small usability drop (download, modify, upload cycle vs. edit & save)

Also, can we remove the style sheet imports from templates/twiki.tmpl since the default template does not depend on style sheets? See /* NOTE: THESE LINES WILL BE REMOVED FROM THE CURRENT TEMPLATE WITH CAIRO RELEASE */

• Done in svn. AC

-- PeterThoeny - 25 Jul 2004

Noooooooo Don't remove the style sheets from twiki.tmpl All the CssClassNames in that topic are in every and all skins including the default. TWiki with the default skin is CSS enabled so long as you leave those lines in.

Also, Arthur - can you please explain why "not all templates should be overridden by user styles, for instance Edit and Attach."

as by doing this, you get inconsistent look and feels (i set fonts and colours etc in my user stlye topic, and i like to hide parts of page that i don't use in UserLayout) - If you don't use the same stylesheets, you get the deafult aqua table heading on edit, while I use a nice grey for view - and this setting is a customisation on the base pattern skin, so i have it in the UserStyleUrl (it also breaks the way I have customised the pattern skin at work, as I have left your work as the styletopic, and put my customisations into the usertopics)

-- SvenDowideit - 25 Jul 2004

These settings were in preparation of Pattern skin. I did not realize they were actually used. Also the use of user topic styles is different then I envisaged.

But OK, I am happy to revert the changes. You can do them if you are in a hurry.

• The templates twiki.tmpl and view.tmpl are messy. I think its better to revert them back to their betarelease state, and then put the css call in. -- ArthurClemens - 26 Jul 2004

-- ArthurClemens - 26 Jul 2004

Peter,

to address the drawbacks of topics for stylesheets, but to enabled them at the same time, the settings in my TWikiPreferences are:

      * Set TWIKILAYOUTURL = %PUBURL%/skins/pattern/layout.css
      * Set TWIKISTYLEURL = %PUBURL%/skins/pattern/style.css

-- ArthurClemens - 26 Jul 2004

Great, solves the performance issue and access log issue

Why not this setup:

      * Set TWIKILAYOUTURL = %PUBURL%/%TWIKIWEB%/PatternSkin/layout.css
      * Set TWIKISTYLEURL = %PUBURL%/%TWIKIWEB%/PatternSkin/style.css

This avoid clutter in the TWiki file tree and keeps related content neatly together.

-- PeterThoeny - 27 Jul 2004

Fine with me.

-- ArthurClemens - 27 Jul 2004

Done for pattern skin. Documentation will follow.

-- ArthurClemens - 31 Jul 2004

Is the "CSS as topic page" feature still needed? Can it be dropped? Deferred to after Cairo? If not urgent it should be deferred.

-- PeterThoeny - 08 Aug 2004

The feature is still needed. But I don't have time to finish the doc now. And RelativeTopicPathAlwaysAddsWeb should be solved too. I think its more realistic to move this to Dakar and leave this undocumented for the time being.

-- ArthurClemens - 08 Aug 2004

Then lets defer it since it is not critical.

On documenting the CSS in the TWiki web, the new pages need to be incorporated into the TWiki Reference Manual, TWikiDocumentation. All offical topics should have the comment include on top and bottom.

-- PeterThoeny - 08 Aug 2004

It might be worth looking at the way MediaWiki imports/links to css and javascript. They use some strange /* code around thier imports and seem to have a way of loading a css just for IE. It's also interesting to note that they use url parameters to serve pages as css.

Here's the code from the header of one of their pages:

    <style type="text/css" media="screen,projection">/*<![CDATA[*/ @import "/style/monobook/main.css"; /*]]>*/</style>

    <link rel="stylesheet" type="text/css" media="print" href="/style/commonPrint.css"/>
    <!--[if IE]><style type="text/css" media="all">@import "/style/monobook/IEFixes.css";</style>
    <script type="text/javascript" src="/style/IEFixes.js"></script>
    <meta http-equiv="imagetoolbar" content="no" /><![endif]-->
    <script src="/w/wiki.phtml?title=-&amp;action=raw&amp;gen=js" type="text/javascript"></script>
    <script type="text/javascript" src="/style/wikibits.js"></script>
    <style type="text/css">/*<![CDATA[*/ @import "/w/wiki.phtml?title=-&action=raw&gen=css";
 /*]]>*/</style>

<style type="text/css" media="all">
   /* Default TWiki layout */
   @ import url("%TWIKILAYOUTURL%");
   /* Default TWiki style */
   @ import url("%TWIKISTYLEURL%");
   /* Custom overriding layout per web or per topic */
   @ import url("%USERLAYOUTURL%");
   /* Custom overriding style per web or per topic */
   @ import url("%USERSTYLEURL%");
</style>

<script type="text/javascript">
<!-- 
document.write("<style type='text/css'>");
/* Default TWiki layout */
if ("%TWIKILAYOUTURL%".split("?")[0].length) {
   document.write("@import url(%TWIKILAYOUTURL%);"); 
}
/* Default TWiki style */
if ("%TWIKISTYLEURL%".split("?")[0].length) {
   document.write("@import url(%TWIKISTYLEURL%);"); 
}
/* Custom overriding layout per web or per topic */
if ("%USERLAYOUTURL%".split("?")[0].length) {
   document.write("@import url(%USERLAYOUTURL%);"); 
}
/* Custom overriding style per web or per topic */
if ("%USERSTYLEURL%".split("?")[0].length) {
   document.write("@import url(%USERSTYLEURL%);");
}
document.write("<\/style>"); 
//-->
</script>
<style type="text/css" media="all">
   /* Styles that are set using variables */
   .twikiToc li {
      list-style-image:url(%PUBURL%/%TWIKIWEB%/PatternSkin/i_arrow_down.gif);
   }           
   .twikiWebIndicator {
      background-color:%WEBBGCOLOR%;
   }
</style>

<!-- fallback in case javascript is off -->
<script type="text/javascript">
<!-- 
document.write("<!--");
//-->
</script>
<style type='text/css'>
   @import url("%TWIKILAYOUTURL%");
   @import url("%TWIKISTYLEURL%");
</style>
<script type="text/javascript">
<!-- 
document.write("-->");
//-->
</script>