Problems with Styles in Expression Web

If Expression Web does not succeed well at its treatment of styles, then it may as well not succeed at all. Styles are involved in even the most basic formatting of text, e.g., to change the font of a paragraph or to underline a word. Even if the user applies a format by clicking the Underline button on a toolbar, the program applies the format as a style. Instead of wrapping the selected text in tags, as does FrontPage, Expression Web finds a suitable style definition and wraps the selected text in tags with the style set as a class attribute. If no suitable style is defined already, Expression Web defines one automatically, with an invented name, in an inline style sheet for the page. While I don’t see any of this as helpful in my own use of the program (since I would define a style myself), neither do I quibble with it. I just infer that since Expression Web takes upon itself to re-interpret basic formatting in terms of styles, Expression Web ought to be very good in its handling of styles. I expect to see both ease of use and consistency of outcome.

In that spirit, let’s do a few very simple experiments such as you might think would have occurred to at least one tester at Microsoft long before the software ever made it as far as a pre-release release. For each of these experiments, start Expression Web in the configuration where it begins with an untitled page to edit and with no open site. Indeed, I have done these experiments on a newly installed Expression Web, thus still with all its default settings. This configuration is not required but I choose it as a standard initial state, presuming it to present the least opportunity for other factors to interact with the points being demonstrated. Most notably, there can be no complications regarding storage or publishing or any other features of the program. The tests really are just of how Expression Web edits HTML and CSS.

Let’s begin with the very simple formatting described above. On the blank page, type “This is underlined text”, double-click in the word “underlined”, and then click the Underline button on the toolbar. What you get is, of course, that the word “underlined” is underlined:

The tabbed rectangle around the p element is one of the Visual Aids, specifically Block Selection. It is turned on for a newly installed Expression Web, but it can easily be turned off from the View menu. I myself find it more distracting (and even obstructing) than helpful, but in the interests of examining Expression Web as it comes, I leave it on for these experiments.

Which Style?

Once you start defining styles (or have them defined for you), you need some way of determining which style is applied to any given characters of text. After all, your page may end up with a lot of applicable styles, drawn from possibly many style sheets, and it may have been years since you edited the page. It may not even be your page that you’re editing. To know what style to apply to some given text, you will want to know what styles are used already for similar text elsewhere on the page.

If I labour the obvious need for this feature, it’s because Expression Web treats it as almost incidental. Expression Web provides two style indicators that are easily found: the Apply Styles task pane and the Class box of the Style toolbar. The Apply Styles pane takes up a relatively large amount of screen space to show you a list of styles. Among these, the style for the current selection is highlighted, but you are in general left to scroll for it. In the Class box of the Style toolbar, the current style is immediately visible, with the others in a drop-down box if you want them, but this toolbar is not ordinarily displayed. A quick indicator of style was evidently not a priority for the Expression Web programmers.

Still, at least an indicator is provided, even if obscurely or incidentally. The grounds for criticism is that the indicators are not entirely reliable. To see this, let’s continue the experiment and ask whether the style that has been applied to the word is also applied to the space that follows it.

The Trailing Space

In probably all Windows programs, double-clicking a word selects both the word and the space that follows it. The merit of this is especially clear when you move a word by dragging and dropping. You want the trailing space to move with the word. This spares you from having to go back to where the word was, in order to delete its trailing space, and you don’t have to insert a space at wherever you moved the word to. By contrast, when you format a word, you typically don’t want to include the trailing space. In our present example, it would look silly were the underlining to extend beyond the word. A convention seems to have developed in which some Windows programs, especially the more sophisticated ones, include the trailing space in a double-clicked selection and in any drag and drop of the selection but exempt it from any formatting of the selection. Examples include Word, FrontPage and Expression Web. (A readily available counter-example is WordPad.)

