Recently in CSS Category

Overring the Ordered List CSS on MT

| | Comments (0)

As I've noted before, I'm not too crazy about using CSS to control presentation of ordered lists. Normally, my solution is to declare my content XHTML transitional and still use the type="" attribute. When playing with a content managment system (CMS) though, you may not have that option.

I just realized that my template in Movable Type (MT) actually has a setting that makes all OL's the decimal type (i.e. 1,2,3...). That's fine except if you have a nested list, in which case you nave nested lists all being numbered 1,2,3. Even my editor, who is no usability guru, commented that this could be confusing (no kidding).

In the code, I HAD made the nested list type="a" for lower-case alpha, but the CSS in my MT template overrides any type declaration I make. Fortunately, Movable Type allows me to add custom CSS to the template, so I did. You can see the code below, but note that #alpha-inner refers to the DIV for the main content. I don't want to mess with OLs in the navigation or sidebar widgets...yet.

/* Nested OL fix */
#alpha-inner ol {list-style-type: decimal;}
#alpha-inner ol ol {list-style-type: lower-alpha;}
#alpha-inner ol ol ol {list-style-type: lower-roman;}

What this declaration does is make first level OL's decimal (1,2,3), the second level lower-alpha (e.g. a,b,c) and the third level lower-roman (i,ii,iii). If I get to a 4th level, I will probably have to rethink my content.

FYI - You can use this strategy on any CMS so long as you or a developer can access the CSS styles, but I do recommend restricting the domain to whichever DIV is the main content. Navigation is often done with a list with its own CSS which should be left alone until you have a better idea of how you want to hack it....

List of CSS Tutorial Links Posted

| | Comments (0)

Just posted a list of my "Go to" tutorials on CSS as a Page (listed under the "links" section). Or...just go to

Ordered Lists and CSS - Are we losing semantics?

| | Comments (4)

I'm about to question a pearl of standards/accessibility conventional wisdom and ask if we need to rethink how ordered lists are coded in terms of CSS. That is, are we putting too much semantic information in the CSS?

The standard mantra for ordered list OL standards is to use stylesheets to change list numbering types as in the examples below. Another is to make sure that nested lists change numbering schemes between levels to mark a change in list level.

Capital Alphabetical
Lower Roman
  1. Item 1
  2. Item 2
  3. Item 3
  1. Item A
  2. Item B
  3. Item C
  1. Item i
  2. Item ii
  3. Item iii

This is a change from the old days when you would specify numbering schemes and start points with embedded attributes (e.g. <list type="A"> if you wanted capital letters).

From a processing level it makes sense because all ordered lists are numbered lists in disguise. And since modern screen readers appear to recognize the new styles, it appears that a major hurdle is cleared.

On the other hand, this means that all numbering scheme information is in a CSS? That's fine...unless a user chooses to ignore your stylesheet and use a custom style sheet. Then the potential is for a nested listed with distinct numbering levels to become an inaccessible nested list using the same numbering scheme at all levels. Hmmm.

Nested List with CSS Nested List, CSS Disabled
  1. Top Level Item 1
    1. Second Level 1
    2. Second Level 2
      1. Third Level 1
      2. Third Level 2
  2. Top Level Item 2
  3. Top Level Item 3
  1. Top Level Item 1
    1. Second Level 1
    2. Second Level 2
      1. Third Level 1
      2. Third Level 2
  2. Top Level Item 2
  3. Top Level Item 3

I'm not sure how serious a problem this is, but it is a possible gotcha. The line between "presentation" and "semantics" can be a little fuzzy at times. Of course, if I want my Hebrew numbered lists, I have to rely on the new styles.

Postscript (Feb 13)

This issue is being discussed on one of the language tech list, and someone else made the same objection (I'm glad it's not just me).

I can't believe I just used the <u> (underline) tag!

| | Comments (0)

OK we're not supposed to the <u> (underline) tag because it confuses readers who might think an item is a link when it's not. But still has it's uses.

For instance, I use the <cite> tag for book titles like Gone with the Wind. Normally the <cite> tag produces italics, but I used CSS to make my <cite> tag both bold and italicized (as in Gone with the Wind) for increased legibility (good functional reasoning here).

But suppose I need to highlight one word within the title for emphasis (e.g. It's Gone with the Wind, not Went with the Wind).

Visually I know that <cite> is already and bold and italic, but now I need to add a third visual element. My choices are 1) Use underline or 2) hack into my stylesheet for the blog and create some sort of custom <em> class or whatever (and add some serious bytes to my file). I confess I took the easy way out.

P.S. Be careful about including "<u>" in Blog titles though. You might want to use "&lt;u&gt;" instead.

Fractions in CSS

| | Comments (0)

If you want to use fractions (e.g. "1/2") the "number slash number" solution is usually fine for most documents, but you can use CSS to make prettier smaller scale fractions...but is a wee cumbersome.

Note: This solution was originally developed by Lars Bruzileus

First you have to shrink the numerator and the denominator to something like 75% - the slash stays at 100%. Then you have to raise the numerator up slightly (by .5 ex). You can also adjust the letter spacing depending on your font.

.den {font-size: 75%;}
.num {font-size: 75%; vertical-align:.5ex}

In the HTML the code looks like this:

<span class="num">1</span>/<span class="den">7</span>

