This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Spec currently says ]] Note: Conformance checkers will include a warning if this pragma is used. Authors are encouraged to use the lang attribute instead. [[ These changes are proposed: (1) For using inccorrect syntax (See bug 9420 w.r.t. the suggest syntax): ERROR MESSAGE: An error message is due if the syntax rules are broken. (bug 9420) WARNING: But even if the syntax rules are broken, there is no need for a error message unless they are broken in the *last* occuring META content-langauge declaration. This is because only the last occuring META content-language is active. User agents are only meant to react to the last occuring element. Hence, in this case, only display a warning. An important reason to, in this case, only display a warning, is documented in bug 9422. (2) For the very use of the <meta> content-language element. (Breakage of the syntax rules should be checked separately - see above.) Currently the spec request a warning to be displayed merely for the very use of the META content-language element. At the moment, I am OK with this. A separate bug will eventually be filed for this.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I have no idea what this means.
Since I filed this bug, you have made it illegal to have duplicate META elements. But that is not a justification for saying that you don't understand. The essense of this bug report is that the validator only give such error messages that are relevant. And I have outlined what I think those messages are.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: I really have no idea what you're talking about. The spec has restricted duplicate pragmas for literally years, that's not new. I don't understand any of the rest of this bug; I really have no idea what you want or what the problem is. If you could succinctly describe (in two lines, say) what the problem is, that would be most helpful.
in bug 9409, you said: ]] There is minimal content using this so it doesn't much matter if we change the way duplicates are handled. (They're invalid now anyway.) [[ And I interpreted the "now" to refer to a recent change - which I interpreted as relateding to content-langaue as well. (I also spent time locating the place in the text where this is said - it is said in tail sentence at the end of the pragma directive section.) It appears after the 'default-style' subsections, but I cannot see any other place were it is said that more than one is forbidden. http://dev.w3.org/html5/spec/semantics.html#pragma-directives Further more, the Valditor.nu has "literally for years" not implemented anything that says that two META content-language elements are forbidden. Finally, I have - if you read my messages and bug reports - many times spoked about this issue - first and last etc META element. So it is strange that this comes as a "shock" to you. Thuys I have nothing but your words for the claim that the spec forbids more than one META content-language element. I will provide your requested "two lines" in my next reply.
The point with this bug is to draw a distinctinon between what kind of syntax that should trigger conformance errors, and what syntax that should have an effect on user agents. The purpose of allowing a wider set of syntax than exactly that syntax which has an effect on future (HTML5) browsers, is to accomodate for legacy user agents. (Another use case could be CMS-es, but let's focus on user agents.)
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: So you're saying that you want the spec to allow syntax which is intended to not do anything, because it does something in some legacy browsers? Surely if it does something _useful_ in legacy browsers, which can't be done in some other way, we would want to make future browsers do it too. On the other hand, if what it does in legacy browsers isn't useful or can be done in another way, then there's no reason to do it in legacy browsers. Either way, it seems like the logical conclusion is that there's no point having the conformance requirements for authors allow something that is a superset of what user agents are going to support. Or to put it another way: Given that you've said that the proposed syntax does nothing in new browsers, the options are: 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. 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). 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). 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.
(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.
> 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. Sure it can. You just set it on the root element, and the HTTP header is then ignored. (This is buggy in some UAs in the one case of setting the default language to the unknown tag, but this is such a rare case that it really isn't worth worrying about.) > HTTP-equiv is unique in that it has effect on the entire > document, whereas lang="" only works on the element and its children. The root element encompasses the entire document, so there's no practical difference. > 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. Not in any interesting way. > 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? HTTP Content-Language has nothing to do with any of this. It is defined as setting the default target audience language. It doesn't say what language the document is in. It isn't relevant here. Some browsers misinterpret it, but that's an issue for the HTTP working group, not for HTML. > 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. If there's a bug in browsers, please deal with it by having the bug fixed, not by making HTML more complicated. > The HTTP header should be canceled with > the HTTP-equive content-language elemnt. That is pretty logical. It's also cancelled by setting lang="" on the root element. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have *ADDITIONAL INFORMATION* and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: There hasn't been new information added since the last time this was rejected.