Why Use CSS

Although templates make this easy as a matter of individual choice, the overall TWiki drive to slicker packaging with more sophisticated menus, etc, PLUS the existing bundled topic content that, if used (like, TWiki documentation), already contains a lot of mixed mark-up - font tags, etc), make for a messy foundation from which a new bunch of templates are likely to be created.

If going for clean XHTML -> XML future is the goal, seems like starting new template design from TWiki Web standards (CSS-related) guidelines makes sense right now.

There is bit of a learning curve to using CSS "properly" - I'm just starting to convert some pages out of interest (not as a coder), and it's not difficult, but not a snap either. From reading designer/Web dev site articles, there seems to be a commitment involved that makes slapping in a quick table, for example, a lot easier as a fast fix than, say, using CSS controls...

It's quite easy to create a local style sheet to render the contents a bit neater. But it would be very nice to have this feature in the default distribution, especially because if you don't use them very often, it's a some work to assemble a consistent set of styles.

I would appreciate it, if such settings like web colors would be replaced or synchronized with such a style sheet, and in the case of webcolors to have the possibility to use color pairs, for not to be restricted to the light pastell colors.

I did all but the color pairs for webcolors (I'm not yet working on a design) and it has been a trivial task. It would nevertheless be good to have CSS support in core TWiki, since doing it my way means editing a lot of template files (everywhere, where there are BODY tags). As it is now, I'ld have to redo this each time I update the system.

TWiki should recognize that any particular installation will have a wide range of usability, navigation and external integration requirements; readily supporting the easy configuration of a site to meet these needs can only increase TWiki's potential userbase.

TWiki needs a couple of more polished templates, layouts using basic HTML presentation elements like font face and relative sizes, text and background colors, block level formatting, apart from extensive JS, DHTML, whatever. Just usable graphic design that degrades back to the '90s, OR clearly requires 4.x or 5.x browsers and equivs, depending on the site.

I second that feature request. A Dec 2001 default install looks quite bland (some may say ugly by todays standards). While this may appeal to techies, other CMS are far ahead in terms of out-of-the-box design and skinnability.

Oh, and who is the ugly guy in the title bar and what does he do on my web site?

I have been learning CSS in my "free" time for some months now and it is my firm belief that done right it will solve many of the skinning and personalization difficulties people have with out of the box TWiki. A well designed stylesheet setup can serve good looking pages to 'most any browser type, including speech and text-only browsers. It does take some time to learn how to work around the idiosyncracies of different browsers, but nowhere near the time required to do the same in html.

Once the foundation is laid, changing the site logo, altering colours and fonts, moving the menus to the left, right, top, or bottom of the browser frame is a matter editing one or two files. The cascading nature means that mutliple stylesheets can be nested (with care). For example, site.css describes the site logo and basic layout; web_one.css refines the layout, perhaps reordering some menus, and sets the colour theme (similar to the way background colours are used to distuinguish webs now); while user.css sets the font family and size on a per user basis.

In the future skins might be used primarily for changing how a TWiki deployment acts and functions while look and feel is controlled by CSS. For exampe a site administrator could use the KoalaSkin nested web structure with the TigerSkin stylesheets. Admittedly with the state of things right now this is blue-sky thinking, but it is certainly achievable.

I agree about using CSS for look and feel - now that IE5+, Opera 5+, MozillaBrowser and Netscape 6+ are widespread, it seems only sensible that TWiki targets modern browsers as an option. It's fine to ship the default templates, but IMO they should be renamed to 'TWiki Classic' and a simpler CSS-based look-and-feel used out of the box. TWiki's default look is rather staid, which puts people off - look at any PhpWiki, or virtually any WebLog, for a more modern look. PikiePikie is one Wiki that lets you choose CSS styles at run-time, just selecting from a drop-down box.

See the Web Standards Project for more arguments on targetting modern browsers.

<pro css rant>

One thing I've found when working with CSS is that it alerts me to things I'm doing that may indicate my design is overly elaborate. For example, if I'm using nested tables (which I've stopped doing since using CSS), how will the data look in a browser like lynx or w3m? I use these as my accessibility meters, if the overall flow and design of the page isn't lost (as it partially is in a text browser that doesn't understand tables, like lynx, or css like lynx and w3m), then the design is sound. Using an editor that indents html, I've been able to remove an average of three or four levels of indentation by making efficient use of smaller tables/divs, without affecting the appearance on NS4+ browsers. IMO, this is a big win, since it makes code easier to read, and likely quicker to parse for massive pages.

As for NS4, I've come to the belief that it has been around forever, and is a major pain in the butt to worry about. That doesn't mean I don't worry about it, I obsess over it, making sure most of my intended design is preserved in NS4, but is nearly identical, at least in all IE and Mozilla/NS browsers since NS4. NS4 does support the majority of CSS1, but there are a few things you have to make the choice of not using at all, because they completely break functionality in NS4, or explain why the page doesn't look as pretty as it could to the users. Of course, this only works where an organization has begun to transition to a "modern" browser, if it hasn't yet, you (ideally) would set a flag telling the TWiki core to automagically figure out it should add font and other tags where div/span tags are normally printed, in addition to the CSS code.

As proof of this, in my version of the GnuSkin (http://csci.mrs.umn.edu/dungeon), I was able to remove the (I think) three-level deep nesting of tables, and just making good use of </table> tags to break things up. In other places, div floats worked. The nice thing about div tags is that they allow a little flexibility in where you actually put them, which doesn't affect the GUI browser's experience, but might mean the difference between your "announcements" box showing up before or after the rest of the front page's content in a text, or miniature browser...as an example.

</pro css rant>

I think the original point [of this topic] is very valid: come up with more powerful, yet readable mark-up, i.e. HTML should not be needed for regular content writing.

On the WAP/WML issue, CSS is actually better for them!!! They do not browse the web, but use proxies that convert HTML pages to their format. CSS being more structured convey the intent of the designer of the page, so the converter can do a better job, otherwise it would be lost with tricks such as tables and one-pixel gifs...

We had a student working on a Web browser for blind people at the W3C, and believe me, in this case you WANT CSS, and this is the same for acessing web sites via voice gateways (which may be more confortable than WAP on non-highend phones)

Why NOT Use CSS

Do not TWiki's minimum client levels mean anything any more ?

_Of course testing will be important. I read this in your text, and I think you can agree that you can use CSS as long as it doesn't break anything ._

[...] but hey, what do base level requirements matter. (Or rather sticking to them - it's not like they're a constitution - they can be changed - but the point is they should be changed first, in conjunction with the community. Anyone who thinks I'm anti-CSS is completely and utterly missing the point, this is about not having a few individuals dictate to a community, but rather it's about working together. )

It is good that you remind us of the basic requirements and bring it up as an argument. They should be discussed. But you cannot just change a requirement beforehand. You have to be able to pass and discuss arguments for and against CSS before knowing it is a bad idea or maybe just possible. This discussion is being held now, and in public. I agree we need some guidelines how twiki should work on what platforms. And we need test examples - we need some more time for this.