At 03:50 03/09/19 +0200, Bjoern Hoehrmann wrote:
You want to change something that has been STRONGLY RECOMMENDED for over
five years to (ideally) MUST NOT just because it could cause trouble
when used improperly or with broken implementations. Today I am good
with web standards if I use the charset parameter, tommorow I am bad
with web standards if I do. What's next on #W3C? Use tables for layout
because people could get CSS wrong and old browsers get some CSS wrong?
I don't think this leads anywhere.
The charset parameter is useful if you cannot or do not want to use an
encoding declaration,
Yes. One particular example that came up recently is the case of IE
going into quirks mode when seeing an XML declaration on an XHTML file.
I guess we can assume that those sites serving different content types
based on browser type can somehow set the charset parameter.
for content negotiation, for view source
functionality, if you perform protocol operations that change the
encoding without changing the document or if you have to deal with
legacy applications that could break your document if no charset
parameter is present.
I'd also want to mention server technology that links the 'charset'
parameter with the actual encoding. For example, for Java servlets,
saying
resource.setContentType ("type/foo;charset=encoding");
will not only produce the relevant header, it will also make
sure that the right conversion (from the internal UTF-16 to
the specified encoding) happens. It would be a bad idea
to disallow this because it works.
I admit that there is probably no strong enough
use case to introduce it, but we have the parameter already and it has
been STRONGLY RECOMMENDED for ages across various W3C technologies.
I can live with removing the STRONGLY RECOMMENDED status and an
informative note that you typically do not need to specifiy the
charset parameter but anything beyond that goes much too far.
I quite agree with this statement.
Regards, Martin.
>To put it another way, quoting Larry Wall: "An XML document knows what
>encoding it's in."
<http://www.w3.org/People/Bos/DesignGuide/stability>:
...
Having to re-learn how to do something is costly, creating new
programs to do the same thing in a different way is costly, and
converting existing documents and other resources to a different
format is also costly, so changes with little or no benefit should
be avoided.
...