W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-text] I18N-ISSUE-337: line terminator handling

From: John C Klensin <john+w3c@jck.com>
Date: Thu, 31 Jul 2014 10:27:05 -0400
To: CSS WWW Style <www-style@w3.org>, www International <www-international@w3.org>
Message-ID: <64C68F9E7F9AF5C4437F1F6D@JcK-HP8200.jck.com>
Hi.  Posting this for the file -- I have no further objections
to this issue being closed.  I do think it would be advantageous
to consider the small technical/editorial issue mentioned under
(i) below if it has not been considered, but do not consider it
very important.



> https://www.w3.org/International/track/issues/337 

Two (contradictory) answers:

(1) I'm pretty sure that I understood the CSS text when I read
it in January.   Given the amount of trouble being agnostic on
the line-end convention has caused, I found the text profoundly
unsatisfying then and find it profoundly unsatisfying now.  

(2) I am now clear that the CSS group has no intention of
changing the present situation and apparently likes it that way.
While I will continue to disagree, I am satisfied that the text
is adequately clear about that position.

Two observations (not further complaints or justification for
leaving this open unless others agree):

(i) Unless there is general consensus that Unicode's attempt to
introduce an unambiguous Line Separator in form of U+2028 has
been a complete failure, I suppose the CSS document would be
better off either including it as an additional alternative (to
"... document languageā€“defined segment break, CRLF sequence
(U+000D U+000A), carriage return (U+000D), and line feed
(U+000A)...") or mentioning why it is not so included.

(ii) I believe that the Unicode Standard discussion of "NLF"
represents a better approach than the indifference ("does not
define...") expressed in the CSS spec.  I.e., one should be
permissive in what is accepted but should canonicalize all of
them
to a single preferred form.  But that obviously isn't the way
the spec if going.

   john
Received on Thursday, 31 July 2014 14:36:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC