W3C home > Mailing lists > Public > www-international@w3.org > January to March 2010

RE: For review: Character encodings in HTML and CSS

From: CE Whitehead <cewcathar@hotmail.com>
Date: Thu, 11 Feb 2010 21:28:31 -0500
Message-ID: <BLU109-W14DE76C9760F9EF6875A3BB34D0@phx.gbl>
To: <www-international@w3.org>, <ishida@w3.org>

Hi--
I read a bit more through the draft; one proofreading comment I had seemed pretty important; the rest will have to wait till hopefully sometime tomorrow!


Richard Ishida scripsit:

> Comments are being sought on this article prior to final release. Please
> send any comments to this list (www-international@w3.org). We expect
> to publish a final version in one to two weeks.

http://www.w3.org/International/tutorials/tutorial-char-enc/temp#Slide0100

{I'm using the same key as before so !!! means it needs fixing for sure in my opinion.|




* * *
!!!
"Pros and cons of using the HTTP header for encoding declarations:  Advantages"  first bullet
"The HTTP header information has the highest priority in case of conflict, so this approach should be used by intermediate servers that transcode the data (ie. convert to a different encoding). This is sometimes done for small devices that only recognize a small number of encodings. Because the HTTP header information has precedence over any in-document declaration, it doesn't matter that transcoders typically do not change the internal encoding declarations, just the document encoding."
 
{ COMMENT:  confusing; the above paragraph is not that clear . . . at first read.

1rst, a minor problem--what is "this approach" is referring to; 'approach' should not refer to the 'header' but the method but the immediate antecedent here is the header itself . . . however I gather 'approach' is referring back to the method identified in the heading above the bullet--so o.k.; 
but all the same, you could change 'this approach' to 'the HTTP header' redundant as that sounds and no one has to look for the antecedent; 
also I'd like to start this sentence with the info about conflict;
but what is really important is:
all the information about transcoding -- except the term itself -- should be parenthetical I think because it is extraneous stuff . . .  ;
{ COMMENT what do I do with ie.  John says i.e. and I think so too; ie for me is internet explorer }
=>
"In case of conflict between internal encoding declarations and the header, the HTTP header gets priority.  Thus the HTTP approach should be used by intermediate servers that transcode data (ie. convert to a different encoding; transcoding is sometimes done for small devices that only recognize a small number of encodings). Because the HTTP header information has precedence over any in-document declaration, it doesn't matter that transcoders typically do not change the internal encoding declarations, just the document encoding."
* * *
!!!
"Pros and cons of using the HTTP header for encoding declarations:  Disadvantages" last par

"(Some people would argue that it is rarely appropriate to declare the encoding in the HTTP header if you are going to repeat it in the content of the document. In this case, they are proposing that the HTTP header say nothing about the document encoding. Note that this would usually mean taking action to disable any server defaults.)"

{ COMMENT:  subject-verb agreement
the HTTP header says; it does not say;  
again I might have a stylistic comment about the note format here;
some places it is in parens and some not; perhaps you should remove the parens here and all will be fine!}
=>

"(Some people would argue that it is rarely appropriate to declare the encoding in the HTTP header if you are going to repeat it in the content of the document. In this case, they are proposing that the HTTP header says nothing about the document encoding. Note that this would usually mean taking action to disable any server defaults.)"

{And as noted, maybe remove the parens}
* * *
 
Best,
 
C. E. Whitehead
cewcathar@hotmail.com


 		 	   		  
Received on Friday, 12 February 2010 02:29:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 12 February 2010 02:29:05 GMT