Problems with Expression Web

Topic status automatically displays here - do not remove.

Bookmark this topic  Print this topic

By Colin Ramsden, November 2006.

You don't really get to know a product until you use it. I've been working with Expression Web (EW) Beta 1 for a little while now, and I've observed some things which are not-quite-right. This topic lists the issues and problems I've encountered so far, and will be amended as necessary.

If you've had a different experience, or would like to comment about (or even correct) this page, just send me an email about it. There's a preformatted link at the bottom of this page for that very purpose. One click and we're communicating. I'd like to hear from you.

Subjects on this page include:

• The case of the disappearing named character entities
• The case of the non-displaying font family
• The case of the zero size files
• The case of mysterious automatic image resizing
• Items for further investigation

 

Who am I? > find out more

---

The case of the disappearing named character entities

Named character entities have been the platform independent method for consistent HTML topic display behaviour for as long as HTML has been a standard—from over a decade ago in the last century! Now, with the advent of Microsoft (MS) Expression Web Designer—renamed Expression Web (EW), MS have introduced a WYSIWYG HTML editing environment tool which removes and replaces named character entities at will. In my view, this is not good.

For example, whilst reviewing and working with EW (Beta 1), I observed that my deliberately placed non-breaking space character entity " " positioned within the middle of my paragraph text—and not at the end of the paragraph—was being automatically replaced with a standard space character upon the next save or refresh.

The following paragraph snippet provides an example of the cause for my concern:

"... experiences with MS FrontPage, and with MS Visual Web Developer (Beta 1)—as reviewed elsewhere. (See Working With Visual Web Developer.)"

<p class="txt">
&quot;... experiences with MS FrontPage, and with MS Visual Web Developer (Beta 1)—as 
reviewed elsewhere. (See <a title="Jump across to different topic" 
href="WorkingWithVisualWebDeveloper.htm"><img alt="Jump to separate topic" 
src="../../Graphics/Navigation/arrowfwd.gif" width="9" height="9" />&nbsp;Working With 
Visual Web Developer</a>.)&quot;
</p>

My intent is that the inline image and the hyperlink text immediately following it, always remain together, so that a line break or text wrap could not separate them over different lines. To accomplish this in the past, I have deliberately inserted a non-breaking space named character entity " " between them (highlighted above).

This has always worked fine with FrontPage (FP), until now when EW "assisted" me by removing the entity allowing the break of separate lines as shown in the example snippet above.

In fairness to EW, I have observed when working in 'Split view' that it uses the non-breaking space named character entity for additional spacing at the cursor position, and removes them as new paragraphs are made.
I'm quite OK with that, because it does a fairly good job at it. However, I'm not happy that it also removes them from the middle of the paragraph, well away from the cursor position.

Using the example above, I found that if I deliberately did insert the non-breaking space named character entity between the image and the hyperlink text as desired, in 'Code view', I could save the document and EW would leave it there. However, it would not display as expected in 'Design view', as if it wasn't there.

I also found by experimentation that if I reformatted the HTML using the 'Reformat HTML' command in 'Code view', EW would remove the non-breaking space named character entity and replace it with a normal space character. That's the result which causes this incorrect and unwanted display behaviour.

 

---

The case of the non-displaying font family

In the process of writing the previous subject in this topic (about the disappearing named character entities), I observed that the example style I applied, which used Monospace as the font family, did not display correctly in (EW) 'Display view', even though it does display as expected in a (IE) browser. What I saw was the Verdana font applicable to the other text elements of the page. Perhaps this is a bug with the EW viewer?

I tried several things to identify the source of this wayward display behaviour:

1. First up, using the 'Apply Styles' task pane in EW, I was able to observe how EW interpreted the style rules attached to the document, by expanding the 'Contextual Selectors' branch of the styles tree.

   It works by listing and highlighting the style rule names which are applicable to the currently selected paragraph (or page element) in the topic page editor window (Design or Code view). This is extremely useful in determining which style rules are being applied, and which are not.

   I was able to see that I have two stylesheets attached to my documents, one for 'screen' display, and one for 'print' display. To make the diagnosis easier, I unattached [disconnected?] the 'print' stylesheet by using the 'Manage Style Sheet Links' context (right-click) menu in the 'Apply Styles' task pane. That halved the number of possibilities. [Note to self: Reattach the print stylesheet after this problem is resolved—before publication.]

