- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Fri, 2 Sep 2011 22:08:15 +0200
- To: Richard Ishida <ishida@w3.org>
- Cc: www International <www-international@w3.org>
Richard Ishida, Fri, 02 Sep 2011 14:52:01 +0100:
> On 22/08/2011 21:34, Leif Halvard Silli wrote:
>> Here is my long review of the 4th document: [...]
>> [ Review comment 1: ]
>>
>> ]] HTTP and meta for language information [[
>> The subsequent question doesn't make it any clearer:
>>
>> ]] what are HTTP and meta language declarations for [[ [...]
> Hmm. I'm not convinced. You suggestions don't actually say what I
> intend (eg. there's no versus implied), and i'm not particularly
> worried that the title is vague. I'm going to punt on this.
This may not sound any more convincing … But the title can be read as
"HTTP for language info & meta for language info". If that is what is
meant, then it should be expressed clearer - e.g.: "Use of HTTP and the
meta element for language information" would be clearer.
As for the question, then it can be read as "What are HTTP for and what
are meta language declarations for." The question is meant to narrow
down what the title means, no? But its first part - what are HTTP for -
instead widens it. …
>> [ Review comment 3: ] The 'quick answer' section
>> Regarding this:
>>
>> ]] The Content-Language value on a meta element should no longer be
>> used. You should use a language attribute on the html tag to declare
>> the primary language of the text in the page.[[
>>
>> * The phrase "should no longer be used" hangs in the air. It is HTML5
>> which forbids it - so this should be said.
>> * Also, the second sentence makes it seem as if the purpose of this
>> article is not to explain what HTTP Content-Header: is for but rather
>> to clear explain the status of the META element: use @lang instead.
>
> The purpose of the article is to explain what *both* http header and
> meta element are for and how to use them (see the question).
>
> What goes for HTML5 is supposed to inform how other flavours of HTML
> are used going forward. Just because you can use the meta element
> with html4 doesn't make it a good idea to do so, for the same reasons
> as it was dropped from HTML5.
You say 'purpose … is to explain what *both* … are for'. The original
purpose of both are the same, no? (Remember that HTML4 includes both
http-equiv=Content-Languague and HTTP Content-Languague:. ) The article
should answer not what their purpose is [this hasn't changed] but what
purpose(s) the should be *used* for [this has changed].
When it comes to HTML5: The article is clearly not negative towards
use of dublin core: <meta name="dc.language" content="en">. I agree
that there can be good reasons to avoid http-equiv=COntent-Language
even in HTML4/XHTML1. As for HTML5, then it isn't really against
dc.language - it just says that it has not been registered.
It is possible to say that HTML5 forbids something and then to add that
HTML5's reason are valid even in HTML4.
>> [ Review comment 5: ] #metadata section
>>
>> I miss a perspective here: A document might be intended for an audience
>> which actually do not consider themselves to use the language of the
>> article. [ snip ]
> I'm not sure i understand your point, but we're talking about
> metadata here, so if you know that your audience is targeted at
> specific language communities you can list them all in the HTTP
> header. (The lang attribute has no relevance here, of course.)
You make a good point, of course: if it is targeted at both an audience
of Bokmål and the Nynorsk users only, then the solution would be to say
Content-Langauge:nn,nb. However, my reaction was triggered by the
section's first sentence:
]] Metadata that describes _the_language_ of the intended audience is
about the document as a whole. [[
May I suggest that - instead of 'the langauge', you say 'the languages'
or eventuially 'the langauges - or language' ? Like so:
""" Metadata that describes the languages - or language, of the
intended audience is about the document as a whole. """
Perhaps even 'audiences' should be plural? Or perhaps the audience is
always singular: One audience, which can be enlarged or shrinked
through a) omitting Content-Language completel versus b) adding one or
more language tags to Content-Language.
And btw: What if the page is aimed at the entire world - or just the
entire country, regardless of user's language? As far as I remember,
there are one or more tags which indicate 'any langauge'. However, I
think it is more compatible to leave out Content-Langauge in such
situations. Could you add a note about that too - that there are
occations when it is better to not use Content-Langauge?
PS: An example you perhaps would like to consider somewhere in the
article: http://www.icab.de contains both English and German text - you
will see this if you disable JavaScript in your browser.
>> [ Review comment 7: ] #meta section 'Content-Language on the meta
>> element'
>> * Given that it is not recommended [in HTML5], it woud be good to
>> draw attention to this.
>> * You touch the subject of, to which degree, browser are using the
>> META element to determine the text processiong lanuage. However, I
>> suggest hthat you take that subject *out* of this section (and out of
>> the #http section as well) and instead place it in a separate section
>> called "Other effects of the Content-Language: header' or something
>> like. Because, the thing is that Content-Language: is used by browsers
>> regardless of whether it comes from HTTP or from http-equiv. Well,
>> http-equiv is used to a larger degree, but nevertheless: it would be
>> more fitting to treat this subject at one place, I think.
>
> I'm only making that point to clarify the history related to the meta
> element. Otherwise it's not actually relevant, since we are telling
> people to use the lang/xml:lang attribute rather than rely on what
> the browsers do with meta/http.
Well, by placing it in a separat section, you could instead focus on
the real purpose. As it is, I feel there is too much repetiation of the
same point - from different angles.
>> * You claim that HTML5 "make a concession for backwards
>> compatibility".
[ ... ]
> As I understand it, the only reason that fallback mechanism was left
> in the spec was as a means of dealing with legacy pages that don't
> use the [lang] attribute - which is a concession. No one should be relying
> on the use of the fallback mechanism in the future - they should be
> using the [lang] attribute.
We can of course say about part of HTML5 that was put there in order to
be compatible with something that it was important to be compatible
with, is a concession. But I don't think it is very useful. The first
meaning of 'concession' according to dictonary.com:
]] the act of conceding or yielding, as a right, a privilege, or a
point or fact in an argument: [...] [[
Thus 'concession' is word that would fit well - for instance when
describing why certain XHTML syntaxes (such as xml:lang and
xmlns="http://www.w3.org/1999/xhtml" ) are permitted in HTML5
documents. In short: 'concession' is nice for describing authoring
conformance rules, when these rules really are based on concessions.
So, for instance, HTML5's *previous* permission to use <meta
http-equiv="Contet-Langiuage" content="a-sing-language-tag">, *that*
was a concession.
To whom, eventually, is HTML5's user agent treatment of
@http-equiv=content-language a concession? HTML5 has been defined as
backward-comaptible. So the entire HTMl5 is a concession ...
May be you could use another word than 'concession' - which is a word
that brings one's thoughts towards 'conformance' - and since it isn't
conforming? And/Or at least make the point clearer that this
compatibility adaption is related to the HTML parser - only
(http://dev.w3.org/html5/spec/parsing#html-parser) and not to the HTML
syntax ? (Including the wording 'HTML parser' with a link to the spec,
could be a good idea.)
>> [ Review comment 8: ] #http Content-Language in an HTTP header
>>
>> * Move this section before the META element.
>> * Point out that this is recommended over using META
>> * Please let the title say:
>> '[Setting] Content-Language using a HTTP header'
>> * Like I said above: please move the fallback features (the "when no
>> other langauge info is present" issues) to a separate section.
>
> See the comments above.
ditto ;-)
>> [ Review comment 9: ] Describe the advantages of real HTTP
>> Content-Language: headers (over meta element variant)
>>
>> * I consider that the purpose of the article should be to give info
>> about the purpose of the Content-Language: header rather than dwelling
>> with side effects of the http-equiv variant.
>
> That was not the intention of the article.
So you wanted the article dwell with side effects of http-equiv (and
http too)? My suggestion(s) above was to move those side-effects into
a separate section of the article. But OK, I have made my point.
--
Leif H Silli
Received on Friday, 2 September 2011 20:08:46 UTC