Null change proposal for ISSUE-88 (mark II)

ISSUE-88
========

SUMMARY
There is no problem and the proposed remedy is to change nothing.

RATIONALE
There is no problem.


Another change proposal suggests adding a note on the basis that we should 
clarify why the HTTP and pragma declarations are different when it comes 
to values, and how they should be used, suggesting that this is a constant 
source of confusion.

However, no evidence has been provided to suggest that this really is a 
source of confusion.

Furthermore, the suggested note is wrong in practice. The pragma doesn't 
give metadata about the document. The original intent of the <meta 
http-equiv> feature was to provide a way for _servers_ to include data in 
their HTTP headers on a per-file basis; this isn't document-wide metadata 
for user agents, it's for servers. This original intent also doesn't match 
reality; reality is that this pragma sets the default language for 
lang="", which also isn't document-wide metadata for user agents.

Finally, the proffered note does not actually match the associated 
rationale: it doesn't explain why the HTTP and pragma declaration syntaxes 
are different; instead it talks about a "language" attribute.

If there is a "constant source of confusion", then what we need is 
pointers to this confusion, so that text intended specifically to address 
that confusion is included in the spec. It is quite possible that we could 
add lots of explanatory text and explain the situation in detail, but to 
do so we need to know what the confusion is about. As far as I am aware, 
no bug pointing to confusion on this subject and asking for clarification 
has been rejected, which makes using the change proposal process 
inappropriate.


The same change proposal also suggests a second change, namely to change 
the syntax to allow multiple comma-separated language codes, even though 
all but the first would be ignored.

User agents do not pay any attention to values after the first. The way to 
mark that a document _uses_ multiple languages in such a way that user 
agents can actually parse and find this information is to use the lang="" 
attribute in the document. Putting multiple values in the pragma would 
fail to handle this according to the proposal.

Another possible use case would be to to have a standard way to say who 
the target audience of the document is, but in practice few people use 
that information on the Web, so it doesn't seem like having a pragma that 
exposes this information would be useful, even if we ignore that the user 
agents are currently required to ignore that information.

Even if there was such a need, this feature would be a bad way to provide 
that information, since it is used in an incompatible way by user agents 
(the first language, and only the first language, is used to determine 
processing behaviour -- none of the languages are treated as a target 
audience language hint). For controlled environments, there are a 
multitude of options available to authors, such as the HTTP header of the 
same name, <meta name> with custom names, microdata, RDFa, out-of-band 
data, <script> blocks, etc. We don't need to use this mechanism for that 
purpose. Doing so would just confuse authors further.

No rationale is given for this second change, so it is hard to evaluate 
what the benefit of making this change would be.


Finally, it should be noted that the aforementioned other change proposal 
is self-contradictory. Making the second change (thus making the syntax 
of the pragma the same as its HTTP namesake) would make the rationale for 
the first change (that we should explain the differences between the 
syntax of the pragma and the HTTP header) incorrect.


DETAILS
Change nothing.

IMPACT

POSITIVE EFFECTS
* Ensures consistency with current implementation usage of the content 
attribute in the Content Language pragma and with earlier specifications.

NEGATIVE EFFECTS
None.

CONFORMANCE CLASS CHANGES
None.

RISKS
It's possible that there is confusion. However, it is easy to handle this 
at a future date when clear evidence of such confusion is found.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 2 April 2010 18:54:54 UTC