Re: directionality of a notification

(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

Received on Friday, 23 December 2011 02:22:41 UTC