[Webkit-unassigned] [Bug 69680] Dir attribute is converted into direction property when merging paragraphs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=69680





--- Comment #3 from Aharon (Vladimir) Lanin <aharon at google.com>  2011-10-11 07:10:05 PST ---
(In reply to comment #2)
> (In reply to comment #1)
> > > should we generate <div dir="ltr">XY</div>
> > > or <div dir="ltr">X<span dir="rtl">Y</div>?
> > 
> > IMO, the former. The problem with the latter is that you are converting
> > paragraph direction style to inline direction style. While paragraph
> > direction is usually indicated by alignment, and most editors provide
> > buttons to see it and control it, neither is the case for inline direction.
> > Thus, later on, the user has no way of knowing that the <span dir=rtl> is
> > there, and thus will be surprised when things work differently than they do
> > normally. And even if the user figures out what's going on, he has no way
> > of removing the inline direction style, and can not tell whether the caret
> > is inside it or just next to it.
> 
> Safari provides a context menu to do this

Wow, I did not realize this.

> but I agree that it's not so user-friendly if the user had to use it very
> often after copy-paste.

Indeed. To see that the inline direction style is there, one has to highlight *exactly* the text covered by the span (not one character more) and click for the context menu. Not very discoverable.

> > > WebKit currently adds direction property when copying content
> > > inside an element with dir property. But this wouldn't work if
> > > the copied content was wrapped by span (need to add
> > > unicode-bidi: embed as well). I don't even know what the correct
> > > behavior is.
> > 
> > First, about the dir attribute vs direction & unicode-embded styles: stay
> > true to what the source has. If it has mark-up like the dir attribute, use
> > that mark-up. Only use CSS if it has something beyond the mark-up. 
> 
> This issue is a little tangential in my opinion.

True.

> It's same problem as WebKit converting b to <span style="font-weight: bold">
> in some cases. We can probably tackle this in some other bug.

The problems are not of the same severity. Bolding is basically an issue of presentation, so style is the right way to do it (for which reason <b> had been deprecated at some point). Text direction is far more than presentation - it is the very nature of the text being displayed. The dir attribute is the right way to do it, and doing it in style alone is discouraged. But, as you said, this is not what this bug is about.

> > Now regarding copying directional information on the copy command. Here
> > too, I think the guiding principle should be to avoid creating inline
> > direction. Thus, if you are going to be creating a <div> or <p>, I think it
> > is very good to put a dir on it in accordance with the source's computed
> > style (even if the source did not have it explicitly on that element). And
> > if the source already has a <span dir=...>, then by all means copy it
> > verbatim. But I do not think that it is good to create a span with
> > direction when the source did not have it.
> 
> Here's a tricky case what if an user selected a part of block? e.g. ([ and ]
> indicate the start and the end of selection below)
> <div dir="rtl">hello [world<p>WebKit</p>]</div>
> 
> In this case, p is a block element and it has RTL directionality inherited
> from the parent div. Which one of the following markups should we generate?
> 1. world<p>WebKit</p>
> 2. world<p dir="rtl">WebKit</p>
> 3. <div dir="rtl">world<p>WebKit</p></div>
> 
> I'd cross-out option 2 because "world" and "WebKit" would have different
> directionalities after paste and behave differently for <div dir="rtl">hello
> [world<br>WebKit]</div>

Whatever you do, I do not think it should be a special case for directionality. That is, you should not come up with different element structures for two cases that only differ in elements having or not having a dir attribute. Probably the best way to think about it is to change the case to have a text-align style (which, by definition, is a block-level style) where it currently has a dir attribute and work backwards from there. So, what would you do for <div style="text-align:center">hello [world<p>WebKit</p>]</div>?

The good thing about asking that question is that you do not have to limit yourself to a supposed bidi expert like myself.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.