Re: directionality of a notification

IMO, the default for the dir of a notification should be like the closest
equivalent in HTML - alert() and confirm() dialogs. These do not allow
specifying a directionality. In HTML5, it has been decided that the
direction that should be applied to their text is per-paragraph per-strong
estimation. See
http://dev.w3.org/html5/spec/Overview.html#text-rendered-in-native-user-interfaces
:

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.


We decided not to try to derive the direction from the element enclosing
the script, or even from the overall page direction, because it makes it
very difficult to code scripts if the strings they display are interpreted
one way in one page and another way in another.

I think that the same reasoning applies here. The "auto" value should not
mean inheritance, but first-strong estimation, and should in fact be the
default.

Aharon

On Fri, Dec 23, 2011 at 4:22 AM, Kang-Hao (Kenny) Lu <
kennyluck@csail.mit.edu> wrote:

> (11/12/23 9:28), John Gregg wrote:
> > On Thu, Dec 22, 2011 at 10:21 AM, Kang-Hao (Kenny) Lu <
> > kennyluck@csail.mit.edu> wrote:
> >
> >> I have three pieces of feedback regarding the Directionality section[1]
> >>
> >> 1. When the dir attribute of a notification is in "inheriting
> >> state"(i.e. dir="auto" currently) and the notification is called from a
> >> Web Worker, the resulting directionality is now always 'ltr'. Is that
> >> intentional and desirable? If not, I suppose we use the directionality
> >> of the root element (or the body element, whatever is better), if
> >> exists, of the calling script's document (or the script's document's
> >> browsing context's active document, whatever is better) as the inherited
> >> directionality.
> >>
> >
> > Using 'ltr' when there is a non-document context is essentially a fall
> back
> > case when the context doesn't provide an obvious answer.  In the shared
> > worker situation I think it's particularly difficult to establish a
> > surrounding directionality, and would think authors would prefer being
> > explicit in that case.  We could improve things somewhat in the dedicated
> > worker situation where the script can be unambiguously connected to a
> > document which would be the logical directionality to inherit.
>
> Even for the shared worker case, the HTML spec has a well-defined
> definition of the Document of a script, which is passed to the shared
> worker script from the calling script so it would be the original
> Document of the <script> that called SharedWorker. (see step 12 of [1])
> I think the definition is understandable but I can't speak for bidi
> authors and you might be right on this.
>
> There's some subtlety about the wording "the directionality must be the
> same as the Document object associated with the global Window object" since
>
> A Document doesn't have directionality (in some sense), and
> document.dir[2] could return either "ltr", "rtl", "" or "auto". It
> reflects the @dir attribute of "the html element" limited to those four.
>
> An HTMLElement does have directionality[3] and it could only be "ltr"
> and "rtl".
>
> I am not knowledgeable about the underlining notification system so I
> don't know if it's capable of taking all four possible values. If not,
> we need to get the directionality of an HTMLElement from the document.
> It could be "the html element" or "the body element" as defined in the
> HTML spec although I don't know which would be better. (and if none of
> them exists the directionality is definitely "ltr")
>
> The concern about the "the html element" vs. "the body element" is that
> if I recall correctly, some "rtl" pages only set @dir on <body> so "the
> document's directionality" isn't well defined.
>
> [1]
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dom-sharedworker
> [2]
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#dom-document-dir
> [3]
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#the-directionality
>
> >> 2. The "auto" value conflicts semantically with the @dir content
> >> attribute in HTML, which uses the first strong algorithm. I propose we
> >> use the empty string to identify the "inheriting state", and potentially
> >> a new "auto" value to identify the "first strong state". In this state,
> >> the UA would apply the first strong algorithm to the content of the
> >> notification to determine the directionality used.
> >>
> >
> > The intent is to match what HTML does -- earlier versions of the spec
> tried
> > to indicate that the notifications "dir" attribute follows all HTML
> rules.
> >
> > So I'm fine with changing it so that "auto" applies that same algorithm
> and
> > a missing value implies inherit the way it's written now.  I don't think
> it
> > needs to be an empty string explicitly.
>
> That sounds OK. You just need to define what the dir attribute should
> return when read if it's in the "inheriting state", which is different
> from the other three.
>
> Another choice is we leave "auto" as what the spec currently says and
> don't introduce another algorithm. Namely, I am fine with dropping this
> comment if bidi folks are fine with it.
>
>
> Cheers,
> Kenny
>
>