And here's what it looks like:


Although I didn't like CSS for superscripts, I do think they are just the trick for vulgar fractions.

Adding a Frame to all Images Within CSS

| | Comments (1)

I write a lot of documentation with screen captures, but many times the images have white backgrounds and don't like without a border.

You can add borders in Photoshop, but if you have access to the CSS, it may be easer to write a style to add borders around an image.

A simple example is

CSS - img.border {border: 1px solid black; margin: 7px}
HTML - <img src="" alt="" class="border" />

Adding the margin also ensures there is a nice cushion around each graphic.

What made me switch to XHTML? XSLT!

| | Comments (1)

I read an interesting article from HTML Goodies reminding me that the switch to XHTML was mostly hype for a long time

As Philbin points out, most of the reasons given aren't valid. This is because XHTML and HTML 4 pretty much have the same functionality, so basically:

  1. Well formed HTML is as valid as well formed XHTML. HTML Strict is pretty strict by the way - no FONT tags or ALIGN attributes allowed.

  2. You can make the same stupid accessibility glitches in either HTML or XHTML (did you know that black on black text is valid code...but illegible?)

  3. Browsers will be supporting both HTML and XHTML for many, many years to come.

  4. Not all browsers support ad hoc combinations of XML and XHTML.
BUT Philbin did miss one thing that made me switch - XSLT. This is another XML schema which lets you convert non HTML XML into XHTML. But because XSLT is an XML schema, it can only reference another XML file...and only XHTML fits the bill. If you want an XSLT generated page to mesh well with the rest of the site, the entire site should really be in XHTML.

This may be a case of the future is coming, but it really takes 5-10 years for it to arrive.

By the way, Dreamweaver 8 was my "bestest" friend ever in the switch. You open any document, then go to the File menu, then Convert, then pick your format (I recommend XHTML Transitional for beginnners, unless you were already HTML Strict).

Once you do this, Dreamweaver magically converts all <br> tags to <br> tags, and all <img> tags to <img /> (and it adds the pesky slash to all your single line meta tags). It also adds the correct DTD statement (so I'm not having to cut and paste that either). After that your WSYWIG editors is set to produce the XHTML versions of the tags and Dreamweaver valildation is generally picker when it's XHTML so it finds basic glitches much faster.

Now...we just have to worry about XHTML 2!

Beware CSS for Superscript/Subcript

| | Comments (0)

Superscripts/Subscripts as “Presentation”

Both HTML and XHTML include the SUP tag for superscripts and the SUB tag for subscripts. However, if you’ve been involved in the standards communities, you may be “warned” against using the SUP and SUB tags and told to use CSS instead.

"Now sup and sub are presentational tags and should be avoided because the presentation should be in the CSS."

"Since SUP is inherently presentational, it should not be relied upon to express a given meaning."

So why are SUP and SUB even listed within the XHTML standard if they are only presentational? My answer is that they are sometimes NOT presentational. That is, the position of the character is meant to convey additional information which would be lost otherwise. For many academic purposes, the use of CSS only could actually cause additional accessibility issues because a user could ignore your stylesheet.

Disabling Stylesheets

Paragraph D of Section 508 specifically states

“Documents shall be organized so they are readable without requiring an associated style sheet.”

That means that if a user decides to disable your stylesheet (some low vision or color blind users do exactly this), then all CSS formatting information will be lost. If your user can parse your content without the superscript/subscript then all CSS is acceptable. An instance of this is trademark “TM” placement on a word. Your page is “prettier” if the “TM” sign is superscripted, but it’s not essential.

SupermanTM (superscript) = SupermanTM (no superscript)

If you use CSS positioning, but a user ignores your stylesheet, he or she will be able to parse the text in most cases. Although it would be even better to use the entity code &trade; (as in Superman&trade; = Superman™)

Academic Superscripts/Subscripts

In the academic world, superscripts and subscripts are usually there to indicate additional meaning, not just for the sake of typographical aesthetics. For example as points outs, in math, 2 superscript 4 means 2 to the fourth power, but “2-4” is the number 24. Now if you use CSS positioning and your user ignores your stylesheet, they may not be able to understand the content.

24 ≠ 24


Some users suggest options like “2^4” but that may not work in every case. For instance. in linguistics, gw ≠ gw. The first letter with the superscript w means rounded g; the second is a true consonant cluster. Again if you use CSS, and the user ignores your stylesheet, the reader will lose the information. Even better, you can add aural styles to SUB and SUP tags if necessary for screen reader supper.

Entity Codes

You can avoid the SUP/SUB tag, in these cases but not with CSS. What you would do is find the entity code for superscript 4 (&#8308;) or superscript w (&#695;) and use them instead...and hope you’ve specified the right font for everyone. The lesson is - you didn’t replace SUP and SUB with CSS but with more meaningful content (i.e. entity codes). See links below for a list

By the way, entity codes may be the wave of the future, but have their own problems. Not all common fonts may support the special characters (while the SUP version will almost always work) and screen readers may not understand the entity code and may spell out “unknown”. At least with the SUP/SUB tag the chances are higher that the user will hear the content of the tag.


If your superscripts/subscripts are adding meaning and not just there to be “pretty”, consider using the SUB/SUP tags or the more modern entity code (assuming it exists for your character)...but the most dangerous path would be CSS only.