2. Secondly, I examined the applicable font families for the wayward paragraph in question, by clicking within the paragraph in 'Design view', and then hovering (the mouse) over each applicable style rule name listed in the 'Apply Styles' task pane. This causes the actual rule to display in the tooltip for examination. I was looking for some duplication or overriding conflict which would explain why I wasn't seeing the Monospace font displayed for that paragraph in the topic page editor. I could find no conflict or syntax error.
3. I tried applying the Monospace font directly to a test paragraph to confirm that the editor could actually display the font family. I note that EW created a new style and inserted it into the page header, than applied that style to the test paragraph, instead of inserting an inline style as expected. The result is as follows:

   This test paragraph has been formatted as monospace using a style rule on the page.

   That displays OK, so the problem's not because the editor can't display the font family. Yet it can't or won't display the style from the stylesheet, so perhaps there's something wrong with the rule declaration after all. 

4. A direct comparison between the rule in the header created by EW, and the existing rule in the stylesheet did show a difference:

   The working style rule created by EW on the page:

   font-family: "Courier New", Courier, monospace;

   The non-working style rule from the existing external stylesheet:

   font-family: Monospace, Courier New, Courier;

   Notice that there are actually a few differences:

   • the order of the fonts places Monospace as last and first respectively;
   • The capitalization of "Monospace" is different;
   • the first font family is enclosed in double quotes in one, and not the other.

   Is the problem simply that EW doesn't recognize the rule declaration unless it "exactly" matches? Or is it something to do with standards compliance to the CSS 2.1 default standard for the site, (declared in EW)?

   Only further testing and information will tell.

5. I'm sure that the order of the font families in the style declaration is simply the order or preference of application. First in the list (reading left to right) is applied first. If unavailable on the viewers system, the next in the list is applied, and so on until the browsers default is used as a last resort. So I didn't think this was wrong, and changing the order would only change the preferences. 

   Changing the capitalisation was as easy as editing the stylesheet. I did this in EW by selecting the misbehaving paragraph in 'Design view', then right-clicking (or selecting the drop-down arrow) on the highlighted rule in the list under 'Contextual Selectors' in the 'Apply Styles' task pane, and finally selecting "Go To Code" from the popup (context) menu. I edited and saved the stylesheet, then returned to this document by clicking it in the EW editor tab strip.

   Tip

   You can quickly toggle between open documents in the EW editor by using the keyboard shortcut Ctrl + Tab. Holding Ctrl and repeatedly pressing Tab will cycle forward through all open documents. Holding Ctrl + Shift and repeatedly pressing Tab will cycle backwards.

That solved the problem. It was a simple as EW not being able to interpret capitalisation of a font family name.
I've altered "Monospace" to "monospace" throughout both stylesheets.

 

---

The case of the zero size files

Whilst working in EW, with several files open, I reached a point where I could not save a document. EW told me:

"The file is in use by another user. Resave to another filename"

or words to that effect. It forced me to create duplicate files. [I lost the screengrab of that error message —damn].

Subsequently, once this behaviour started for one file, it occurred for a few more, until I shutdown and restarted.

Upon restart, the files in question displayed alarmingly as having zero file size! Had I lost their contents? Oh no!?!:

The EW 'Web Site' file explorer dialog showing highlighted files
with zero file sizes!

Interestingly enough, I observed at a later date that even the root folder listed files with zero file size:

The EW 'Web Site' file explorer dialog showing my project root folder
scaringly with lots of zero byte size files. What the ..?.

It does not appear that these files are actually zero bytes long, just that the file viewer lists them erroneously as such. This will require further observation.

I have since observed that this disparity is apparently playing havoc with the Web Site publishing functionality.
It marks unchanged files as having different timestamps, and requiring update, which is really not necessary.

This requires further investigation. I shall update this topic when more information become apparent and available.

 

---

The case of mysterious automatic image resizing

I had the case where some images in my web were mysteriously changing their size, and destroying my lovely layout in the process. Upon further investigation, I discovered that it all started after I had altered the EW 'Page Editor Options' CSS settings.

To prevent EW from automatically inserting non-compliant XHTML 1.0T web standard "Height=" and "Width=" properties to an image tag when inserting images (instead of applying CSS style formatting properties), I tried deselecting the Tools>Page Editor Options>CSS tab>'Use width and height attributes for images instead of CSS' checkbox:

The EW 'Page Editor Options' dialog CSS tab with non-CSS manual sizing

I would have expected that this would cause the writing of the image size as style attributes to the tag, because of the "instead of CSS" in the setting. However, upon examination of an inserted image (above), it had not done so:

<img alt="Page Options CSS tab properties dialog" 
src="images/EWPagePropertiesCSStab.jpg" />

