RE: word-break:keep-words

芦村さん、詳細なご説明をありがとうございます。少し理解できました。

ご説明からするとat-riskでもよさそうですが、この場合、at-riskのままでも仕様の文面としては「単語」なのか「文節」なのかなどを煮詰めねばならず、それが困難なため、協議の結果、仕様[1]に以下の文面を追加しました。

> This value is likely to be dropped before CR unless there is interest from implementers.

[1] http://dev.w3.org/csswg/css3-text/#word-break

-----Original Message-----
From: Kazuyuki Ashimura [mailto:ashimura@w3.org] 
Sent: Monday, February 21, 2011 12:33 AM
To: Koji Ishii
Cc: public-html-ig-jp@w3.org
Subject: Re: word-break:keep-words

石井様，皆様，

W3C/慶應の芦村です．

お世話になっております．

W3Cの仕様策定手続きについて，簡単に補足したく存じます．

1. Candidate Recommendationにおける実装依頼
-----------------------------------------

W3Cプロセスドキュメント [1] およびW3Cパブリケーションルール [2] にござ
います通り，仕様書をCandidate Recommendation(CR)として公開する際には，
以下の二つの形で，W3C会員および公開メーリングリスト参加者(等)の皆さん
へ，仕様実装をお願いいたします．

- 「Call for Implementation(CfI)」(仕様実装のお願い)をW3C会員の皆さん
  (具体的には各会員企業のAC Rep.の皆さん)へ送付

- 「Transition Announcement(TA)」(仕様がCRになったお知らせ)を，非会員も
  含む，当該WG公開メーリングリスト(および関係各位)へ送付

2. 実装困難な機能に対する扱い (Features at risk)
---------------------------------------------

通常，当該仕様の相互運用性を確保するために，CR中にて，「各機能について
実装が二つ以上得られること」をProposed Recommendation(PR)への移行の条件
とすることが多く，十分な実装が得られない場合は，当該機能を削除する必要
が生じます．当該機能の削除(および，使用中の他の部分への影響)が
「Substantive(本質的)」と考えられる場合は，編集を加えた後，再度Last
Call Working Draftとして公開する必要があります．

ただし，CR公開に先立って，実装が困難な機能が想定されている場合には，CR
仕様書および上記のCfI, TAにて，その機能(=実装できない危険性のある機能)
を「Features at risk」として明記しておくことにより，当該機能の実装が得
られなかった場合でも，CRからその機能を削除した上でPRへ移行することが可
能です．

なお，その際には，仕様策定に取り組むWorking Group内で議論の上で，上記し
ました通り，「CR仕様書，CfIおよびTA」にて，「どの機能をFeatures at
riskとするか」を明記しておく必要があります．

Features at risk記述の例(InkML):
http://www.w3.org/TR/InkML/#status

[1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
[2] http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=cr-tr
[3] http://www.w3.org/2005/10/Process-20051014/tr.html#return-to-wg

ご参考まで．

Kazuyuki


On 02/19/2011 11:41 PM, Koji Ishii wrote:
> word-break:keep-words[1]が辞書ベースの単語区切りを日本語や中国語で行い、単語単位で改行を許す、という仕様になっており、これに対して先日オフラインでフィードバックをいただきました。
> 
> Interoperableな実装が望めないのでちょっとリスクがあり、調べたところ、つい一月ほど前に
> * マンガや散文における自動改行[2]をサポートしたい
> * at-risk扱いにするけど、入れておけば何かコメントがもらえるかも[3]
> というコメントと共に追加されていました。
> 
> 私もまだW3Cのプロセスをよく理解していませんが、通常は、仕様に入れてしまってブラウザーベンダーに実装してもらえない機能が見つかると、最初に戻ってやり直し扱いになってしまうのですが、あらかじめ「at-risk」という扱いをしておくと、削除するだけ（変更は不可）ならやり直しにならないような特例があるらしく、その扱いを適用する、ということだと思います。
> 
> ちょっとどういう経過でこの値を入れたのかは私も定かではありませんが、
> * やるにしても「単語単位」は間違いで、せめて「文節単位」
> * Interoperableな実装は望めないのでそもそも難しい
> ので、特例扱いだとしても入れて議論する価値をあまり見出せませんが、コメントが欲しいようなので、ご意見いただけると幸いです。
> 
> [1] http://dev.w3.org/csswg/css3-text/#word-break
> [2] http://littlepotato.webfreehosting.net/cjk-beyond-kinsokushori.php
> [3] http://lists.w3.org/Archives/Public/public-css-commits/2011Jan/0017.html
> 
> よろしくお願いいたします。
> 
> 

-- 
Kaz Ashimura <ashimura@w3.org> http://www.w3.org/People/all#ashimura 
Tel:                                                 +81 466 49 1170

Received on Wednesday, 23 February 2011 19:43:30 UTC