Page MenuHomePhabricator

[Regression 1.26wmf3] VisualEditor's toolbar icons ignore content directionality
Open, MediumPublic

Description

There are a couple of toolbar icons whose direction depend on the content direction rather than the interface. For instance, the list icons (bullet list, number list, etc) depends strictly on the content of the document (and specifically the context that the cursor's in, in case the document contains multiple directionalities) and not the UI language.

Specifically, the toolbar has two sets of classes that are applied to it depending on the context of the cursor: ve-ui-dir-inline-rtl/ltr and ve-ui-dir-block-rtl/ltr
We used to have the icons specified in a VE-specific css file that defined the directions of those icons based on the above classes rather than the overall UI directionality. The classes seem to still be properly applied, but the icons are no longer defined to "listen" to this rule.

Lists (bullet/number) icons should go by the direction of the ve-ui-dir-block-(ltr/rtl) class and completely ignore the UI direction.

This used to work, and is now broken.

Event Timeline

Mooeypoo created this task.Jul 7 2015, 9:14 PM
Mooeypoo raised the priority of this task from to Needs Triage.
Mooeypoo updated the task description. (Show Details)
Mooeypoo added a project: VisualEditor.
Mooeypoo added a subscriber: Mooeypoo.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 7 2015, 9:14 PM
matmarex claimed this task.Jul 7 2015, 9:18 PM
matmarex added a project: Regression.
matmarex set Security to None.

[22:56] <MatmaRex> mooeypoo: this is about listBullet and listNumbered icons? perhaps a better solution would be to "duplicate" them, e.g. listBulletLTR and listBulletRTL, and switch the icon being displayed from JavaScript
[23:02] <MatmaRex> (this is probably a regression from 28844ed633c6f07d2a777ed3b643049e1fee803b)
[23:02] <MatmaRex> (feature added in 87fd3b7756a9bd40ab9742dbc8a5a391b280caf1)

Jdforrester-WMF renamed this task from (Regression) VisualEditor's toolbar icons ignore content directionality to (Regression) [wmf3] VisualEditor's toolbar icons ignore content directionality.Jul 7 2015, 9:47 PM
Jdforrester-WMF triaged this task as High priority.
Restricted Application added a project: I18n. · View Herald TranscriptJul 7 2015, 9:47 PM

What about adding a config to RLIM to load both directions? For content-language specific icons, we will want to load both, but for interface-language specific icons we won't.

We could, but then we'd still need a way to choose which one to display. We could implement a way to define custom selectors for icons, if we want it to match .ve-ui-dir-block-ltr/rtl (which looks like a ton of thankless work that'd make the system even messier than it already is), or maybe come up with a sane default class name for both versions and then use that in VE code (which is suspiciously like… just duplicating the icon, but more code to write and maintain).

I'm all for proper RTL support but I think supporting this functionality going forward might be a bit excessive. I think the icons should get their directionality from the document and that's that. In the vast majority of cases the user will be familiar with these icons in their native direction, and understand what they do - they aren't going to suddenly be thrown because they icons *didn't* change when they entered an strange text area that's in a different direction.

I think tools that mention directions, such as the table context tools, need to match the content direction always, but 'increase indentation' is clear no matter what the direction.

Mooeypoo added a comment.EditedJul 8 2015, 4:33 PM

I very much disagree.

Sure, it's possible to translate the direction of these icons to your content's context, but from experience, it's actually not that easy and can be really confusing, especially when dealing with multiple contexts and/or conflicting contexts between the document and the interface. This is especially true for the indent button. The list icon is one thing; it's still a little weird, but users can understand the idea of having a list even if it's flipped -- the indent, however, is directional, and can be incredibly confusing when you deal with content that is on the other direction.

I can't express how many times I would click the wrong indent direction in editors online, then have to undo and click the other one. It can get really confusing.

This will be even more confusing when/if VE supports language blocks. It already is confusing in pages that have divs with different directionalities in the wikitext (and those exist in a few places, especially in hewiki.)

