Change Details

This was added via {T123153} in 2016. It does have so many issues: * It's rare that a dialog title is so long that it appears cut-off. A solution that tries to improve such an edge-case should take care to not introduce new issues. But this one does. * Users typically don't expect a tooltip on a window title. I believe it's fair to assume that the majority of users running into cut-off titles don't think of hovering them with the mouse. * It doesn't help users on touch devices. * In contrast to the minor benefit, the duplication is always a problem for e.g. screenreader users. The same text is always read twice. * It's useless and confusing in all situations where the title fits. I believe it's fair to assume that this is the vast majority. * Reading the short discussion in T123153 I do have the impression that: * Even back in 2016 it was clear this is just a band-aid patch, and probably not even a good one. (Quote: "Let's do that as a start.") * It's hard to tell what the reasoning for the tooltip solution was, other than being quick to implement. Nowadays the browser tooltip feature is considered to be inaccessible, see e.g. https://sarahmhigley.com/writing/tooltips-in-wcag-21/. * The implementation is half-baked. The duplicate tooltip is only set under very specific circumstances. Only when the `….static.title` property is used. But: * Not all dialogs do this. There are multiple ways to achieve the same, e.g. using a config option or calling `this.title.setLabel()`. Only some duplicate the title. * Many dialogs change the title dynamically. I could not find a single one that makes sure the tooltip is updated accordingly (or removed). Instead the tooltip says something wrong then. This probably qualifies as a bug in the majority of situations. * It's entirely undocumented, as far as I can see. Devs using a subclass of the Dialog class aren't aware of this and it's implications. This backs both the "band-aid" argument as well as the argument that this behavior potentially causes bugs in all code using #oojs. At this point it's better to ignore and work around this behavior (by not using `….static.title` but manually calling `….setLabel()`) or revert [the patch from 2016](https://gerrit.wikimedia.org/r/297973). A proper solution should act only when necessary, i.e. only when the title is actually cut-off. And even then a tooltip might not be the best solution. Instead: * The font size could be lowered a bit. * It could wrap to 2 lines. * The title could start a scroll animation. (Not that I think a distracting animation is a good solution, but it's a solution I have seen in other places.) * Another truncation algorithm can be used, e.g. one that puts the "…" in the middle instead of the end. * The tooltip could be shown on click instead of on hover. * … Some code already contains manual calls to `this.title.setTitle()` to work around the bug described above, see e.g. https://gerrit.wikimedia.org/r/700849. This does not scale: * According to T123153 the only reason the tooltip is there is to repeat the visible title. But the current implementation can't guarantee this. It's incomplete, causing unexpected behavior. * We can't expect every user of a Dialog subclass to know that calling `this.title.setLabel()` is not allowed without calling `….setTitle()`. This should happen automatically, just as the initial tooltip is created automatically. * Manually calling `….setTitle()` in e.g. VisualEditor means we work around a bug in the wrong codebase. * Every manual `….setTitle()` call hard-codes parts of the current implementation. Changing the implementation in OOjs (e.g. use other tooltips instead of the browser ones, or only show a tooltip when the title is actually truncated) will break such users.

This was added via {T123153} in 2016. It does have so many issues: * It's rare that a dialog title is so long that it appears cut-off. A solution that tries to improve such an edge-case should take care to not introduce new issues. But this one does. * Users typically don't expect a tooltip on a window title. I believe it's fair to assume that the majority of users running into cut-off titles don't think of hovering them with the mouse. * It doesn't help users on touch devices. * It doesn't help screenreader users, even makes their life harder. Screenreaders don't have a problem reading the full title no matter how long it is. When the software is configured to read title attributes (the screenreader users I know do this) the text is read twice. * It's useless and confusing in all situations where the title fits. I believe it's fair to assume that this is the vast majority of situations. * Reading the short discussion in T123153 I do have the impression that: * Even back in 2016 it was clear this is just a band-aid patch, and probably not even a good one. (Quote: "Let's do that as a start.") * It's hard to tell what the reasoning for the tooltip solution was, other than being quick to implement. Nowadays the browser tooltip feature is considered to be inaccessible, see e.g. https://sarahmhigley.com/writing/tooltips-in-wcag-21/. * The implementation is half-baked. The duplicate tooltip is only set under very specific circumstances. Only when the `….static.title` property is used. But: * Not all dialogs do this. There are multiple ways to achieve the same, e.g. using a config option or calling `this.title.setLabel()`. Only some duplicate the title. * Many dialogs change the title dynamically. I could not find a single one that makes sure the tooltip is updated accordingly (or removed). Instead the tooltip says something wrong then. This probably qualifies as a bug in the majority of situations. * It's entirely undocumented, as far as I can see. Devs using a subclass of the Dialog class aren't aware of this and it's implications. This backs both the "band-aid" argument as well as the argument that this behavior potentially causes bugs in all code using #oojs. At this point it's better to ignore and work around this behavior (by not using `….static.title` but manually calling `….setLabel()`) or revert [the patch from 2016](https://gerrit.wikimedia.org/r/297973). A proper solution should act only when necessary, i.e. only when the title is actually cut-off. And even then a tooltip might not be the best solution. Instead: * The font size could be lowered a bit. * It could wrap to 2 lines. * The title could start a scroll animation. (Not that I think a distracting animation is a good solution, but it's a solution I have seen in other places.) * Another truncation algorithm can be used, e.g. one that puts the "…" in the middle instead of the end. * The tooltip could be shown on click instead of on hover. * … Some code already contains manual calls to `this.title.setTitle()` to work around the bug described above, see e.g. https://gerrit.wikimedia.org/r/700849. This does not scale: * According to T123153 the only reason the tooltip is there is to repeat the visible title. But the current implementation can't guarantee this. It's incomplete, causing unexpected behavior. * We can't expect every user of a Dialog subclass to know that calling `this.title.setLabel()` is not allowed without calling `….setTitle()`. This should happen automatically, just as the initial tooltip is created automatically. * Manually calling `….setTitle()` in e.g. VisualEditor means we work around a bug in the wrong codebase. * Every manual `….setTitle()` call hard-codes parts of the current implementation. Changing the implementation in OOjs (e.g. use other tooltips instead of the browser ones, or only show a tooltip when the title is actually truncated) will break such users.

