[wiki] textbook css

zero · 2008-04-22 16:45:36

Who looks after / can access the stylesheets for textpattern.net?

ruud · 2008-04-22 16:52:45

The developers can (or should be able to) access the style sheets. Is there a problem?

zero · 2008-04-22 18:28:40

<samp> does not seem to be recognised, so I hoped that putting this in the css it might work:
samp {font: bold 1em “courier new”, courier, “lucida console”, monaco, monospace; }

<samp> is used to indicate sample text but is rarely used although it is not deprecated or anything.

ruud · 2008-04-22 19:10:54

Any MediaWiki experts here that can shed a light on whether <samp> is supported or not?

hakjoon · 2008-04-22 19:14:32

Well it seems that issue is actually that the mediawiki parser won’t allow <samp> as a tag, so it encodes the entities.

I changed the <samp>s to <code> which seems to provide a similar visual effect

zero · 2008-04-22 19:49:14

Thanks. The trouble is that there is already <code> on the page. This makes it a bit confusing in some places near where I previously put <samp>. So I’ve changed it to which is not great but better I think. is also supported and appears to do exactly the same as . However, changing one of these would probably caused undesirable effects on other Textbook pages where these are used.

That’s why I used <samp> in the first place because I felt that the text someone had to type in should be distinguished in some way. Oh well, let’s hope it’s supported in Dokuwiki.

hakjoon · 2008-04-22 23:11:25

Yeah I understand where you are coming from. In many ways <code> is also something someone would type or copy, but it’s really just splitting hairs at this point.

I would prefer if we used vs as is a deprecated tag.

zero · 2008-04-23 18:31:15

and are not yet deprecated in html 4 and may even make a comeback in html 5

Both elements are used extensively in existing Textbook pages so it is a major job to change them all to and . Browsers still support them too. I had a look at Dokuwiki and it will support <samp> and other elements provided you put $conf[‘htmlok’] = 1 in the dokuwiki.php file and then enclose raw html with <html> tags.

So Dokuwiki will allow more styling. However, should we alter pages to be more correct before moving them to Dokuwiki or leave them? And sometimes it is hard to know what is more correct.

In the html 5 link it says:
The strong element now represents importance rather than strong emphasis.
Personally, I think importance and strong emphasis mean the same thing in many situations :-S

About the b element it says:
The b element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is emboldened.
But surely a key word has extra importance! And why do most people embolden text? To make it stand out because it is important, imo.

I think for most people strong = b and em = i so why not use them all and apply styles of your choice?
But that’s getting a bit abstract. Any more practical thoughts on Textbook css?

hakjoon · 2008-04-23 19:56:44

Yeah the whole strong/b thing in html5 seems asinine to me, but then again I think HTML5 has a ton of bad ideas. I think anything that moves us further from strict parsing is just a step backwards. Tag soup wouldn’t exist if we had just made html strict to begin with.

I know html5 is supposed to dictate a common set of fallbacks for situations but as someone who was spent hours hunting down weird rendering differences because IE treats unclosed elements this way and Netscape treats it this way I want no return to that.

That’s a rant for another day though.

Anyway is fine if you don’t want to use <code>, we cna change it to <samp> when we change platforms. As long as it’s clear it something people should type in I don’t really care what it’s wrapped in.

Last edited by hakjoon (2008-04-23 19:57:06)

hakjoon · 2008-04-23 19:59:16

I really like your article/tutorial BTW.

zero · 2008-04-25 11:57:50

Thanks for the feedback, Patrick. I hope new users like it too.

I was reading the Textpattern Semantic Model and there’s a point highlighted in yellow about Textile and emphasis and it mentions screen readers knowing what emphasis means. I’d forgotten about that. So it looks like and should replace and as the norm. and could then be used for additional styling that is the exception. I wonder if there’s a way to search and replace those elements in a whole bunch of pages instead of a page at a time? I think all the tags pages could do with changing in that respect.

I’ve also taken the liberty of making alterations to the Textpattern Semantic Model because I thought some things weren’t clear enough or potentially confusing. I hope I haven’t confused things further!

Destry · 2008-06-28 06:33:51

A few notes on wiki styling based on some of the comments I’ve seen in this and other posts on the topic…

Element Parsing

As Patrick noted, MW prevents use of certain HTML elements. I’m not sure why, and I’m not sure of the entire list, but I don’t think it’s very many. Two others that do not parse are ACRONYM and ABBR, which few people in wikis bother with anyway and for justified reasons.

However, it’s very easy and semantically acceptable to fake a non-parsing element by using a span and class selector for that element. If deemed valuable, we could add such custom rules to the css on a case-by-case basis.

For example:

span.abbr {text-decoration: underline;}

Usage (within a paragraph):

The NOAA issued a warning…

Or another one with more utility (and meant to be used temporarily in copy):

span.highlite {background:yellow;}

Usage in wiki (within a paragraph):

This section still needs finished.

Frontoffice Editing of CSS

Although MW provides a means for editing the CSS file in the frontoffice as a special wiki page, we’re not going to do that. For one reason, the new design will follow a style guide, and therefore be relatively fixed (except for collaborative aides we might create over time and add to the style guide). Therefore when things need changed, it will be reflected in the style guide (which will be in the wiki), and the CSS edited the conventional way (on the file using a text editor).

Another reason is there will not be just a single CSS file to edit, and so the frontoffice editing approach will be useless anyway.

One thing I’ll be doing is taking the gargantuan main.css file and breaking it down into logical pieces. For example:

main.css
- layout.css
- copy.css
- portlets.css
- menus.css
- tables.css
- diffing.css
- collab.css

These may not reflect the actual file names yet, or what goes in them, but just to give the idea.

The main.css will stay so to not need to edit the php files that reference it; however, it will contain no (or few) rules, but rather use @imports to call each of the other css files in order appropriate cascading order. It’s then much easier to edit a particular “kind” of presentation in the other files later, rather than scroll 5 kilometers through a single CSS file to find that one little class selector, for example. This is the same CSS model used for the forum, if I remember correctly.

Browser Support

By default, MW tries to cater to every browser and their past 5 versions (give or take). As a result, there’s quite a few CSS files lying around just for different browser versions alone (hacks are not in the already monstrous main.css). One reason it’s so bloated by default is because MW default skins, especially monobook, have convoluted layouts and bad semantical structure. Furthermore, a lot of CSS is used that does not validate or is not supported across all browsers, thus one thing compensates for the previous, and so forth. A real Frankenstein mess that has evolved over years, and which the MW developers have yet to do anything about. This is one reason why MW has a bad rap for being an “awkward” or “heavy” wiki, which is too bad because it’s really doesn’t have to be that way.

We’ll retool the markup and CSS so it’s just a single cascade (indicated above) that works without a sea of hacks. David_1cog (?) made a little headway on CSS cleanup with the current skin, but there’s a lot more to do with cascading, markup…

For the record, we will support all modern browser versions and IE6. That means not the last 5 versions of Opera, for example. (If a div doesn’t float properly and your using Opera 9.0, sorry, we’re not hacking for it. Update your browser.).

IE6 (and 7 if necessary) may get a special CSS file that is fed via a conditional comment, that ways it’s easy to drop these files in the future when IE6 goes the way of Netscape.

Style Guide

Can’t say to much about this yet, except that we need to see the .com concepts. The actual wiki version of the style guide will mostly be written in parallel with new skin development.

However, if people have comments about style guide-ness, try and throw them down here, or in this thread if you don’t have a wiki account or are too lazy.

Last edited by Destry (2008-06-28 06:50:13)

Textpattern CMS

Textpattern CMS support forum

#1 2008-04-22 16:45:36