Re: Notifications meetup outcome

>  We discussed directionality and the outcome was to "ltr", "rtl", and
"auto", defaulting to "auto", behaving the same as in HTML, but no
inheritance

Unfortunately, 'behaving the same as in HTML' is ambiguous, and in fact is
likely to be understood inappropriately as referring to HTML's dir
attribute and its "auto" value, as these are defined for most HTML
elements. I say that it is inappropriate because HTML is (obviously enough)
a markup language. The title and body of a notification, on the other hand,
as far as I understand from
http://dev.w3.org/2006/webapi/WebNotifications/publish/Notifications.html, are
plain text.

HTML's dir attribute, including dir="auto", was designed under the
assumption that the stuff inside an element is free to have mark-up of its
own. Thus, if I have an element that contains three paragraphs, let's say
represented by three children <p> elements, where each paragraph contains
text in a different language, and thus possibly of a different
directionality, each paragraph is expected to use the dir attribute as
appropriate to state its directionality. The same assumption was used when
defining dir="auto". It means that the element has a directionality, but
the document author is not sure what it is, and it thus needs to be guessed
from the element's content. Nevertheless, the assumption, as usual, is that
the element as a whole has a single directionality - and this
directionality is inherited by descendants, unless they have a dir
attribute of their own. If the element with dir=auto contains a part whose
directionality is independent of the rest, that part - a descendant element
- is expected to say so by having its own dir attribute - even if it's a
dir="auto" of its own. If, in the example above, the document author does
not know the language in which any of the three <p> elements is written,
but does know that each may be in a different language, then putting a
single dir="auto" on the <div> does not suffice: it effectively applies the
directionality of the first <p>'s content to all three <p>s. The author is
instead expected to give each of the <p>'s a dir="auto" of its own.

In plain text, however, there is no mark-up that makes it easy to indicate
the separate directionality of sub-parts. For this reason, the Unicode Bidi
Algorithm rules P1, P2, and P3 (
http://unicode.org/reports/tr9/#The_Paragraph_Level) state that (unless a
higher-level protocol like HTML says otherwise) the directionality of *each
paragraph* of plain text needs to be estimated independently from the
paragraph's first character with strong directionality. In a stream of
plain text, paragraph boundaries are indicated by certain characters,
newline being one of them. Thus, left to its own devices, the Unicode Bidi
Algorithm would break up a notification body containing some newlines into
the corresponding number of paragraphs and assign each paragraph its own
directionality based on its first strong character.

The HTML spec acknowledges in two places that this is the appropriate way
to deal with multi-paragraph plain text of unknown directionality. The
first is that it specifies it to be used when dir="auto" appears on the two
elements that either can't or are not expected to contain mark-up, but are
expected to contain muliple paragraphs of plain text: <textarea> and <pre>.
(Well, actually, it does not specify it directly, but it does specify that
by default <textarea dir="auto"> and <pre dir="auto"> should have
unicode-bidi:plaintext, and unicode-bidi:plaintext just translates the
per-paragraph first-strong directionality guessing algorithm into CSS
concepts.) The second place where the HTML spec acknowledges this as the
right way to deal with plain text of unknown directionality is even more to
the point: HTML specifies it directly (
http://dev.w3.org/html5/spec/Overview.html#text-rendered-in-native-user-interfaces)
for the text passed to script functions like alert():

"A string provided by a script (e.g. the argument to window.alert()) is
expected to be treated as an independent set of one or more bidirectional
algorithm paragraphs when displayed, as defined by the bidirectional
algorithm, including, for instance, supporting the paragraph-breaking
behaviour of U+000A LINE FEED (LF) characters. For the purposes of
determining the paragraph level of such text in the bidirectional
algorithm, this specification does not provide a higher-level override of
rules P2 and P3. [BIDI]

"When necessary, authors can enforce a particular direction for a given
paragraph by starting it with the Unicode U+200E LEFT-TO-RIGHT MARK or
U+200F RIGHT-TO-LEFT MARK characters."

I strongly believe that this should also be the way that a notification's
body and title are treated when a notification has the auto dir value (and
that it should be the default dir value for a notification). I think that
the notifications spec should use something like the verbiage above or
perhaps a shorter synopsis something like this:

"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."

Aharon

On Tue, May 1, 2012 at 12:03 AM, Anne van Kesteren <annevk@opera.com> wrote:

> Here a brief summary of what we discussed at Apple today. Let me know if
> there are any questions. If you have comments please email them to the
> list. As I indicated earlier outcome of the meeting is subject to
> discussion.
>
> We discussed the remaining two issues with the specification:
>
> * Given that the DAP WG is no longer working on the permissions
> specification we will go with the proposal from Apple to expose the
> permission model as static members of the Notification object.
>
> * We discussed directionality and the outcome was to "ltr", "rtl", and
> "auto", defaulting to "auto", behaving the same as in HTML, but no
> inheritance as 1) it's unclear whether the root element exposes the right
> directionality to begin with and 2) workers don't have a directionality.
> Aharon, Kenny, if you concerns about this approach please let the list know.
>
> We also discussed display handling and whether the length of displaying
> was up to the notification platform or the application. Currently it is up
> to the application, but the specification allows for the notification
> platform to set a hard timeout. Aside from timeout configuration, the
> ability for progress bars and displaying actionable buttons in
> notifications came up as well. Proposals for these will be considered for a
> potential future version of Web Notifications. We will work with the W3C to
> recharter as appropriate.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>