The border color was added 20016-08-12 via Id561485.
The border was removed 2016-09-15 via I1fdc0ec.
The color is meaningless since then.
Bug: T370572
Change-Id: Ic7a190bf3b56903f2afdd989eb1e78fa02ac01d9
This line was added in 2017 via I9adbd47. I think this was a mistake.
What happens is that the grab cursor appears as part of the hover
effects (the yellow/blue "ghost" circles). But these can't be
dragged. Having the cursor there is confusing as it constantly
flickers between the click and drag cursors.
Am I missing something?
Change-Id: I611fee6f7199d68b61b103bcbb2011c88651883b
Hover and click events to highlight or change revisions need to
know the intended revision target. This did not work for the area
where the pointer containers overlap the underlying revisions.
For that reasons we implemented a calculation to get the revision
using the mouse positions. That implemetation seems to be faulty
at some points.
pointer-events: none allows us to pass though the mouse events so
that we're able to always rely on the revision containers as target.
On the pointers we still want to catch events to allow dragging.
Bug: T352169
Change-Id: Ie53a6ec3b7c458dc2f72e494829dfab80952b86f
The idea is to visually group things together that belong together.
This reduces duplication and hopefully makes the code easier to
read.
Change-Id: I609ee0eb5644de9c32984a3b2535652504e0e940
While working on renaming and consolidating some methods I found
it puzzeling, that the generic "highlight" word is already taken
by the filter mechanism. So I made these things more specific.
I checked the global wiki search if any user referes to these to
override CSS. It seems nobody does, so the change should be save.
Change-Id: I47c149978b0527c2d9e91709ef9d704526d56101
According to the compatiblity standards to give Grade A support
for modern browser versions not older than 3 years, we do not need
these workarounds anymore.
Change-Id: Ib1c42594b2c4077cabb010b8830a04ab10938a17
This was removed in I75ef7c3. Turns out it's needed for the
highlightable elements in the popups (e.g. when highlighting all
edits made by the same user). The text row in the popup gets a thin
gray border. This border needs some padding on the left.
The solution is to make the CSS selector more specific so it can
win over the problematic selector in Vector.
Bug: T341872
Change-Id: Ia029b92b5e049c60279b55177a62e03919dc55d8
When the user uses the keyboard to interact with the slider, the
revisions can changed by moving the pointers with the arrorw keys.
In that case the pointers have keyboard focus. To allow tabbing
into the popup from that position, the tooltip needs to follow the
pointer in the DOM. That's what's done in this patch.
Bug: T341872
Change-Id: I75ef7c32fb105526552eac387ff5a5bda8eefe1b
Removed the HTML in the tutorial message and used linebreaks(\n\n) in i18n/en.json file,
replaced .html( mw.message( '…' ).…() ) with .text( mw.msg( '…' ) ) in modules/ext.RevisionSlider.HelpDialog.js
and added 'white-space: pre-wrap' in class '.mw-revslider-column-text' in file modules/ext.RevisionSlider.less
without affecting the front end of the page.
Bug: T267128
Change-Id: Iaf8b1819ca3139c18fb65cfca1c0b2120abb10f4
- move border to right so when the text starts there's a straight line
- increase right margin to fit mock
- adjust border radius so it's most probably always more than the line height
Bug: T218770
Change-Id: I76a2f096d14bf4d912686a71e5771ead1c7db3e6
* Uses the existing implementation of highlighting revisions from the same user
* Shows bubble next to tags in Tooltip
* When you hover on a bubble, tag row is circled, and revisions with a specific tag gets highlighted. When hovering ends, highlighting ends. But, if there is an active filter available, all previous states are restored accordingly.
* When you click on a bubble, in addition to highlighting revisions and tag row, any previous tag or user filter is removed.
Bug: T203581
Change-Id: I824a027a7f542eb7227545870553e58ec23542bb
Initial patch for introducing keyboard shortcuts reversed the blue and yellow lines. To fix that issue, the DOM order for pointer lines were put back to the original state in https://gerrit.wikimedia.org/r/#/c/473217/. Now, this patch tries to put the tabbing order in place reversing the changes made for the fix as per discussion in https://phabricator.wikimedia.org/T162119#4753481 and style changes.
Bug: T162119
Change-Id: Ic84503de0a877095c118abddb8066aeb667bc03c
Also
- fix arrow width to one size of `20px` and
- make use of `.box-sizing` mixin in one occurrence.
Bug: T207905
Depends-on: I09aea78f8ebde37cf4f7de9bf0e14894c76ee722
Change-Id: Ibf4a6c8b77877a34668e91b0f5cf6c11a23e9f88
* Added `tabindex` on yellow and blue knobs to enable tabbing
* Used some of the logic of draggable functionality to support moving between revisions with keyboard shortcuts
* Also changed the source order of old and new pointer. Old pointer comes first in the DOM
Bug: T162119
Change-Id: I4d8db2352915c44aa11617edea5bcb0ac92ddc93
Completed subtasks
* Added bubble in the Tootltip
* Added border on clicking or hovering the bubble
* Highlites Bubble on hover
* When Clicked or hover on the Bubble: Highlights
revisions from the same user
* Added filter revisions.
Bug: T136105
Change-Id: I64cfef395ce1812d501980067edffe210fc99227
Added show() and hide() for mw-revslider-auto-expand-button in collapse and expand function.
Bug: T200263
Change-Id: Ic24a175dfe8d19853e32669f12b9f17e26730d6b