This was added via {T123153} in 2016. It does have so many issues: * It's rare that a dialog title is so long that it appears cut-off. A solution that tries to improve such an edge-case should take care to not introduce new issues. But this one does. * Users typically don't expect a tooltip on a window title. I believe it's fair to assume that the majority of users running into cut-off titles don't think of hovering them with the mouse. * It doesn't help users on touch devices. * In contrast to the minor benefit* It doesn't help screenreader users, the duplication is always a problem for e.geven makes their life harder. sScreenreader usersders don't have a problem reading the full title no matter how long it is. TWhen the same text is alwayoftware is configured to read title attributes (the screenreader users I know do this) the text is read twice. * It's useless and confusing in all situations where the title fits. I believe it's fair to assume that this is the vast majority of situations. * Reading the short discussion in T123153 I do have the impression that: * Even back in 2016 it was clear this is just a band-aid patch, and probably not even a good one. (Quote: "Let's do that as a start.") * It's hard to tell what the reasoning for the tooltip solution was, other than being quick to implement. Nowadays the browser tooltip feature is considered to be inaccessible, see e.g. https://sarahmhigley.com/writing/tooltips-in-wcag-21/. * The implementation is half-baked. The duplicate tooltip is only set under very specific circumstances. Only when the `….static.title` property is used. But: * Not all dialogs do this. There are multiple ways to achieve the same, e.g. using a config option or calling `this.title.setLabel()`. Only some duplicate the title. * Many dialogs change the title dynamically. I could not find a single one that makes sure the tooltip is updated accordingly (or removed). Instead the tooltip says something wrong then. This probably qualifies as a bug in the majority of situations. * It's entirely undocumented, as far as I can see. Devs using a subclass of the Dialog class aren't aware of this and it's implications. This backs both the "band-aid" argument as well as the argument that this behavior potentially causes bugs in all code using #oojs. At this point it's better to ignore and work around this behavior (by not using `….static.title` but manually calling `….setLabel()`) or revert [the patch from 2016](https://gerrit.wikimedia.org/r/297973). A proper solution should act only when necessary, i.e. only when the title is actually cut-off. And even then a tooltip might not be the best solution. Instead: * The font size could be lowered a bit. * It could wrap to 2 lines. * The title could start a scroll animation. (Not that I think a distracting animation is a good solution, but it's a solution I have seen in other places.) * Another truncation algorithm can be used, e.g. one that puts the "…" in the middle instead of the end. * The tooltip could be shown on click instead of on hover. * … Some code already contains manual calls to `this.title.setTitle()` to work around the bug described above, see e.g. https://gerrit.wikimedia.org/r/700849. This does not scale: * According to T123153 the only reason the tooltip is there is to repeat the visible title. But the current implementation can't guarantee this. It's incomplete, causing unexpected behavior. * We can't expect every user of a Dialog subclass to know that calling `this.title.setLabel()` is not allowed without calling `….setTitle()`. This should happen automatically, just as the initial tooltip is created automatically. * Manually calling `….setTitle()` in e.g. VisualEditor means we work around a bug in the wrong codebase. * Every manual `….setTitle()` call hard-codes parts of the current implementation. Changing the implementation in OOjs (e.g. use other tooltips instead of the browser ones, or only show a tooltip when the title is actually truncated) will break such users.