Replacing legacy breakpoint variables with new Codex
design system `@max-width-breakpoint-*` tokens.
Bug: T331403
Change-Id: Ib1ff07a7692948b1fd22e9620c132133d392dab9
Follow-up to 5b6018b244 which put an
element between the advanced box and the actions wrapper. We can have
the rule use the subsequent sibling selector rather than direct sibling.
Bug: T348143
Change-Id: Ibe1b25bf15d320b17601a0d9471d4b7e6ca4ef19
Also, replace a `px` value with an `em` value in another similar case,
to support users and skins changing base font size. The exact values
don't matter that much.
Bug: T335823
Change-Id: I18778b13948abc18d67631d620be0b658d04facf
Replacing 'mediawiki.ui/variables.less' @import with
new skin-aware 'mediawiki.skin.variables.less' standard.
Also
- replacing several static values with new Codex design token featuring
skin variables – `background-color` `color`, `border-*`, `box-shadow`.
- removing skin overrides like `.skin-monobook`, they are now covered
by the skin variables.
Patch requires MediaWiki core version >= v1.41.0.
Bug: T332541
Co-Authored-by: Volker E. <volker.e@wikimedia.org>
Change-Id: I36c7a0f5ed06c3eccd792b19b6a1972663f20df6
This allows it to be re-used for other features, such as the
upcoming floating "Add topic" button.
Add some support for Android, although not used in this patch.
Change-Id: Ibd1e1ee087ac607c88a7402d0422c633700d1992
Also ensure that when we click the button, we scroll the widget fully
into view below the sticky header.
Bug: T318474
Change-Id: I394f02912cd6ab2773552a7364691ef89a17369c
In general we are hiding non-content elements in the preview
and this matches the behvaviour of the article editor.
Change-Id: I6669d8cc737214d464b662ccc6900ccce229b3d7
We remove the [reply] and [subscribe] links when they should not be
visible (controlled by 'enableSectionEditLinks' option, which is
disabled when previewing).
Bug: T309423
Change-Id: Ie0d3fba2c4d166daac3ea2e117a246c9584284ca
Use 12.8px for interface, and 12.7px for content.
Move mode tabs away from the reply body so the underline can be seen.
Change-Id: I9cb9a611ca64595152f800e1e15b640402f6cb74
When moving the edit mode switcher outside of the toolbar actions,
we apparently forgot that we can disable this feature entirely.
Also remove $overlay: true, which isn't needed after the changes
from T307849.
Change-Id: I005cf18853305edd162c613f60b1ac45f42c3093
When there are just two modes, using arrow keys to switch between
them is not intuitive. The focus moving from the selector to the
body widget afterwards is even less intuitive.
Override default TabOptionWidget to allow options to be highlightable
(not just immediately selectable), and mark the current mode's tab as
disabled instead of selected (but make it look selected).
This results in intuitive keyboard interactions (tabbing to the widget
highlights the other tab rather than the current one, pressing enter
switches to it).
Bug: T274423
Change-Id: I9d358d5f301cbf081380ef5d34ccc8c4e146652e
Longer, but follows the style guide and less likely to conflict.
We need to account for init classes in the cache being around for
a while.
Change-Id: I738bc93393850db320fdbda2b003ca8ac40556da
There are no available tools that use this, but it
can be tested using:
ve.init.target.surface.executeCommand('specialCharacter')
Change-Id: I853e6a3b9bd3caff018b6fe22cea9b1c6a428dff
1. Extend the JS modifier to allow adding top-level comments
(that is, replies to headings). PHP modifier doesn't do this
because we'll save the changes using paction=addtopic instead.
2. Subclass CommentController to allow adding a new heading and a
top-level comment underneath it at the same time.
3. A lot of ugly code in ReplyWidget to customize the interface
for this case. Much of it should probably be moved to
CommentController/NewTopicController.
Bug: T267595
Change-Id: I9c707bb7f7aae1b92c72fb4dee436490f8c8409b
Follow-up to d5a1b7bc2b.
The rule hiding the scrollbar was applied to the wrong element.
Bug: T267609
Change-Id: I596f29ba191032a82c579c63e9aa526eb4e887aa
Even though the field is supposed to resize itself to match the text
inside, vertical scrollbar would sometimes appear when the user has
zoomed in. Some calculation probably handles fractions of pixels
incorrectly (might be a bug in OOUI or a browser bug).
Since this field has no limit on max rows, we can just hide the
scrollbar. This can't be fixed in OOUI itself, since its autosize text
fields usually have a limit to how tall they are allowed to grow
before a scrollbar is used.
Bug: T267609
Change-Id: Id36ed417c4678e469a6c05715404e330064c2017