Note that there are NO image size properties to be found—neither as outdated "Height=" and "Width=" properties (which I don't want), nor as attributes of the "Style=" property (which I do want).

This then left me with the problem of having no defined sizing properties for the image.

Comment:

So far as I'm aware, an HTML page will display (render in the browser) much faster and accurately if you provide an image's dimensions in the HTML, without the need to wait for the browser to fully download the image to determine its dimensions; so I have always followed the recommended practice of declaring image dimensions in my pages.

The next step was to find a way to have the image sizing applied—in the manner I wanted, using the "height" and "width" attributes of the "style" property—so I figured the image properties were a logical next choice.

In an attempt to have the CSS properties applied, I right-clicked the image in 'Design view', and selected 'Picture Properties'. On the Appearance tab, in the 'Size' section, I checked 'Specify size':

Picture Properties dialog with 'Specify size' option checked

As previously, I would have expected this time that this change would write the image size as style attributes to the tag, however it had not done so! It appears to have altered the img tag rule in the attached stylesheets instead!?!

Oh no!!! That causes all sorts of grief—so it's not the answer I was looking for.

It appeared that this particular combination of checking BOTH the 'Use width and height attributes for images instead of CSS' AND the 'Specify size' properties causes EW to hardwire the "img" rule in the stylesheet to the fixed width and height property values of the image I just inserted!

The unwanted side effect of this action is to resize EVERY image within my site (linked to those stylesheets) which did not specifically have size properties already set.

What next?

After inserting images (using drag-and-drop or paste) into an open HTML file whilst displayed in 'Design view', and upon saving, I further observed that EW mysteriously prompted to 'Save Embedded Files': 

EW Save Embedded Files Dialog

See that the stylesheet was listed. Given that I had made no changes to the stylesheet, and that if I did I would have saved it separately, it was most curious that EW wanted to save it. EW must have changed it in some way, and I didn't want that! My stylesheets are sacrosanct, and must be left alone! I don't want EW changing it willy-nilly.

Selecting OK did indeed allow EW to change and save the stylesheet. Subsequent examination of the stylesheet revealed that EW had added a 'width' and a 'height' parameter in the 'img' rule. The real problem with this action, was that it caused all images (without inline style sizes) to resize to the 'img' tag dimensions! That's very bad.

On the next image import, after this occurred, I clicked on the 'Set Action' button, and found an option to have it leave the file alone:

The EW 'Save Embedded Files' dialog 'Set Action' settings

This prevented the stylesheet from being altered, but didn't do anything towards preventing the action in the first place. I searched through the 'Page Editor Options' dialog, but could not find anything relevant to EW saving its style changes to the stylesheet, other than on the CSS tab, as highlighted below:

The EW Page Editor Options dialog CSS tab defaults

Clicking the 'Reset Defaults' button displayed the above settings. The only change was the one I had made to option to 'Use width and height attributes for images instead of CSS'. After importing another image, and observing the 'Code view', I was puzzled that EW did not apply the size properties to the newly imported image tag. I was now left with images that had no declared sizes, and a Page Editor that insisted upon altering the img tag rule in the stylesheet. I think this was also puzzling to EW, so it crashed.

After a restart (and crash report to phone home—just like ET!) it appeared that the aforementioned 'Page Editor Options' property to 'Use width and height attributes for images instead of CSS' had returned to unchecked. Curiously enough, I did set this option, and close EW. Upon the next restart, this option was unchecked! Perhaps this option is not remembered!?! I shall try again, and monitor the situation.

A promising solution

There's too much going wrong here to leave this matter unresolved, so I went searching through the EW help.
It described the operation of the 'Auto' option in the 'Page Editor Options' CSS tab in starkly contrasting opposition to my expectations.

It stated, surprisingly, that all the drop-list options on the CSS options page were only applicable when the 'Auto Style Application' option was selected, (which was not the default!). It appears that the default is 'Manual'.

That turned my thinking on its head! I had it all wrong! It appears that you could better control the 'Auto' formatting functionality, than the manual!?!

The answer to my problem was to select 'Auto Style Application' (to have the sizing dimensions applied during image pasting), and to select 'CSS (inline styles)' for ALL the drop-list options (to have EW leave my stylesheets alone):

The EW Page Editor Options dialog CSS options
customised to work for me my way

The final piece of the puzzle was to set the option to 'Only reuse classes with the prefix "style"' which instructs EW to modify the attributes of the "style" property. That's what I wanted in the first place!

Going back over the images I had previously installed, in 'Design view', right-clicking each and selecting 'Picture Properties'>Appearance tab>'Specify size' option, finally applied the inline size attributes as wanted to the "style" property of the individual image tags.

 

---

Items for further investigation

The items listed below are in draft format for further elaboration in due course. This is a work in progress. If you'd like to be informed whenever this topic is updated, just click the email link at the bottom of the page, send me your email address, and request that I keep you updated. I'd be happy to.

A

Swapping between 'Display view' and 'Code view' causes some page elements to disappear, like they did in VWD. This is not consistent, or at least, I don't yet know the cause of this behaviour. Luckily, it appears that unlike this behaviour in VWD where the data was lost (forever?), in EW the undo function works to restore the missing data.

Dragging and dropping paragraphs around within a list also appears to cause this problem.

I think its a synchronization thing. Moving the selection between these views does seem to cause the display to jump about as it renders the selection in 'Display view'. See the example below, taken from 'Code view', where the first word in the text is repeating the leading two characters, and where the closing tag two paragraphs later is missing the leading two characters of the tag:

<p class="txt">
DrDragging and dropping paragraphs around within a list also appears 
to cause this problem.</p>
<p class="txt">
&nbsp;</p>
<p class="txt">
Bp>
<p class="txt">

Note that the 'Design view' displayed just fine (without error) whilst the 'Code view' was misbehaving. At the same time, other sections of the document were also altered:

<p class="txt">
Ap>
the MS online community have questioned this behaviour. p&gt;
p>
<h4>
See Also
h4>

This behaviour did eventually make itself visible in the 'Design view'. I had to manually correct them:

DrDragging and dropping paragraphs around within a list also appears ” 

SpSpellchecker works more effectively than VWD, which didn't have or ” . 

 

B

Interesting behaviour—requiring further investigation—with the conversion of named entities into ASCII chars. The insert symbol also inserts a font style for the symbol. The inverse is the apostrophes are converted to "'" which I notice is the ASCII decimal value. This appears to be inconsistent behaviour. I note that others in the MS online community have questioned this behaviour.

 

C

The CSS editor "Reformat CSS" function broke my CSS.

I have observed that something in EW—the CSS editor I think—has separated many of my multiple common rule declarations into separate single rule declarations each with a single class, duplicating the rules for each. Perhaps because I've declared a CSS standards (2.1) for the EW default compliance.

This appears to have broken the appearance of the hyperlinks in my topics. I've had to add correcting style rules to the screen stylesheet to counteract the display behaviour of the 'print' stylesheet which now inexplicably dominates.

 

D

The 'Apply Styles' task pane refreshes and expands all branches of its tree whenever the current topic in the editor is changed.

 

E

I wonder if the editor has functionality to adjust line-wraps to avoid word widows at the end of the preceding line?

 

F

When inserting images in 'Design view' using drag-and-drop, the automatic inclusion of dimensions (height and width) does not include a descriptor (such as "px").

 

G

The page editor makes changes to the attached stylesheet behind the scenes, when you readjust the formatting (style) of a classed page element. I wonder if there's a way to stop it from altering my predefined styles?

For example, the topic "HowToInsertGraphicsIntoRTFs.htm" contained several inline formatting using the 'Font' tag, which I edited to have an applied style instead. I was changing the appearance of the text, and when I saved the topic, I noticed that I was being asked to save embedded files too! As there were no embedded files in the document, and I hadn't changed any, I wondered what was happening. It was changing the stylesheet! Oh, no!?!

I opened the stylesheet, and hit undo, to see what was changed. Sure enough, it had altered the style which was applied to the text I had been editing in the topic. This could become a real problem if it "automatically" changes things behind the scenes! 

It will require further investigation to find a resolution.

Update

To prevent EW from altering your attached stylesheets, select Tools>'Page Editor Options'>CSS tab>'Auto Style Application' option, and in every drop-list option, select "CSS (inline styles)":

The EW 'Page Editor Options dialog CSS tab
with 'Auto' formatting selected and with
all options set to "CSS inline styles"

 

H

EW crashes if you select a 'LI' tag in the tag bar, and press enter:

Watch what happens if you
select a LI tag in the tag bar,
and press Enter

I since discovered that I can also reproduce this crash behaviour with the 'DD' tag.

I

EW changes all relative- and hyper- links on the page to absolute links. After creating a new page in my site by opening a template version and saving it as another file name, I was prompted to also save the linked files and images. It turned out that somehow I had opened two instances of EW, and this was possibly causing that behaviour.

J

How do you close the "Web Site" publication screen? (opened with File | Publish Site, yet with no close X button). It seems that you can alter what's displayed through the menu Site | Folders and Site | Remote Web Site.

[up to K!]