Re: For review: The byte-order mark (BOM) in HTML

On 12/20/2012 3:53 AM, Leif Halvard Silli wrote:
> How about being consistent about writing
>
>  byte order mark
>
> and not
>
>  byte-order mark
>
> since the former is the official form?

And not to forget,  BYTE ORDER MARK, when indicating the formal identifier.

A./

> Leif Halvard Silli
>
> Richard Ishida, Thu, 20 Dec 2012 10:16:25 +0000:
>> On 18/12/2012 22:57, Asmus Freytag wrote:
>>> The text says
>>>
>>>
>>>            What is a byte-order mark?
>>>            
>>>
> <http://www.w3.org/International/questions/new/qa-byte-order-mark-new.en.php#bomwhat>
>>>      At the beginning of a page that uses a Unicode
>>>      
>>>
> <http://www.w3.org/International/articles/definitions-characters/Overview#unicode>
>>>      character encoding
>>>      
>>>
> <http://www.w3.org/International/articles/definitions-characters/Overview#charsets>
>>>      you may find some bytes that represent the Unicode code point U+FEFF
>>>      ZERO WIDTH NO-BREAK SPACE (ZWNBSP). This combination of bytes is
>>>      known as a byte-order mark (BOM).
>>>
>>>      The BOM, when correctly used, is invisible.
>>>
>>> For a while now, there's been a formal name alias defined for the Byte
>>> order mark, Actually two, if you count the abbreviation. (See:
>>> http://www.unicode.org/Public/UNIDATA/NameAliases.txt)
>>>
>>> FEFF;BYTE ORDER MARK;alternate
>>> FEFF;BOM;abbreviation
>>>
>>> Section 4.8 of the Unicode Standard explains that these aliases are
>>> designed (like the original character names) to be used as identifiers
>>> (e.g. in specifications, regular expressions etc.).
>>>
>>> With the introduction of U+2060 WORD JOINER, there's no longer a need to
>>> ever use FEFF for its ZWNSP effect, so from that point on, and with the
>>> availability of a formal alias, the name ZERO WIDTH NO-BREAK SPACE just
>>> represents baggage.
>>>
>>> I recommend that the original name, if mentioned, be relegated to the
>>> status of a historical footnote.
>> Sounds good to me.
>>
>> RI
>>
>>
>>> A./
>

Received on Thursday, 20 December 2012 15:26:34 UTC