Re: Strange advice re BOM and UTF-8

But we aren't talking about conforming software, we're talking about a 
validator warning which points out that in the real world, many common 
editors used to alter web content will render BOM as < i ? (whatever).

When this happens, since the very very first thing in the file is NOT a 
DOCTYPE declaration, MSIE < 7 will automatically (and stupidly) use quirks 
mode to render the page, because of those three little characters non-
compliant software has ignored, which can break an entire site even if they 
are not visible.

For widest compatibility, avoiding the BOM is a "best practice" and I'm in 
favor of not removing best-practice, real-world tips from the validator on 
the basis of "applications ought to know better," because they do not.

Don't even get me <i<b>started</b<span>on</span></i> things the validator 
*should* flag because of how real-world developers *use* it (quality control) 
instead of rigid adherence to SGML, but that's just my opinion.  :-)

-Eric

>
>"Multiple BOMs" is not an error, and doesn't even exist. The character 
>U+FEFF is to be interpreted as BOM only at the start of a file or data 
>stream. Otherwise, it has the semantics suggested by its Unicode name, 
>ZERO-WIDTH NO-BREAK SPACE. Such usage is not recommended in the standard; 
>we are supposed to use U+2060 WORD JOINER instead. (Here on Earth, 
>however, U+FEFF seems to be better supported than U+2060.) Yet, such usage 
>is standards-conforming, and conforming software must not simply remove 
>"the second BOM" when it gets data that starts with U+FEFF U+FEFF. (It 
>may make an informed decision to ignore the latter code point but only 
>because it decides to ignore a leading zero-width no-break space.)
>
>Of course, generating several U+FEFF at the start of a file is a bad idea 
>and may confuse software that purports to support Unicode but doesn't.
>
>-- 
>Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
>
>
>

Received on Wednesday, 6 December 2006 17:10:50 UTC