So, I think three points can be made in favor of implementing a solution here (whichever the solution may be)

  • I don't think the implementation is that difficult; we used to have this done very easily with simple CSS rules that used either iconname-ltr or iconname-rtl based on the already existing CSS classes on the toolbar. This is a regression in a piece of code that used to be relatively easy to implement and extremely easy to maintain; you just add a rule to a CSS file with /* @noflip */ on it.
  • Relatedly, since this worked in the past, the issue now seems to be with the way we load icons, and fixing it would probably benefit not only VE itself, but other pieces of software. I don't think it's a good thing that the icon system in OOUI doesn't support flipping inherently. We should fix that, or find a fix that others can reproduce.
  • And lastly, while it's true that RTL users expect bad behavior from editors, VE should do better.

We could, but then we'd still need a way to choose which one to display. We could implement a way to define custom selectors for icons, if we want it to match .ve-ui-dir-block-ltr/rtl (which looks like a ton of thankless work that'd make the system even messier than it already is), or maybe come up with a sane default class name for both versions and then use that in VE code (which is suspiciously like… just duplicating the icon, but more code to write and maintain).

Can we not add a configuration option to the resource loader icon loading mechanism that lists an array of icons that should be loaded with both directionalities, or even "just" state some sort of override of "always load these icons"? It sounds like this might actually be helpful to other products and other cases, as well.

Can we not add a configuration option to the resource loader icon loading mechanism that lists an array of icons that should be loaded with both directionalities, or even "just" state some sort of override of "always load these icons"? It sounds like this might actually be helpful to other products and other cases, as well.

We can, but what good will it do? You still need a way to choose which one to show. Just making them a separate icon will accomplish the same effect without needing a new API.

Relatedly, since this worked in the past, the issue now seems to be with the way we load icons, and fixing it would probably benefit not only VE itself, but other pieces of software. I don't think it's a good thing that the icon system in OOUI doesn't support flipping inherently. We should fix that, or find a fix that others can reproduce.

