Yeah, you read that right. To re-iterate: if you want to code a site and expect it to load even semi-reasonably in Internet Explorer 6 or 7, you probably don’t want to write it or even touch it in Microsoft’s Expression Web Designer. At any rate, not this version of Expression.
Expression Web Designer is very Web 2.0 compatible. It’s the only really big HTML interface that validates directly against the W3C standards, by default checking page-display compatiblity against CSS 2.1, instead of against FF, IE6, or something. It does a very good job at that too, but unfortunately, it’s far ahead of Microsoft’s time.
When you write a page in “UTF-8” encoding, Expression Web Designer sometimes takes it to its head to write something called the BOM, which is a tiny, little, useless unicode character inserted into the code to prove something.
The only problem is, Internet Explorer 6 & 7 both fall under W3C’s so-called ‘older browsers’ list, and hence, don’t support the BOM at all. What you end up with is Internet Explorer incorrectly displaying php/ssi includes, and a bunch of unexpected HTML display errors will crop up in Internet Explorer but not any of the other browsers.
The code with such includes is exactly the same as if it wasn’t pieced together server-side, but for the presence of this BOM character that skews the code to hell. If you have some weird errors when dealing with server-side includes in Internet Explorer that don’t show up in any other browser on any other platform – this is your man.
To fix it you have to manually open all pages ‘pieced-together’ by php or whatever SSI you use in Notepad, and then proceed to save them as “ANSI” files instead of unicode.. Then get back to work.
The issue here is with PHP, not IE. If you use the include() function in PHP to include a UTF file which begins with a BOM it will insert the BOM into your final document. When you copy and paste the text (sans BOM) into the main document then there is no problem. Most browsers ignore the stray BOM in the middle of the HTML document, but IE does not.
You can find reference to the include() UTF issue on the PHP site http://php.net/include/
index.php and indexs.php are not serving the same page. If you copy both of them verbatim with curl and compare them with something (like Beyond Compare) you will see that there are the stray bytes introduced by the PHP include() on line 18 of indexs.php (which I assume is the version that uses the include function).
Some suggested reading:
“The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)”
http://www.joelonsoftware.com/articles/Unicode.html
While I agree with you on that, (and thank you for those links!!), the only reason the BOM was there in the first place was because I used Expression Web Designer &mash; knowing that Microsoft’s only browser can’t deal with BOM, it shouldn’t write the BOM in there at all.
IE should ignore the BOM in the middle (the BOM is intended to be at the beginning of a document), and since it doesn’t ignore it, Expression should know better than to write it.
I still don’t think it’s a fair criticism to make.
Internet Explorer correctly handles pages which start with a UTF BOM, but displays some rendering inconsistencies on pages which contain these BOM characters in the middle of a file. When encountered in the middle of a page these bytes (EF BB BF) should be ignored or treated as an error. While IE doesn’t handle these stray bytes particularly gracefully (it should probably ignore them like FF and Op), they should never be there in the first place.
The PHP include function does not correctly support including UTF files which start with a BOM.
The Expression product does not support PHP. It saves UTF files with a BOM, but that is a perfectly normal thing for an editor to do. UTF files are well within their rights to start with a BOM (although not required).
Expression has no problems with IE. Expression has no problems with UTF. PHP has an issue with UTF, and IE has an issue with PHP’s UTF issue. So Expression PHP IE = problem.
However, Expression simply isn’t intended for editing PHP, as far as I know it has no specific support for it. From your earlier post about Expression:
“If there is one feature that is lacking, it?s Expression?s lack of PHP awareness. ASP is wonderful, but the most popular web language remains PHP, and it get?s annoying to discover that you can?t even see the contents of PHP include() in design mode (Dreamweaver does that OK), and it would be a lot nicer to let it use whatever server-side technology exists on the test server instead of displaying all contents as static HTML.”
Yes, IE should ignore it, but Expression has every right to write BOMs at the beginning of UTF files. It is completely correct behaviour. Wait for PHP’s include to support UTF or stop using Expression for unsupported server side languages.
Fair enough I guess.
Just like to mention though that’s not only PHP – like I stated in this post it happens with SHTML too – something that Expression theoretically does support.
Don’t get me wrong, you’ve read our original (very positive) review on Expression, and here’s our review of IE7 Beta 3, we think they’re both great and a huge step forward, and afterall, they’re not done yet. But it’s just a shame that it has to break on the minute details like this.
I’ve been using expression ctp1 to build a drupal theme, and just as you, it messed things up. After fiddling for a while though, I came to the conclusion that this is PHPs fault. So I upgradded to the latest PHP and not only did the problem stay, now my IIS worker proccesses are crashing every 5 minutes.
PHP is really starting to wear on me… but I like drupal too much to try and use some ASP cms. MS would be nice to give us the option to turn BOM off in expression.
Hi Glenn,
If you need help with IIS you can ask ask away at our forums and we should be able to help 🙂
I have been beta testing the Expression Web Designer for a while now I have to say that I really hate it.
I generally use Adobe/Macromedia Dreamweaver and Front Page 2003 and Expression Web Designer is nothing like either of them to put it in a nice manner.
I removed it from my computer last night having found it to inflexible for my design needs. I would never recommend this web design tool to anyone in it’s current version, and I will not allow anyone on our web development to install it on their computers.
I was very disappointed.
I never tried the Expression Web Designer but until now i didn´t hear much possitive stuff about it.
i work with adobe/macromedia programs too . and this since many years so i think i will stay with them. they are expensive that´s true but every good program is expensive and on my opinion they are definitelly worth it.
Our team has been building with Frontpage 2003.
My previous experiences with Web Designer have not been very good. I am wondering what will happen once Web Designer completely replaces front page as expected. Web Designer is a complicated – uncomplicated piece of software. In other words, it is difficult to figure it out, yet its features are relatively basic for a web design software. Front Page is certainly better in many regards for simplicity as well as it’s features. I especially appreciate the Web Componets of front page which save us a ton of updating time.
I hope M.S. will dramatically upgrade Web Designer so it becomes realistically usable, otherwise I will have to train the team in Dreamweaver.
But CCCI, you do realize that Frontpage creates the world’s most bloated, non-rendering, and highly-broken code?
Expression may not be as advanced of a program (and I agree with you, the interface needs some serious heavy-lifting), but it produces much cleaner code than Dreamweaver or Frontpage….
Dreamweaver really needs a new version. Dreamweaver MX is really old now!
Hi, I’m a Expression novice who is learning as I go. I apologize in advance if this is a stupid question, but I’m hoping you can help me. Some images on my home page are not displaying in IEv6, while they’re fine in IEv7. How can I fix this??
How do you mean by “not displaying?”
Are the missing entirely? Look wrong? Load half-way?
One shows about 1/3 of the image, the other doesn’t display at all. Its like they’re invisible or something, because the ‘placeholders’ are still there.
Sounds like a PC-related issue to me – have you tried running it in IE6 on another PC?
I was having the same problem (or at least a similar one) with server side includes of an htm snippet from Expression Web Designer. I found a reference elsewhere, on someone having a similar problem with Dreamweaver, and they recommended adding:
in the section to address the issue. I did that, and the problem seems to be fixed. It may not be elegant or correct, but seems to work.
ViennaMike,
What was the other reference? What did you add?
Thanks for this info.
I’ve spent hours today trying to get a SSI file to render properly after usign MS Expression Web and it looks to be down to the issue you’ve highlighted.
First time I’ve really used Expression Web in anger and I’ve got to say I’m not very impressed. Much prefer “any other designer/editor” than this piece of MS “software”.
They should have the option of saving to different encoding standards and they should add SSI support into the product!
@Bonfirst
Nothing to do with PHP! My project doesn’t contain any PHP so far and Express Web breaks the SSI webpages just as indicated.
@ViennaMike
What is the recommendation please?
Thanks again.
Some more digging around has revealed this is fixed in V2 of the product!
Would have been good if they issued a fix for V1 as well.