[Bug 23646] "us-ascii" should not be an alias for "windows-1252"


--- Comment #38 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to Jirka Kosek from comment #37)
> So far no one showen where browsers implement us-ascii as an windows-1252
> alias for *encoding*, so to me it seems that change I propose (replace or
> escape characters above U+007F for us-ascii encoding) doesn't change
> anything in browser implementations.

Not so.

The us-ascii label is resolved to the windows-1252 encoding early when loading
a document. The original label isn't around anymore at the time of e.g. form
submission. Therefore, the label mapping for decoding also affects encoding.

At least in Firefox, there is no separate mapping from labels to encodings for
encoding. You can see the mapping that Firefox uses at

> > (In reply to Jirka Kosek from comment #9)
> > > Consider the following example. I have page containing copyright symbol
> > > (U+00A9). I want to save it in "us-ascii" encoding using XHTML syntax of
> > > HTML5.
> > 
> > You want something that's hostile to interop, then. The spec should not
> > accommodate what you want.
> > 
> > In other words, the right solution is to always use UTF-8 when you create
> > XML documents. 
> In ideal world yes, but when you have other constraints and you know that
> receiver can handle us-ascii then why it should be broken?

What "other constraints"?

If you know what the receiver can handle, you don't need specs to bless your
bilateral arrangement.

> I would rather see if browser vendors can prove that changing the current
> definition of us-ascii encoding breaks anything.

No, that's not how this works.

> Please note that the
> Encoding Standard changes how us-ascii encoding behaved in the past, so this
> change must be justified and well reasoned. 

Citation-needed for the Encoding Standard describing a change compared to
pre-Encoding Standard browser behavior.

You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 1 July 2014 10:12:23 UTC