- From: <ishida@w3.org>
- Date: Wed, 3 Aug 2016 14:44:24 +0100
- To: Matitiahu Allouche <matitiahu.allouche@gmail.com>, public-i18n-core@w3.org
hi Mati, thanks for the comments. See below... On 31/07/2016 08:58, Matitiahu Allouche wrote: > Hello, Richard! > > I have looked at sections 3.2 and 5 of the bp-i18n-specdev document and I have the following comments. > > 1) In section 5.2.4, we find: "They are invisible in most editors and are therefore difficult to work with, and can easily lead to orphans and overlapping ranges." > I think this is not strictly correct. Since each CC such as LRE/RLE or LRI/RLI starts a new embedding level, there cannot be overlapping ranges other than total inclusion, which in itself is not an error. But you could end up with "text LRI more text RLE more text PDI more text PDF". And in HTML, because of a clause that the editor put in which says that implicit closing of LRI/RLI by PDF is not allowed, you could also end up with the inverse. One additional way this overlap could occur would be if part of the logic is in markup and part in stray CCs. (see https://github.com/whatwg/html/issues/709) Do you agree? > 2) Ibidem, we find: "Processors that extract parts of the data, add to it, or reuse in combination with other text it may incorrectly handle the control codes." > Editorial: "it may" => "may" fixed > This argument is not really a con for CCs, since the same can be said of markup. > The same is true for the next argument: "Search and comparison algorithms should ignore these characters, but typically don't." > So maybe you should keep these arguments but note that although the same caveats hold for markup, implementers might support included markup better than included CCs. added > 3) In 5.2.6, "guarrantee" => "guarantee" fixed > 4) In 5.4, we find "It must be possible to also set the direction for content fragments to auto. This means that the base direction will be determined by examining the content itself." and a whole discussion after it. > However section 5.5 seems to generalize the same concepts. I suggest to merge the 2 sections. > > 5) There is quite some overlapping between section 4.2 "Setting text direction" and section 5 "Handling text direction". I suggest considering merging them. yes, the overlaps were due to the drafty state of the document. I have now removed the duplication. thanks, see the updates at http://w3c.github.io/bp-i18n-specdev/index_bidi#text_direction ri
Received on Wednesday, 3 August 2016 13:44:42 UTC