Sven said: We need to doco all the CSS tags that we are putting into TWiki

It would also be beneficial to build a canonical list of class and ID names which could be used by all css-using skins.

#name = ID can only be used once in any page
.name = class can be used any number of times

Classes and IDs Currently In Use

Appendix B: TWiki CSS

Listing of CSS class names emitted from TWiki core code and standard plugins, for the 01-Aug-2004 TWiki production release.

Who should read this document?

More or less all html elements generated by TWiki core code now have Cascading Style Sheet (CSS) tags. Skin builders and others who want to change the appearance of the default TWiki installation or any of the skins can use this document to see what styles can be created for these html elements.

Naming conventions

1. All TWiki class names have the prefix twiki. So: twikiEditPage, twikiTopicAction, etcetera. Remember that CSS class names are case sensitive - TWiki CSS uses lowercase tw.
2. TWiki uses class names only (.twikiViewPage) and no id names (#twikiViewPage), to allow multiple class names. Class names are written using the dot prefix.
3. If you define your own CSS classes, it is preferable that you do not use the twiki prefix to prevent undesired overriding effects.

CSS classes

Classes from core code

.twikiNew Changes.pm .twikiChangeFormButtonHolder Edit.pm .twikiChangeFormButton Form.pm .twikiForm Form.pm .twikiEditFormTextField Form.pm .twikiEditFormLabelField Form.pm .twikiEditFormTextAreaField Form.pm .twikiEditFormCheckboxButton Form.pm .twikiEditFormCheckboxButton Form.pm .twikiEditFormCheckboxField Form.pm .twikiEditFormRadioField Form.pm .twikiEditFormError Form.pm .twikiRadioButton Form.pm .twikiCheckbox Form.pm .twikiEditFormError Form.pm .twikiDiffTable RDiff.pm .twikiDiffDeletedHeader RDiff.pm .twikiDiffDeletedMarker RDiff.pm .twikiDiffDeletedText RDiff.pm .twikiDiffAddedHeader RDiff.pm .twikiDiffAddedMarker RDiff.pm .twikiDiffAddedText RDiff.pm .twikiDiffChangedHeader RDiff.pm .twikiDiffChangedText RDiff.pm .twikiDiffUnchangedText RDiff.pm .twikiDiffLineNumberHeader RDiff.pm .twikiForm Render.pm .twikiAnchorLink Render.pm .twikiLink Render.pm .twikiNewLink Render.pm .twikiNew Search.pm .twikiAlert Search.pm .twikiAlert Statistics.pm .twikiAlert TWiki.pm .twikiToc TWiki.pm .twikiTocTitle TWiki.pm .twikiEmulatedLink Preview.pm

Classes from Plugins

TablePlugin

.twikiSortedAscendingCol TablePlugin.pm .twikiSortedDescendingCol TablePlugin.pm .twikiFirstCol TablePlugin.pm

Classes used on twiki pages

.twikiPageForm

Going further

PatternSkin makes fully use of CSS in its templates. Read the PatternSkin topic and PatternSkinCss to learn more about adjusting PatternSkin, or creating your own CSS-based skin.

See also: DragonSkin .

Practical introduction to CSS: http://www.w3.org/Style/LieBos2e/enter/

-- TWiki:Main.ArthurClemens - 08 Aug 2004

PatternSkin

See: PatternSkinCss

SeeSkin

Generic Containers, which would likely be used by any CSS-based skin for twiki. The names aren't important, it's what they contain that counts.

• #topsection wrapper for everything in the top (masthead, logo, tagline, etc.)
  • #title topic name (%TOPIC%)
  • #search search form (aka GoBox)

• #content %TEXT% and #meta
  • #meta metadata (%META{"form"}%, %META{"attachments"}%, %META{"moved"}%)
• #editcont %TEXT% when in edit mode

• #navigate %WEBTOPICLIST% and %WIKIWEBLIST%
• #lineage current topic revision and parents/children (%REVINFO%, %META{"parent"}%)

• #menu wrapper for page topic actions:
  • #topicaction edit, attach, print, etc...
    • #diffs container for individual version diffs (1.3 < 1.2, etc.)
  • #editmore link to advanced topic actions (rename, re-parent, etc.)

• .nocss container for elements which are only for non-css browsers (contents usually hidden to css-aware ones). Use this for things like skip-navigation links for screen readers.

SeeSkin specific addons

• #bugreport links to new topic form in Feedback web
• #logochar logo character
• #extraDiv1,#extraDiv2,...#extraDiv6 catch-alls to add extra imagery (cf. CssZenGarden )

• .deem de-emphasize (make text lighter and smaller).

Discussion

---

conversational bit below adapted from TWikiIRC date=2004-05-17,Mon&sel=295#l291 ( Main.MattWilkie ,Main.SvenDowideit, Main.WillNorris ,Main.MartinCleaver )

argh. do we have to have 'TWiki' prefix everything?

Yes, as they are for TWiki specific stuff. Otherwise it clashes with non TWiki content.

but everything is twiki specific.. isn't it?

no

what non-twiki content?

headings are non twiki, they are html.

if you want to use a twiki prefix, they should be in a namespace putting twiki in front of every id/class sucks

http://annevankesteren.nl/archives/2004/03/css-namespaces

that is an altrenative that maphew mentioned before i'm happy to use that instaed - but i'm not doing the work :()

sure, neither am i {grin}

the alternative I mentioned is to use child (descendant) selctors:

'#content h1 {font-weight:bolder}' is only applied to H1 elements contained within the 'content' container. Or in this case '#twiki .DiffAddedMarker {blah blah}'

that's a very nice solution, lightweight, in every respect

it's called Environmental Style. It has the added benefit of that when you move .DiffAddedMarker so it's inside an #owiki container, for example, you can apply completely different css without changing the content http://realworldstyle.com/environmental_style.html

---

To put TWiki in front of every CSS tag generated by lib code or used in templates makes the distinction clear between stuff you override and tags a skin maker has added. If users are able to change CSS in topics (users that are not aware of lib files, tmpl files and so on) it is easy for them to make 'mistakes' by overriding or redefining css tags that are used by TWiki.

For instance the user decides to create a definition for .topic: .topic { float:left; } and this will mess up the whole layout because this overrides the TWiki-defined style .topic. It seems safer to use TWikiTopic, and let the user mess around with .topic.

I like Environmental style, but would like to use it for the templates: #view .TWikiTopic, #preview .TWikiTopic, etcetera.

-- ArthurClemens - 17 May 2004

I don't think user overriding would be much of a problem if there were an easily accessible list of the existing names. In any case, I'm not interested in arguing further about it. I've made my case, others will either agree or not. It's a minor point relative to just getting twiki in shape to use css at all.

added names used by SeeSkin
added names used by PatternSkin (may not be current)

-- MattWilkie - 20,31 May 2004

I just learned a useful piece of knowledge: you can assign multiple classnames to page elements. For instance:

<a class='class2 class1' href='/'>link</a>

or more relevant to the discussion:

<body class="view TWiki">

If I think about it, of course I knew something like a.green, but never realized you could extend this.

This is in the HTML specification, so nothing new: http://www.w3.org/TR/html401/struct/global.html#h-7.5.2.
This makes it possible to create multiple inheritance: to save on filesize by combining styles, and to override styles locally.

Some rules: 0. User overrides author overrides default
1. important overrides non-!important
2. Inline overrides included (embedded and link)
3. Higher specificity overrides lower specificity
4. Later in the rule order overrides earlier

Mac IE has a fundamental problem with interpreting multiple classes: http://dhtmlkitchen.com/learn/css/multiclass/index2.jsp. Other browsers seem to take it.

Multiple class names do not work with ids, only with classes. This would mean that layout elements are also made classes, so #TWikiMain becomes .TWikiMain. Not a big deal, and makes it more flexible.

I have added a test file to play. Try in the body the combinations "view TWiki", "view OWiki", "preview TWiki" and "preview OWiki".

-- ArthurClemens - 04 Jun 2004

nice discovery Arthur! I read about this ages ago but had completely forgotten about it.

-- MattWilkie - 06 Jun 2004

adding TWikiFormsEdit * classnames to let me customise their look

-- SvenDowideit - 18 Jun 2004

Sven, as you have worked for Pattern skin: do you see problems if we change the ID names to class names, to enable multiple classes?

-- ArthurClemens - 19 Jul 2004

BTW, below contributor list is on the wrong place, better to refactor the top and move contributor list up.

-- PeterThoeny - 25 Jul 2004

I'd like to put in a strong vote for putting the css files into SVN, in addition to MartinCleaver 's plea for having the default topics that make up a release to be in SVN. right now i'm having trouble tracking what changes to completely break my pattern skin usage at work (at least its happneing in my testwiki)

-- SvenDowideit - 26 Jul 2004

May be I am missing something, but putting topics into SVN has these issues:

• Not as easy to maintain as TWiki topics
• No visual feedback that rendering and linking is correct
• No RCS controlled topics in release; no topic history indicating the TWiki time line

A better approach is to go back to the monthly Beta release schedule and to automate the merging of Alpha releases with Beta releases.

(This is off-topic and should be refactored)

-- PeterThoeny - 27 Jul 2004

---

Small part refactored:

When using multiple classnames in templates, the classnames should not be in WikiWord syntax or they will get parsed. Better is to avoid TWiki syntax at all when using classnames. So TWikiGrayText should be called twikiGrayText.

---

Contributors
-- ArthurClemens - 07 Apr, 08 Aug 2004, -- MartinCleaver - 17 May 2004, -- MattWilkie - 17,20,31 May 2004,