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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23646

--- Comment #39 from Jirka Kosek <jirka@kosek.cz> ---
(In reply to Henri Sivonen from comment #38)
> 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.

But are there any pages using us-ascii encoding in a wild? If no, then there is
no problem with having different aliases for decoding/encoding.

> > 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"?

For example 15 years old POS terminal with no UTF-8 support.

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

If I'm asking encoder to produce us-ascii output I'm not expecting getting
bytes with value larger then 127 in my output. 

> > 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.

I think that definition of US-ASCII is pretty clear, it's 7-bit encoding. I'm
talking about us-ascii in general not only in browsers because the Encoding
Standard seems to apply to everything, not only to browsers. If the scope is
narrowed to browsers only, then do as you wish. But it would be silly to have
two different definitions of us-ascii -- one for browsers and second for other
environments.

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

Received on Tuesday, 1 July 2014 10:32:22 UTC