Since the formatting for our experiment is just an underlining, it’s immediately plain that Expression Web has not formatted the trailing space. With other sorts of formatting, such as bold or a change of font, there’s little if any visible change to the space. So, in looking to the generality, let’s select the space and ask the Apply Styles pane or the Class box on the Style toolbar to tell us what style the space is formatted with.

Believe it or not, Expression Web’s answer depends on which direction you move while selecting the space. Whether you use the mouse or the keyboard, if you select from left to right, the trailing space is said (correctly) to have no style:

Select from right to left, however, and the same trailing space somehow acquires the same style as the preceding word:

Of course, this behaviour is not just for trailing spaces. You will see it, for instance, if you underline the letter e in text and then try to find whether any style has been applied to the x.

It’s bad enough that Expression Web gives so little thought to helping you know what style applies to a selection, but that its answer depends on which direction you select in is just bizarre. Note that FrontPage not only provides an obvious indicator, in the Style window on the Formatting toolbar, but gets the answer right for both directions. If Expression Web’s different behaviour is intended, it will be fascinating to hear Microsoft’s explanation. (The obvious hypothesis is that the behaviour is an oversight. Expression Web shows the style that will apply to any character typed at the current position of the caret and just ignores that text is selected.)

Explicit Styling

Of course, for FrontPage, you have to define your own styles. To underline one word, given an expectation that you may want to underline others for much the same reason, you will have defined something that FrontPage (and Word before it) calls a character style and implements as a class selector for the span element. If you were doing this as a FrontPage user, you will likely be defining your own styles in Expression Web, too. So, in the simple experiment above, instead of clicking the Underline button, create a New Style, in a name of your choice, e.g., “.stressed”, and then explicitly apply this style to the double-clicked selection:

Yes, when you format a double-clicked selection with explict awareness of CSS styles, Expression Web decides that the trailing space is part of the formatting. If you don’t want to include the trailing space, which you usually will not—see how silly it looks above—then give up the practice of double-clicking to select a word. Instead, select it by moving over it carefully with the mouse or with keystrokes, or double-click but remember to unselect the trailing space. Then, every time you go to this extra trouble, you can be glad that Expression Web makes it so easy to format text using CSS and is so obviously an advance on FrontPage.

Manual Style Application

If you are happy to have Expression Web generate styles for you, then you can exercise some control over the feature by opting for Manual Style Application. Let’s see how that works for our simple experiment of formatting one word in a sentence. From the Page Editor Options, go to the CSS tab and choose Manual Style Application. Then, return to the blank page and repeat the simple experiment of typing the sentence, double-clicking the word and clicking the Underline button. Now you don’t have the problem of whether the trailing space is formatted. If you do this with the original Expression Web, you get the whole paragraph underlined:

Two things to notice about this result are incidental and can be disabled. In addition to the tabbed rectangle from Block Selection, the p element is also surrounded by a (very) pale blue box with a thin blue border. This too can be turned off, but not as a visual aid: at the Style Application toolbar, click on Show Overlay (even though what you really want is to hide the overlay).

Of course, the stand-out problem is not the clutter of the visual aids. It is that the whole paragraph has been underlined. You select one word, apply some formatting, presumably intending to affect just the selected text, but Expression Web formats the whole paragraph. This is absurd. I’d say not just absurd but “absurd, of course” except that in no end of supposedly expert reviews that talk apparently knowingly about Manual Style Application, I have not seen any that comments on this behaviour. They’re experts. Since they surely didn’t comment on Manual Style Application without having done very simple experiments like this, it must be that the behaviour is absurd only as I perceive it.

In fairness to Expression Web, I must point out that the software does indicate that the whole paragraph will be affected. That is what the pale blue overlay is for. There’s a logic to it, to do with what the Style Application toolbar describes as the Target Rule. When the Target Rule is New Auto Class, as for the picture above, Expression Web generates the same CSS as for Automatic Style Application, but it applies the new class to the block element that contains the selected text. There seems to be no way, e.g., by choosing a different Target Rule, to confine the style’s application just to the selection.

