What Ben Millard would like from CSS3 (5th March 2008)

(Lengthy reply to Tell the CSS WG what you want from CSS3. I’m likely to revise this entry as it’s a quick scribbling of ideas to make the 10th March 2008 deadline. Discussion takes place on the www-style mailing list and the CSS Working Group Blog.)

Big Picture

The things most relevant to my perspective as an author are:

Widespread Implementation of CSS2.1 Features

CSS2.1 defines a lot of really useful things. If only implementation was widespread.

CSS2.1 Selectors

These would allow me to use fewer class attributes:

Tabular values of the display Property

Would help with ease, accuracy and robustness of layout:

As an example, Calthorpe Park School’s layout mixes a combination of:

We shouldn’t need brain surgery for this effect! Tabular display ftw.

Review of some CSS3 Features

Multiple Backgrounds per Element

Enable much tidier markup for highly graphical and flexible layouts, such as Tower College and Umbel. Currently requires lots of <div class> or <span class> to layer all the necessary images.

CSS3 Selectors

Interesting for simplifying markup. Alternate table row styling, borders and backgrounds in nested navigation lists and other groups of specially styled elements, too.

The table of CSS3 selectors has “Meaning” as a column header. A paragraph after the table says each entry should have “Matches” added before it. The header column should be “Matches”, not “Meaning”? The terms “Pattern” and “Matches” are often used in RegEx and other pattern-matching systems, adding a familiarity bonus.

Shorthand

Shorthand properties in Level 3 seem more confusing than need be. Perhaps you should gather feedback on what authors would actually use these for?

Simple shorthand should make the common cases easy. Using the properties individually retains support for all complex cases. Much like the CSS2.1 border properties.

CSS3 Color Module

Having all colours in one CSS specification is convenient. Especially the named colour keywords.

Grid Positioning, Advanced Layout: Template-based Positioning, Perhaps Others

Widespread implementation of display: table-*; would make much of this redundant?

Ideas

I’m unsure if the suggested solutions here are the best available.

Horizontal Gaps in %-based Layouts

At the moment, I have to:

Setting width as x% minus yem would enable slightly less markup, slightly more robustness and other slight gains.

Table Cell Width and Text Alignment (Columnar Styling)

In the January GCSE Exam Timetable, I have these columns:

  1. Long names of exam papers, aligned left and made as wide as possible.
  2. Names of locations, aligned left.
  3. Times, aligned right. (3 columns.)
  4. Shortened examining board names, centered.
  5. Exam codes, aligned left. (Various mixtures of letters, numbers and punctuation.)
  6. Number of entries, aligned right.

I currently use lots of class attributes. I’ve seen it done other ways. It’s a perennial issue.

How about table markup like this (but without the comments): 

<table class="prose">             <!-- Contains long text -->
 <caption>Timetable for <acronym title="General Certificate of Secondary Education">GCSE</acronym> Exams, January 2008</caption>
 <colgroup class="main">          <!-- Exam names, important -->
 <colgroup>                       <!-- Left aligned locations -->
 <colgroup span="3" class="time"> <!-- Right aligned times -->
 <colgroup class="board">         <!-- Centered exam boards -->
 <colgroup>                       <!-- Left aligned exam codes -->
 <colgroup class="number">        <!-- Right aligned numbers -->
 <thead>
  ...
 </thead>
 <tbody>
  ...
 </tbody>
</table>

No other class attributes would be present throughout the table.

The relevant CSS would be like this: 

/* - Data Tables */
table.prose {
 width: 100%;
}
table.prose .main {
 width: 90%; /* Minimise the width of other columns */
}
thead th {
 text-align: center;
}
tbody th {
 text-align: left;
}
table .number, table .time {
 text-align: right;
}
table .board {
 text-align: center;
}

So <colgroup class> would set the styling for these columns. But it would be overriden by styles set on more specific elements, such as the <th> elements. Somehow.

The more tables a website has and the bigger they are, the greater the advantages of columnar styling.

Simplify the Language for Authors

A lot of new properties apply an image to the background of an element in different ways. There is a proliferation of side-by-side layout properties, too. They will not make authors’ lives easier, afaict.

We can set multiple backgrounds on an element using the general-purpose extensions to background. We can create side-by-side layouts using CSS2.1 features such as float, position and display.

Consider how much success HTML gains from trying to be simple for authors...and how much confusion still arises! Contrast that with the complexity of and overlap between all the features and syntax CSS Level 3 proposes.

Reducing the Number of Images and the Amount of Markup

Drop Shadows, Other Shadows

(Specific feedback as requested in CSS Drop Shadows.)

Sometimes, the shadow is cast by more than 2 edges. For example, the outer edges of Kainos’s layout and around photos in its main content. The footer on Umbel has a tall, strong shadow below with faint, thin shadows either side. They are joined with a curving, narrowing, faintening shadow. Each icon in the footer and the navigation list has a very soft, even shadow around its whole circumference.

Designers usually want shadows to look exactly as their visual shows. They drew them so I don’t have to guess and browsers need not figure out a sensible default.

Hard edges ruin the effect of soft drop shadows. They are better as graphics, at least in professional designs.

Using alpha-transparent PNGs with border-image would make box-shadow redundant. In turn, multiple background-image per element makes border-image redundant. They are equal in terms of markup optimisation, afaict.

So why have box-shadow? I can’t think of a reason.

Graphical Borders

I did the borders on Umbel by adding extra elements via Javascript. Each one is sized, positioned and given a background-image from the main CSS. I’ve seen it done other ways, all require adding extra elements one way or another.

I think multiple rectangular portions of a single graphic applied to the main containers would be best for this. No need for border-image and related attributes.

Selecting Rectangles from an Image

Each background-image and border-image requires a separate image file, afaict.

Selecting rectangles from an image allows all decorative graphics to be taken from a single image file. The markup can be as minimal as border-image would enable. A single HTTP transfer would download all the decorative images for that page (or for the whole website):

It is used in the UI for Mozilla and its extensions is similar to CSS Sprites. But selecting specific rectangles of an image file allows infinite variations in the size of the element without other parts showing up. This removes the need for empty space in the image file, reducing filesize.

You might spread decorative graphics across up to 3 images:

.png
for regular patterns along with alpha transparency effects, such as drop shadows.
.jpg
for photographic decoration such as “smiling people”.
.gif
for low bit-depth decoration such as icons or simple repeating patterns.

This would maximise image compression at the expense of 1 or 2 HTTP requests. If all your graphics are handled fine by one format, you’d only need 1 image.

Adding content images and graphical headings with <img src alt> would remain, of course.

Notes about Authorship of Examples

I was involved in making each website I’ve given as an example. I have a maintainance contract with Calthorpe Park School. I do not maintain the other websites.