[Bug 9424] Conformance checking of the syntax of <META http-equiv="content-language" content="*">

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9424


Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




--- Comment #7 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-04-14 04:56:14 ---
(In reply to comment #6)

> Status: Rejected
> Change Description: no spec change
> Rationale:
   [...]
> Given that you've said that the proposed syntax does nothing in new browsers,
> the options are:

I have not said this. What it does in new browsers depends on the spec you are
writing. HTML5's doctype is based on how it works in legacy browsers, so this
kind of thinking is not a new thing.

> 1. Proposed syntax does something useful in legacy browsers, but does not in
> new browsers, and there's no better solution: we should change what the spec
> requires of new browsers, then change the authoring requirements to match what
> syntax does something useful in new browsers.

As you know, I have been requiring that new browsers should continute to handle
the empty content-lang the same way as they now does.  This is part of  almost
everything I say. I see nothign useful your solution for the empty
content-language meta. It only creates insecurity and inconsitensy. So, yes
this (1.) is the situation as I see it.

> 2. Proposed syntax does something useful in legacy browsers, but does not in
> new browsers, and there's a better solution: it shouldn't be conforming as it
> is a waste of time (it doesn't work in new browsers).

What is waste of time is the time you spend on forbidding me from making sure
the legacy browsers can live up to future browsers as much as possible.

There is a difference between useless and harmless. That something becomes
harmless in a future browser even if it si useful now, is of cours the
intetion.

I don't really understand wherein the improvement in your solution is. Instead
I see trouble, because you do not allow me to take my measures to be compatible
here and now.

> 3. Proposed syntax does something that is not useful in legacy browsers, and
> does nothing in new browsers: it shouldn't be conforming as it is a waste of
> time (it's not useful).

Indeeed. Ouch.

> As far as I can tell, the content-language pragma does nothing you can't do
> with lang="", and so case #1 doesn't apply. Therefore one of #2 or #3 applies,
> and we shouldn't make it conforming.

Clearly, wer are not at 3. :-) Then we must be at 1. or 2. Or both 1 and 2.

Content-language pragma does one thing which you can't do with lang="": It puts
a border between the document and the HTTP header. This is not something that
lang="" can do. HTTP-equiv is unique in that it has effect on the entire
document, whereas lang="" only works on the element and its children. Of
course, if you place @lang in <html>, then you should be covered.  That @lang,
in a conforming browsers, can override what content-language says, is of course
how it should be. But they are still different things.

In fact, I don't understandd this buisnes with "does not do something that lang
cannot do". Is it your view that we should nto use HTTP content-language
either? It is precisely because I want to be able to use the HTTP
content-language header for its real purpose that I want to avoid that such 
choice affects the document in anyway. The HTTP header should be canceled with
the HTTP-equive content-language elemnt. That is pretty logical.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 14 April 2010 04:56:16 UTC