Geoff Chappell - Software Analyst
On this page I collect problems that I have observed in my ordinary use of Expression Web but have not yet classified. As the write-up continues, some organisation may become plain, especially for problems that are reliably demonstrable. These are then moved to separate pages, as for the following:
Unfortunately, much of Expression Web’s misbehaviour remains a mystery to me, in the sense that I don’t know how to reproduce it. A few of these are described here for now. I really must stress that I think I have better things to do than catalogue this software’s numerous defects and that these are just a small selection of observed problems. At the time I have a problem with Expression Web, I’m writing up real work that I bought the program for and I therefore do not often redirect my mind to writing up the bug. I just learn to put up with this program’s errors and hope that the everyday experience of working around its defects does not distract me too much from the real work that the program is supposed to help me with. I really would much prefer that this software worked acceptably. It is instead like no software that I have ever used, let alone paid hundreds of dollars for. That any one person can find even this many glitches to write about supposedly commercial-grade software is a disgrace.
Almost everything noted here and in the separate pages dates from the original Expression Web but persists at least to Expression Web 3 (including SP1). Is it that Microsoft’s testing programme does not find the obvious multitude of errors in basic functionality or that Microsoft’s quality control does not then care to get these bugs fixed?
Many of the problems noted on this page have not yet been checked for Expression Web 4 because they require extended observation of real-world editing. As explained in First Impressions of Expression Web 4, this new version shows almost immediately so serious a problem for me that I’m not prepared to let it into real-world use.
The feature by which Expression Web detects “code that’s incompatible with particular HTML and CSS schemas” looks like it might be useful some day. This website, for instance, is designed for viewing with Internet Explorer 5.0 and higher, preferably without having to make lots of special cases. It might help to have Expression Web alert me to my inadvertent use of a construction that requires a higher version. Thus far, however, there are only three circumstances in which I have yet seen the Code Error Detected icon in the status bar. One is where I have decided to ignore my own constraint about keeping to features that are supported by Internet Explorer 5.0. Another is when I’m typing in Code view and haven’t yet finished the code. The last, which is by far the most common, is when I am working in Design view and it is Expression Web that is doing the coding!
Perhaps I ought be grateful that Expression Web detects its own errors. Without this detection, I might keep typing away in Design view and not realise what a mess Expression Web is making of the HTML. Strangely though, I’m not grateful at all: I’m furious that Expression Web keeps making errors to detect.
The code errors are usually of the form where part of an HTML tag has got lost. Often, a character immediately after some preceding HTML tag has got duplicated. Sometimes, a pair of characters are duplicated. I suspect the editor has a bug such that it misaligns its copying from one buffer to another. I also can’t help wondering if some such bug is at least related to my experience that Expression Web crashes often, several cases of which seem attributable to good data having got overwrritten in error. An increased frequency of Expression Web’s detecting its own coding errors has often turned out to mean that a crash is not far away.
This problem persists in Expression Web 3. Indeed, it’s aggravated because the Code Error Detected icon stands out less well against the darkness of the new user interface, so that it tends to go unnoticed for longer, quickly compounding the initial code corruption. And as if to prove that these things have no end, double-clicking the icon now does nothing instead of taking me directly to the “detected” error. That may seem a small matter, but since it’s already exasperating to be using this feature only because the program itself made the error, it adds insult to injury that the programmers put their users to a few extra mouse movements.
A feature that I find especially helpful in Design View is the Quick Tag Selector at the top of the editing window. Suppose for instance that I am working on text in a list item and it occurs to me that I want the list assigned to a class. There are of course many ways to do this, but the quickest way I know is to click on the appropriate <ul> tag in the Quick Tag Selector. Then, if I know the class name, I can pick Edit Tag from the drop box and add a class attribute by hand, else I can pick Select Tag and choose a class from the list in the Class box on the Style toolbar.
In Expression Web 3 with Service Pack 1, the utility of the Quick Tag Selector is greatly reduced by a defect. It is still is useful for showing immediately the hierarchy of selectors that apply to whatever is currently being edited, but it does not select the tag that you ask for. Suppose, for example, that the caret is in plain text in a list item. If you click on the <ul> tag in the Quick Tag Selector and pick Edit Tag, you get the <li> tag.
This problem looks to have been fixed for Expression Web 4.
Several user-interface features sometimes just stop working, for no reason that I’ve yet been able to identify. An especially strange example is the Quick Tag Editor. Pressing the Ctrl+Q shortcut reliably produces the Quick Tag Editor while in Design view, but there is often no response in Code view. Sometimes there is. Often there isn’t.
This problem persists in Expression Web 3.
Another feature that sometimes stops working is the resolution of Include Pages. This feature dates from FrontPage as a Web Component. It acts as a design-time analogue of server-side includes: an HTML comment contains directions to insert HTML code from another page. When publishing to a site that has the FrontPage Server Extensions, the Include Page feature has the enormous benefit that very many pages can be changed just by uploading the few included pages that they share. Unlike some of the Web Components from FrontPage, this one presents no problems with standards compliance. Though it is not explicitly supported by Expression Web—see, for instance, that a search of the User Guide for “include page” produces no matches—the relevant HTML is recognised and users can insert it by hand or as a code snippet. Expression Web 3 even provides a toolbar button (though only on the Standard toolbar, which is not ordinarily enabled). All document pages at this site contain at least one Include Page, for the copyright notice.
Sometimes, when you open a page, some or all of the Include Pages are unresolved. I have not yet noticed a pattern, except that Expression Web sometimes crashes not much later. I have, however, noticed a workaround. Open the affected Include Pages, refresh the page that you wanted to edit, and then close the Include Pages.
This problem persists in Expression Web 3.
In Code view, the context menu entry named Reformat HTML causes Expression Web to rearrange the code in conformance with options set at the Code Formatting tab in the Page Editor Options. Why code that Expression Web writes for text I enter in Design View is not automatically formatted according to those options, I don’t begin to understand, but I’m glad to have the means to tidy the code’s white space and line breaks for easier reading. (Note that this is entirely distinct from the Optimize HTML feature, which edits the code non-trivially.) It would be better, however, were the reformatting not so quirky.
One of the Code Formatting options is to set a right margin. To all the world, a right margin is a vertical line beyond which text ought not extend. To Expression Web, it is a vertical line beyond which text must not start.
The default is a right margin at 80 characters, presumably to fit with a long established lowest common denominator for printing plain text from personal computers. The possibly few users who care will expect HTML code that only exceptionally exceeds 80 columns (and only then because of text that contains no white space or other breaking character). What Expression Web produces is HTML code that only exceptionally fits 80 columns. If this is by design, it ought be recognised as novel and be explained in the User Guide.
This problem persists in Expression Web 3.
That’s not to say that the Reformat HTML feature is unaffected by an upgrade to Expression Web 3. It’s not as if bugs persist from the original just because the code hasn’t changed. No, there are new ones. For this feature, some of the formatting rules are now completely ignored—not just treated to a novel interpretation, but ignored.
For a quick example, open the Page Editor Options dialog and verify that the br tag is configured to have a line break after its end. On a blank page in Design View, write a word or two, a line break (Shift-Enter) and a bit more text. Change to Code View and reformat the HTML. If your page has any XHTML document type, you will indeed see one line of text ending with a <br /> tag, and then more text on a second line. Do this with an HTML document type or even with no document type, and there will be no line break after the <br> tag. Well, silly you for not being as “with it” as are the Expression Web programmers and testers!
For who can know what reason, it sometimes happens that when you open a style sheet, e.g., to edit it by hand, the text that you are shown is not what’s in the file! In particular, rules for multiple selectors are unrolled, so that the same rule is reproduced separately for each selector. Especially unhelpful is that Expression Web takes upon itself to remove comments. For example:
span.regkey, /* registry key */
span.regval { /* registry value */
white-space:nowrap;
}
becomes
span.regkey {
white-space:nowrap;
}
span.regval {
white-space:nowrap;
}
Why it should want to unroll the rules, let alone remove comments, is anyone’s guess. I suspect it has something to do with Expression Web keeping an internal representation of the style sheet, and showing this instead of the actual contents when you open the style sheet as a file. The unrolling has always been done whenever Expression Web opens the style sheet automatically because I have done something that Expression Web has decided to handle by editing the style sheet on my behalf. I could be glad that Expression Web doesn’t just save its changes without showing me, but gladness for that would be the sort that comes from low expectations.
A workaround, though only when you open the file yourself to do your own editing of it, is to refresh the file, as from the View menu or by pressing F5.
I have not yet seen this problem in Expression Web 3.