Define "inherently". We do inherently support flipping based on user's language, and that's exactly what's happening here. We don't support flipping based on arbitrary dynamic client-side data. For that, we use different icon names. (Just like we don't have one icon for both "lock" and "unlock", varying on whether something is locked, but two separate ones.)

It wasn't "inherently" working before, either - someone had created this logic and implemented it in CSS. Now that we're trying to make this reusable, the logic had to be removed and we only have "dumb" CSS selectors. (I am myself not a huge fan of this practice when applied too religiously, and <div class="column4-12"> and <span class="icon icon-alert destructive"> look suspiciously like <table align="left"> and <font color="red"><img src="alert.gif"> to me, when we could be using <aside> or <span class="warning"> instead, but I digress.)

Mooeypoo added a comment.EditedJul 8 2015, 5:07 PM

Can we not add a configuration option to the resource loader icon loading mechanism that lists an array of icons that should be loaded with both directionalities, or even "just" state some sort of override of "always load these icons"? It sounds like this might actually be helpful to other products and other cases, as well.

We can, but what good will it do? You still need a way to choose which one to show. Just making them a separate icon will accomplish the same effect without needing a new API.

I might be missing something here, but what's wrong with the way we used to do it? We had a special css rule that went something like

.ve-ui-dir-block-ltr .oo-ui-bulletList-icon {
    /* @noflip */
    background-image: url( bulletlist-ltr.png );
}

.ve-ui-dir-block-rtl .oo-ui-bulletList-icon {
    /* @noflip */
    background-image: url( bulletlist-rtl.png );
}

We had those rules for the 3-4 icons we wanted to flip, and it worked without needing to do something special in JS. The only special operation in JS is to set and switch the direction css classes on the toolbar -- and that's already implemented.

Am I missing something? Why is that not a good way to go?

Relatedly, since this worked in the past, the issue now seems to be with the way we load icons, and fixing it would probably benefit not only VE itself, but other pieces of software. I don't think it's a good thing that the icon system in OOUI doesn't support flipping inherently. We should fix that, or find a fix that others can reproduce.

Define "inherently". We do inherently support flipping based on user's language, and that's exactly what's happening here. We don't support flipping based on arbitrary dynamic client-side data. For that, we use different icon names. (Just like we don't have one icon for both "lock" and "unlock", varying on whether something is locked, but two separate ones.)

"User language" is a bit of a misnomer. First, we're not talking about language, we're talking specifically about directionalities (Which is different even with the behavior of the icons) and second, the language is twofold, which is the entire issue -- content language and interface language are separate and different, and that makes the user's life (especially one that deals with different directionalities) really quite difficult and confusing.

The icon system may support pre-processed flipping, but if it doesn't support dynamic flipping based on content, I think that's a bad behavior. We might (hopefully) support language blocks in the future; we might also want to do things with OOUI and already mixed-directionality products like Commons, where media is shared in various languages and directionalities. I think having OOUI icon system be limited to ONE language (interface) is wrong, and we might actually be shooting ourselves in the foot here with other products that will be using OOUI in the (near) future.

It wasn't "inherently" working before, either - someone had created this logic and implemented it in CSS. Now that we're trying to make this reusable, the logic had to be removed and we only have "dumb" CSS selectors. (I am myself not a huge fan of this practice when applied too religiously, and <div class="column4-12"> and <span class="icon icon-alert destructive"> look suspiciously like <table align="left"> and <font color="red"><img src="alert.gif"> to me, when we could be using <aside> or <span class="warning"> instead, but I digress.)

The logic is reusable; you have selectors and a way to use them, and it really sounds to me to be fairly easy - both to implement (anywhere) and to maintain. And to run, too, as it doesn't seem to take much processing power to say the least.

Other products may have other needs for their icons to flip which would require different implementation, but if OOUI's icons aren't allowing you to load certain icons with two directionalities already, then that's a rigid part of ooui itself that will prevent others from finding the solutions that work for their products to begin with.

"User language" is a bit of a misnomer. First, we're not talking about language, we're talking specifically about directionalities (Which is different even with the behavior of the icons) and second, the language is twofold, which is the entire issue -- content language and interface language are separate and different, and that makes the user's life (especially one that deals with different directionalities) really quite difficult and confusing.

Yes, I meant interface language, sorry.

The icon system may support pre-processed flipping, but if it doesn't support dynamic flipping based on content, I think that's a bad behavior. We might (hopefully) support language blocks in the future; we might also want to do things with OOUI and already mixed-directionality products like Commons, where media is shared in various languages and directionalities. I think having OOUI icon system be limited to ONE language (interface) is wrong, and we might actually be shooting ourselves in the foot here with other products that will be using OOUI in the (near) future.

Hmm. Okay, you have me convinced that this is something that would be worthwhile to have. Now you need to convince me that it would be practical ;)

  • Providing two versions of each icon would basically double our payload, for a feature that (currently) would hardly be used anywhere (remember, we embed all vector icons in the stylesheet). Or we could do something clever (like CSS transforms to flip the icons which are simply mirrored), increasing the complexity of the system and making the icons more difficult to change, and possibly affecting browser compatibility (needs research).
  • We'd probably need to pretty heavily rework everything that currently assumed that we only need to serve one image for each icon.
  • We'd need an API to choose the directionality of icons to display for given OOUI element. We could rely on the .oo-ui-rtl / .oo-ui-ltr classes (which are currently used very inconsistently), we'd also need to do something smart with regards to OO.ui.Element.static.getDir and OO.ui.Window.prototype.getDir probably.

This is not insurmountable, but probably not a weekend project either.

If the issue as stated ("VisualEditor's toolbar icons ignore content directionality") is really "High" priority, then for now we should just duplicate the icons in OOUI, or add back the custom stylesheet bits in VE (since that's something that can be done in an hour or two).

matmarex removed matmarex as the assignee of this task.Jul 14 2015, 3:11 PM
matmarex added a subscriber: matmarex.

Okay, I guess it can wait until we work out the general solution, then.

Jdforrester-WMF renamed this task from (Regression) [wmf3] VisualEditor's toolbar icons ignore content directionality to [Regression 1.26wmf3] VisualEditor's toolbar icons ignore content directionality.Jul 14 2015, 3:27 PM
Jdforrester-WMF lowered the priority of this task from High to Medium.
Mooeypoo moved this task from Backlog to VisualEditor on the RTL board.Jul 15 2015, 6:28 PM
Amire80 moved this task from Untriaged to RTL on the I18n board.Feb 27 2018, 7:39 AM