- From: Aharon (Vladimir) Lanin <aharon@google.com>
- Date: Thu, 7 Jun 2012 12:50:20 +0200
- To: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Web Notification WG <public-web-notification@w3.org>, Ian Hickson <ian@hixie.ch>, ML publc-i18n-bidi <public-i18n-bidi@w3.org>
- Message-ID: <CA+FsOYbk03YTQdpy7UCKrqPaTYSt6bAXQ_X5pfbR--DWX60-Ww@mail.gmail.com>
I think that what you have is nearly there. It is very nice to have a separate title and body direction. I think that the oddities that Kenny is commenting on are due to the fact that while the body is allowed to have more than one paragraph, a title seems to be assumed to have just one. This may be a holdover from when (if I remember correctly) the spec used to explicitly prohibit the title from containing newlines (which, if broadened to the rest of the bidi class B characters, e.g. PARAGRAPH SEPARATOR, would prevent the title from containing more than one paragraph). If you are going to allow a title to contain newlines, though, you have no choice but to allow it to contain a sequence of paragraphs, and thus you need the exact same verbiage for the title as for the body. I think that this would actually simplify the Rendering section's prose. It could go something like this: User agents are expected to honor the Unicode semantics of the text of a notification's title and body. Each is expected to be treated as an independent set of one or more bidirectional algorithm paragraphs when displayed, as defined by the bidirectional algorithm's rules P1, P2, and P3, including, for instance, supporting the paragraph-breaking behaviour of U+000A LINE FEED (LF) characters. For each paragraph of the title and body, the notification's title or body direction provides the higher-level override of rules P2 and P3 if it has a value other than "auto". [BIDI] Aharon On Thu, Jun 7, 2012 at 12:17 PM, Kang-Hao (Kenny) Lu < kennyluck@csail.mit.edu> wrote: > (Cc+ public-i18n-bidi) > > (12/06/07 16:08), Anne van Kesteren wrote: > > Sorry to bother you again. By studying the text in HTML I have tried > > to define something reasonable for BIDI in > > http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html#rendering > > but it feels somewhat shaky. If you could take another look and > > provide some guidance that would be appreciated. > > Some feedback: > > 1. The prose is logically correct but it specifically talks about the > details of P2 for the directionality (by the way, I think the exact term > is "base direction" or "paragraph direction") of the title *only* but > not for the body, which seems a bit weird. > > I think Aharon's wording > > (12/05/01 17:22), Aharon (Vladimir) Lanin wrote: > > "If the notification's dir attribute is auto, its title and body must > > be split into paragraphs and the directionality of each paragraph > > determined from its content independently of the others as specified > > by the Unicode bidirectional algorithm's rule P1, P2, and P3." > > has the extra benefit that it doesn't use the hidden assumption that a > UA only shows a single paragraph of the title of a notification. > > 2. The prose > > # The higher-level override of rules P2 and P3 is provided by a > # notification's body direction, when that is not "auto". > > can be clarified to > > | The higher-level override of rules P2 and P3 is provided by a > | notification's body direction, when that is not "auto", so that the > | base direction of each paragraph is the notification's body > | direction. > > to prevent the misinterpretation that the body direction only applies to > the first paragraph. (But admittedly this misinterpretation is a bit > hypothetical. For reference, css3-writing-modes uses > > [[ > (definition of a paragraph) > > The paragraph embedding level is set according to the value of the > ‘direction’ property of the paragraph's element rather than by the > heuristic given in steps P2 and P3 of the Unicode algorithm. > ]] > > ) > > 3. The sentence "including, for instance, supporting the > paragraph-breaking behaviour of U+000A LINE FEED (LF) characters" calls > out LF but not other characters such as U+2029 PARAGRAPH SEPARATOR. > > This is a minor thing though, and I notice that this sentence comes from > the HTML spec. > > > Cheers, > Kenny >
Received on Thursday, 7 June 2012 10:51:26 UTC