Perhaps the feature operates as Microsoft intends, but to me it seems at best half-baked: how can it be that Manual Style Application gives you “precise control over which styles Expression Web modifies and what kind of styles it generates” if none of its options reproduce what Expression Web does for Automatic Style Application?

Repeat this experiment with Manual Style Application in Expression Web 3 and you do indeed get the same result as with Automatic Style Application, i.e., the selected word (without its trailing space) gets formatted, not the whole paragraph. Against this is the problem of how to get Manual Style Application enabled, since Expression Web 3 crashes when enabling Manual Style Application while no page is open.

Non-Style Formatting

Thus far, we have that for the simple exercise of underlining a double-clicked word in a sentence, Expression Web has three different outcomes from three different methods: it formats just the selected word, or the word and its trailing space, or (if only in the original Expression Web) the containing paragraph. You might think this is bad enough, such that there surely can be no more silliness to be talked about. You would be wrong.

Each of those three methods produces the formatting as a style, at least in our case where the formatting is just a matter of underlining. However, for some formatting, Expression Web actually doesn’t work with styles, whether to generate a new name or reuse an existing style. Instead, despite all the talk of being style-based, it codes the formatting in terms of HTML tags.

If you format for Bold, Italic, Superscript, Subscript, Strong, Emphasis, Sample, Definition, Citation, Variable, Keyboard or Code through the Font dialog (from the Format menu), then Expression Web wraps the selected text in , , , , , , <samp>, <dfn>, <cite>, <var>, <kbd> or <code> tags. For each of these, if you want to format some text and have Expression Web actually code it as a style, it seems you must define the style yourself. That was true of FrontPage, anyway, and so CSS-aware FrontPage users don’t have to change their technique, but what does it say of Expression Web’s supposed improvements for CSS that it changes to styles for some formatting but not for all? Where’s the consistency?

Inline-Style Formatting

There is also a case where formatting is applied as an inline style, i.e., as a style attribute in a tag, rather than as a class attribute for a style that is defined in a separate style block. This is how FrontPage handled all Font effects that had no corresponding HTML tag, namely, Strikethrough, Overline, Blink, Small caps, All caps, Capitalize and Hidden. Expression Web keeps this behaviour if you format text as Hidden. What’s so special about Hidden?

Character Styles

As noted above, those FrontPage users who defined styles for inline text will have style sheets that contain class selectors for span elements. The Expression Web designers can’t possibly have been unaware of this, and so it seems fair to say that they must have chosen not to support it in their consideration of the upgrade path from FrontPage. By support, I don’t mean to suggest that Expression Web should distinguish styles as paragraph or character styles as did FrontPage. CSS already has a much richer differentiation and Expression Web rightly puts CSS to the front. I ask only for recognition. When you’re about to format some inline text, you should have to hand all the classes that have been defined for span elements. After all, if you proceed to format the selected text, Expression Web will wrap the text in tags. So, why not regard the selection of inline text as implying a span element whose applicable styles ought to be displayed in the Apply Styles pane or the Class box of the Style toolbar?

As things stand now, if you have a style defined only as a class for a span element (whether you acquired it from FrontPage or you simply like to make your definitions no more widely applicable than you think they need to be), then Expression Web puts you to two steps to apply the style to some selected inline text. First, wrap the selected text in tags, e.g., from the Quick Tag Editor on the Edit menu. Then, choose a style, now that Expression Web recognises it as applicable.

Now, Microsoft might regard this complaint as more of a request for a feature than criticism for a bug. I might agree with them had FrontPage never existed and were Microsoft not so happy to say what an improvement they have delivered in the change to Expression Web. In FrontPage, given a style that is defined only as a class for a span element, applying that style to an inline selection of text is as easy as choosing it from a drop-down list. That it’s not at least as easy in Expression Web is at best deficient. For software that is supposed to make working with styles easy, Expression Web can be awfully clumsy.