How about using the preferences (TWikiPreferences, WebPreferences and user preferences) as style sheets? Something like for TABLE parameters:
Seems to me the effective way to implement this is to have a handler for the prefrence pages that extracts from and creates a .css file based on the styles on the preference page. The file(s) could then be included via template. Worth noting that one .css file can include another .css file in a couple of different ways, and depending on how the other file(s) are included, the overrides of the included file either do override the base or are ignored. This means the if you have a site.css which includes a web.css which includes a user.css you automagically get personalization from the site down to the user level. It might also be worth considering an ability to finalize different styles. I might have a color theme for a web I want repeated on all topic pages, or a background texture. I wouldn't want an adventerous user changing those and so i'd like them to be finalizable at the web level... This seems like a tough problem, since (for example), background is an attribute of the <body> tag, and not a tag in it's own rigth (AFAIK). Conversely, It might be nice to have a distinct style for a webhome page and a differing style for topic pages. Another notion is to have a %stylesheet(style.css)% macro which would expand into a
Re the NB: It appears OK to me -- it appears as 'href="style.css"' both in the source and in the "rendered" page. Am I missing something, or does your browser do something different than mine? (In this case mine is Netscape 3.01 -- I will try IE 5 and Konqueror 2.1 and add additional notes if I find a difference. Nope, the same in all three cases (but it is interesting to see the differences in formatting between the three browsers.) Oops, I lied -- now I see a difference when I do the preview -- it displays something like: 'href="/cgi-bin/oops/Codev/PreferencesAsStyleSheets?template=oops"'. I'm now going to preview and then save this page to see what it looks like when saved (rather than previewed). OK, I'm back. It seems that the strange text appears only during the preview and appears "correctly" when saved. Someone else may be able to explain why this happens. It would be nice to see it fixed -- we could learn to live with this behavior but it is confusing. -- RandyKramer - 26 Mar 2001
Yes, that was what I saw too - glad i'm a) not hallucinating, and b) you traced down to just the preview! -- DavidLeBlanc - 27 Mar 2001
If I understand correctly, only those preferences relating to page design should go into the style sheet. Now, if we go for stylesheets, why convert back and forth from css to twiki preferences? Why not leave everything in a stylesheet? One per twiki eg
It might also be worth considering an ability to finalize different styles.
brings up another issue: it is a deliberate feature of css, not to finalize a style. A user/browser is supposed to be able to always override the designer's settings. If you mix sth like
We could go the style sheet way, though we need to check carefully if this is OK. Questions:
-- PeterThoeny - 27 Mar 2001
I think both preference page styling and discrete separate stylesheets should be accomodated, which is the design i'm working towards. The advantages of keeping content separate from presentation are hard to beat. Peter, i'm wondering why you used a table in your example? (This is using my proposed preference page syntax.):
If you use stylesheets, you want this to be the place to control colors, fonts etc. If scripts render style directly, you have a hard time to get a consistent look. For example, I'm using a stylesheet on my site. Looks mostly good. But things like attachments stick out with ugly colors (in the context of the style). To fix this, I have to change the ... template. Hmm. Actually, that's good enough. Still - does TWiki really base all rendering on templates? Probably not - see BadHTML! Regarding user preferences, macro expansion etc. What are the goals of all this? I try to summarize:
Goals:
Goal 1 is what I am after. A combination of stylesheets and template files should suffice. After all, you do it only once after installation... So WebBasedTemplateMaintenance seems overkill to me. Goal 2 might be of interest to some. 1 simple style file per web should be all we need. This could override whatever feature. (BTW, I prefer HierarchicalNavigation to show the context.) Goal 3 + 4 -- wo would want that anyway? I guess:
Another story is, how CSS capable browsers render your page. It needs an awful lot of work-arounds to get sth reasonably looking. Goal 6 would be nice side-effect. In theory CSS should eat some performance. In my experience the time for wire transmission plus parsing extra markup outweigh this. And it's on the client side. -- PeterKlausner - 03 Apr 2001
My notion is that there would be default stylesheets shipped with TWiki: TWiki.css would be the site level stylesheet, and WebDefault would be the file copied to a new web and renamed as webname.css. As it turns out, for those browsers so equipped, a browser-local stylesheet is possible (IE 5 for one supports this although poorly documented). I would not really want to get into user level stylesheets supported in TWIKI for many of the reasons Peter pointed out. A point about using things like table and span to create (for example), styled "headings". They are considered a bad thing and that is in fact why styling is being deprecated out of html/xhtml completely. The problem is that it obscures the semantics of the element! As a taste of what style sheets can bring to TWiki, i've now attached a very primative first hack for inspection/comments. These are derived from the 20001201 release of TWiki and I don't know how/if they'll work on the 20010301 beta release. Please replace the obvious files, and add the webname.css files to your twiki/data/webname directories. -- DavidLeBlanc - 03 Apr 2001
DeleteMe -- SamHasler - 15 Feb 2005
* Set TABLE_STYLE = cellpadding="1" border="1" cellspacing="0" * TH_STYLE = align="center" bgcolor="#d3d3d3"or this would control the whole TABLE tag:
* Set TABLE_STYLE = <table cellpadding="1" border="1" cellspacing="0">|</table> * Set TH_STYLE = <th align="center" bgcolor="#d3d3d3">|</th>This would control the style of tables. It could be extended for other other styles as well, i.e. headers, horizontal rules e.t.c. -- PeterThoeny - 23 Mar 2001
Seems to me the effective way to implement this is to have a handler for the prefrence pages that extracts from and creates a .css file based on the styles on the preference page. The file(s) could then be included via template. Worth noting that one .css file can include another .css file in a couple of different ways, and depending on how the other file(s) are included, the overrides of the included file either do override the base or are ignored. This means the if you have a site.css which includes a web.css which includes a user.css you automagically get personalization from the site down to the user level. It might also be worth considering an ability to finalize different styles. I might have a color theme for a web I want repeated on all topic pages, or a background texture. I wouldn't want an adventerous user changing those and so i'd like them to be finalizable at the web level... This seems like a tough problem, since (for example), background is an attribute of the <body> tag, and not a tag in it's own rigth (AFAIK). Conversely, It might be nice to have a distinct style for a webhome page and a differing style for topic pages. Another notion is to have a %stylesheet(style.css)% macro which would expand into a
<link rel="stylesheet" type="text/css" href="style.css">NB: View the source of this - it demonstrates that TWiki seems to be doing href substitutions even within <verbatim> tags. the above href in the <link> is supposed to be "style.css", not what Twiki turned it into. as part of the <head> element. This could be included at the top of any page - and the .css could be an attachment! This seems quite wikiwayish to me! Perhaps both would be good! An ability to create "looks" at the site, web and user level, and also the ability to customize any page (potentially with override conrol of the web/site stylesheets). -- DavidLeBlanc - 25 Mar 2001
Re the NB: It appears OK to me -- it appears as 'href="style.css"' both in the source and in the "rendered" page. Am I missing something, or does your browser do something different than mine? (In this case mine is Netscape 3.01 -- I will try IE 5 and Konqueror 2.1 and add additional notes if I find a difference. Nope, the same in all three cases (but it is interesting to see the differences in formatting between the three browsers.) Oops, I lied -- now I see a difference when I do the preview -- it displays something like: 'href="/cgi-bin/oops/Codev/PreferencesAsStyleSheets?template=oops"'. I'm now going to preview and then save this page to see what it looks like when saved (rather than previewed). OK, I'm back. It seems that the strange text appears only during the preview and appears "correctly" when saved. Someone else may be able to explain why this happens. It would be nice to see it fixed -- we could learn to live with this behavior but it is confusing. -- RandyKramer - 26 Mar 2001
Yes, that was what I saw too - glad i'm a) not hallucinating, and b) you traced down to just the preview! -- DavidLeBlanc - 27 Mar 2001
If I understand correctly, only those preferences relating to page design should go into the style sheet. Now, if we go for stylesheets, why convert back and forth from css to twiki preferences? Why not leave everything in a stylesheet? One per twiki eg
/pub/Main/web.css,
one per web eg /pub/Codev/web.css,.
one per user, maybe /pub/Main/TwikiGuest/user.css as attachment?
Ok, one benefit I can imagine:
some might find wiki preferences easier to use than css.
But with proper templates
-- ie, the beloved colors and fonts ready for change --
this should be no big deal.
Anyway, not too many people tinker with their individual settings,
or am I wrong?
Those who really do, probably love the added features of css.
The benefits of using css are more on the implementation/maintenance side. - You get rid of many ugly
<font bla blastatements altogether or replace them with a few self descriptive class attributes. - It's much easier to create a coherent look and feel.
It might also be worth considering an ability to finalize different styles.
brings up another issue: it is a deliberate feature of css, not to finalize a style. A user/browser is supposed to be able to always override the designer's settings. If you mix sth like
<font color... plus background color style,
you may well end up with black characters on black background...
This implies, that all rendering should be controlled by a stylesheet.
And that's what you want for maintainability.
Downside of all this: before you can seriously switch to css,
you have to clean up all the rendering code.
-- PeterKlausner - 27 Mar 2001 We could go the style sheet way, though we need to check carefully if this is OK. Questions:
- Relying on style sheets means raising the RequiredEnvironmentForTWiki. Do all common browsers, including special ones like text browsers, support style sheets?
- Do we need a separate style sheet editor, or is it better to define styles in the TWiki preferences?
* Set H1_STYLE = <table border="5" cellspacing="1" width="100%">
<tr bgcolor="#d3d3d3"><td align="center">
<font size="+3"> <b> | </b> </font> </td></tr></table>
So that a H1 heading gets translated and rendered like this:
| Testing H1 Header |
I think both preference page styling and discrete separate stylesheets should be accomodated, which is the design i'm working towards. The advantages of keeping content separate from presentation are hard to beat. Peter, i'm wondering why you used a table in your example? (This is using my proposed preference page syntax.):
Style h1
{ align: center;
color: red;
width: 100%;
background: #d3d3d3;
border-style: groove;
}
A Styled Header
Of course, just like Perl, CSS has a million different ways to do the same thing (PeterThoeny's form of declaring a "style"):set H1_STYLE = <span style="width: 100%; position: center; border-style: groove; font-size: 200%; font-weight: bold; color: red; background: #d3d3d3;"> | </span>A Styled Span Heh. position is a CSS-2 style not honored by (at least) IE5.5 at this time. It is simply ignored. Also, <span> is supposedly best used as an inline styling element. I see that you're considering the possibilities of a preference being more a macro that replaces a tag then as actual CSS style declarations. Is that getting too complex? My notion is that a stylesheet would style the existing tags used in a TWiki page (such as <p> etc.), rather then add styling for user added tags. If something like that (styling user tags) is desireable, then one could use any name for a tag and it gets "translated" into an HTML tag and style (shades of XML). This brings up the interesting idea of being able to make things like <verbatim> user defined styles if the appropriate psuedo-style requiring wysiwyg presentation of an enclosed text is available. My personal opinion is that styles ought to be CSS style declarations and not macros. It's more complex (for the user), and fogs the idea of what a style is. By using style declarations, then a user can refer to any stylesheet reference for info. WRT finalization: I think this is appropriate to do: CSS does support a notion of some styles overriding other styles and not others. I think that nested levels of control of styling is consistant with how preferences are done on TWiki now. I don't think a 100% support of styles would really be workable. Also, I don't think that styles on personal preference pages are easily doable - since stylesheets are downloaded from the server, one would have to support something like <username><webname>.css which could end up being a lot of individual files stored on a server. PeterKlausner: Why do you have to clean up all the rendering code? Does it insert styles now? -- DavidLeBlanc - 30 Mar 2001
If you use stylesheets, you want this to be the place to control colors, fonts etc. If scripts render style directly, you have a hard time to get a consistent look. For example, I'm using a stylesheet on my site. Looks mostly good. But things like attachments stick out with ugly colors (in the context of the style). To fix this, I have to change the ... template. Hmm. Actually, that's good enough. Still - does TWiki really base all rendering on templates? Probably not - see BadHTML! Regarding user preferences, macro expansion etc. What are the goals of all this? I try to summarize:
Goals:
- Easy site maintenance, i.e. adapting local look and feel
- Easy cascading of style for sub-webs
- Capability for users to personalize their style
- Easy personalization of style
- Improve page portability and accessability
- Improve performance and reduce page size
Goal 1 is what I am after. A combination of stylesheets and template files should suffice. After all, you do it only once after installation... So WebBasedTemplateMaintenance seems overkill to me. Goal 2 might be of interest to some. 1 simple style file per web should be all we need. This could override whatever feature. (BTW, I prefer HierarchicalNavigation to show the context.) Goal 3 + 4 -- wo would want that anyway? I guess:
- techies who just can't resist to tweak what can be tweaked (like myself
- handicapped who need to improve readability -> see goal 5
- Keep an implementation as leight weight as possible - both in code complexity and performance impact.
- To make use of CSS, you have to understand it anyway. If you don't, an additional layer of TWiki syntax won't buy you anything in terms of ease of use. I'd even consider it a usability feature to keep sth as complex a CSS out of Joe Average's sight.
- Good point: you don't want (n users x m webs) style files. Unfortunately, missing style files are handled "ungracefully".
How about TWiki macros, which expand to <link rel=...> only if the corresponding file really exists. This way, only a few interested would actually create their stylesheets. And you could finalize your style by leaving %USER..% out of the template.
These 4 macros plus new templates plus less BadHTML would be all we really need.%SITESTYLE% /pub/twiki.css %WEBSTYLE% /pub/web.css %USERSTYLE% /pub/Main/user/twiki.css %USERWEBSTYLE% /pub/Main/user/web.css
Another story is, how CSS capable browsers render your page. It needs an awful lot of work-arounds to get sth reasonably looking. Goal 6 would be nice side-effect. In theory CSS should eat some performance. In my experience the time for wire transmission plus parsing extra markup outweigh this. And it's on the client side. -- PeterKlausner - 03 Apr 2001
My notion is that there would be default stylesheets shipped with TWiki: TWiki.css would be the site level stylesheet, and WebDefault would be the file copied to a new web and renamed as webname.css. As it turns out, for those browsers so equipped, a browser-local stylesheet is possible (IE 5 for one supports this although poorly documented). I would not really want to get into user level stylesheets supported in TWIKI for many of the reasons Peter pointed out. A point about using things like table and span to create (for example), styled "headings". They are considered a bad thing and that is in fact why styling is being deprecated out of html/xhtml completely. The problem is that it obscures the semantics of the element! As a taste of what style sheets can bring to TWiki, i've now attached a very primative first hack for inspection/comments. These are derived from the 20001201 release of TWiki and I don't know how/if they'll work on the 20010301 beta release. Please replace the obvious files, and add the webname.css files to your twiki/data/webname directories. -- DavidLeBlanc - 03 Apr 2001
DeleteMe -- SamHasler - 15 Feb 2005
| BasicForm | |
|---|---|
| TopicClassification | Select one... |
| TopicSummary | |
| InterestedParties | |
| RelatedTopics | |
| I | Attachment | History | Action | Size | Date | Who | Comment |
|---|---|---|---|---|---|---|---|
 tmpl |
edit.tmpl | manage | 2.8 K | 2001-04-04 - 04:14 | UnknownUser | TWiki/templates/edit.tmpl | |
| tmpl |
view.tmpl | manage | 1.5 K | 2001-04-04 - 04:13 | UnknownUser | new view template for TWiki/templates |
Site map
Blog web
Create New Topic
Index
Search
Advanced search
My topics of interest
Changes
Major changes only
All tags
Notifications
RSS Feed
Statistics
Preferences
Community 
Readme first
Developers News
How you can help
Community roles
#twiki IRC
Lima Release
Feature Proposals
Bugs Changes
Categories 
Account 
Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.