The icons have a padding of 6px around the icon image itself. To
get to the required 16px/8px space the margin was adjusted
accordingly. Note that there's also a 2px padding around the menu.
Bug: T272482
Change-Id: I3df9f355dfd5c4e6366432555b96bf788e784280
I get a scrollbar at the bottom of the sidebar. The reason is
that the container's width is 100% + 1px. The extra pixel is
from the border, which is not needed in this mode.
Bug: T274554
Change-Id: I4f749be6b9a7f89f9a7a195dc66c5c18253b1327
This is – for now – intentionally done in a way that can be
undone. This will still be helpful for debugging for a while.
But we need to get rid of the duplication to be able to make
this new functionality visible on the beta cluster.
Actual removal will hapen the moment we actually remove the
old toolbar. There are already tickets for this.
Bug: T286765
Change-Id: I842c3c39a55a273af20643fa8a602d2e57fb6b8c
This ellipsis was there before we started working on this code,
but was never working properly.
We understand that the CSS was intentionally done like this (as
the comment explains). However:
* We changed the width of the dialog. The old value doesn't
match any more.
* The width is different when the sidebar is expanded vs. when
it is collapsed. Even if we update the number, it won't
always work.
* The 100% work fine in current browsers. I can only assume
this was different back in 2014 when this CSS was written
(see Ia8259e9).
Bug: T285044
Change-Id: I3de2b0ed0b6a05d2b9fa0b325a2b12277564b271
Actually reusing this OOUI mixin gives us a lot of well
developed functionality we need anyway. Most notably proper
event management, e.g. click events.
The number of CSS properties we need to override is managable,
I would argue. Let's see:
* Our buttons are not inline-elements, but should use the full
width.
* No focus-border left and right for the same reason.
* We want much more inner padding.
* We want a stronger hover effect.
* We need to fine-tune the position of the icon. This is
because of the inner padding.
* Need to get rid of a negative margin that's only relevant
for inline-buttons.
I currently feel like the benefits are worth living with
slightly more brittle code. Note that we can undo this change
any time because all this is well encapsulated in this new
class.
Bug: T274544
Change-Id: I33f275a958964d49e803e56bf74a6fa961093da1
This introduces another generic "button-like" class that can
be reused in multiple places in the new sidebar. The main
change in this patch is the "add more information" button
which is now an instance of this new class as well.
This patch also simplifies over-complicated setup code in
related widgets.
Bug: T274544
Change-Id: I0cfe7675d02fdd5c5dc8d9198bb3f4aec9abf397
Before, the new sidebar was hacked in a place where it confused
the BookletLayout logic. This became visible when using the
up/down buttons to move elements in the sidebar.
This new container wraps the new and the old sidebar. It also
uses a temporary color to make it easier to see where one ends
and the other starts.
Bug: T274544
Change-Id: I4e5b40b1d1556886fc85cff9e926a02e4888f032
The two new widgets are pretty trivial now, thanks to the base
class.
Note there is still no code to delete the widgets. That's also
why you will always see a placeholder widget at the top. This
will be fixed with the next patches.
This patch also renames most of the "…TemplateOutline…" classes
to "…TransclusionOutline…" The reason is that these widgets are
not for a single template, but part of the container widget for
a more complex transclusion (i.e. a sequence of multiple
templates and wikitext snippets).
Bug: T274544
Change-Id: If4219b0b8ad4d1969ab1ec5ec4db0728811bab35
The icon and the name of the template are now created by the
base class. This is meant to be reused for other elements
that are not templates.
Bug: T274544
Change-Id: I76bbc0e8c0420e9c6357d093d5f5e1651a0c2719
This matches the existing naming scheme better. I also plan to
re-use this class for other types that are not templates.
That's why the name is the more generic "transclusion" now.
This patch also removes a `padding: 2px` that's not that
helpful. We will need paddings later, but need to choose them
much more carfully.
Bug: T274544
Change-Id: I6f0f630da2230b023b3fb065e5ad86d8211bb7b3
It's good practice to make transparent elements transparent
for mouse clicks as well, i.e. make it possible to select text
behind the fade effect.
Bug: T283943
Bug: T286235
Change-Id: Ib5022a74c70e4b7cb5e2a0faad20bd9abcc0da36
Introduces new widgets forming the backbone of the experimental
template dialog sidebar.
FIXME: `text-overflow: ellipsis` is not working yet, the container
styles need adjustment.
Bug: T274543
Change-Id: Ie81b84be288553343017c4aaf8691c4e266995f5
Both the template description as well as the parameter
description (including default value and examples) typically
contain longer texts. These can contain longer words that
"explode" the design. This is trivial to avoid.
Note this is not meant to fix this issue in all places where
it can appear. For example, a long parameter name causes the
same issue. But:
* Technically, it's not that easy to fix.
* Even if, it's not obvious how to fix it. Cut off the
container? Add ellipsis? Or wrap? How should the
surounding stuff float then?
This is all left out because of this. Focus on what's
obvious.
Bug: T284890
Change-Id: Id6700af168f5ab5ddde97d3f5ae63829b65a3be5
This dramatically simplifies the "mode" flag in
MWTransclusionDialog. The main reason to touch this code is:
The flag appears like it will be "single" when the dialog
contains a single template, and "multiple" when there are
multiple templates. But this is not true.
What the flag really does is show/hide the sidebar. The sidebar
is needed to be able to create multi-part templates. But a
dialog that already contains multiple templates can be set to
"single" mode (i.e. the user can collapse the sidebar), and
vice versa.
This patch focuses on private details inside of this class, but
keeps the terminology of a "mode" in some places. E.g. the
messages are not renamed to not cause unnecessary trouble for
translators.
Change-Id: Ib029fd48b393d2ab7d7cff6c842789e22989e944
Previously, if the checkboxes were shown on multiple lines (e.g. due
to a FlaggedRevs checkbox), there would be uneven margin at the
bottom. There was a special case to fix this only for the watchlist
expiry not-checkbox.
Change-Id: I006049cf23e6d42519bfa15b7ec30ea1bc5d08ac
These are the most minimal (and therefor most stable,
hopefully) hacks I could come up with so far.
Bug: T274903
Change-Id: I28ba414dd34aad756e29400eb656f0942291a923
Renames "Add a template" to "Template Search" in most cases and
provides inline help for the workflow.
Bug: T277028
Change-Id: I3fee87cb89b5044e785596e71ef3f1a18f2694ce
The name "description" conflicts with the TemplateData field name,
which is only one of several documentation fields.
Change-Id: I0942701204fe8499e8890740585b9a02c1d14c63
The internal name "more" conflicts with new collapsible buttons.
TODO: looks like TemplatePage has an analogous field?
Change-Id: I10b24758316a6cc3fbd236c77daffa014fcdafc6
When $wgVisualEditorTransclusionDialogInlineDescriptions is set to
true, the template dialog will use a larger format.
Bug: T273971
Change-Id: Iad3c3f4d65125c83e35414ce15f793f6a1b192ef
This was used when we used to pass API errors to showMessage, but
is now unused by the two remaining users (missing edit summary, and
"press ctrl+enter to submit").
Change-Id: I8a6b4db78d4e451cf3ec85fcdfd8293328aaaa3c
Reference images are moved to Cite and used by Citoid.
Bug: T170919
Bug: T171292
Depends-On: I02041246dda1b3d3ad1bcc0b014fa022e8259b62
Change-Id: Id97659ed1fa64a1223a8957fefaf2a149edd0e9c
The MWParameterSearchWidget that shows a list of all available
template parameters displays the (human-readable) label and
description of each parameter (both given via <templatedata>), as
well as the parameter's internal name and aliases, if there are
any.
This turns out to be non-helpful in the majority of situations:
* When there is no <templatedata> yet, there are no labels.
Instead, the names are used as labels, which means they are
*all* identical and everything is shown twice.
* The same happens when manually adding an "unknown field". Simply
start typing, and you can add parameters with any name. What you
type is shown twice (actually 3 times, 1 time in the input
field, 2 times in the result widget).
* Many template parameters are already nice, human-readable. Even
if <templatedata> exists and specifies labels, these labels are
often identical to the names. There is no need to come up with
something else if the name is already good enough. (Exception:
Localizations, but these are rare.)
Furthermore, this is a *search* result widget. The pretty much
only reason the names and aliases are shown is because the user
can search for them, and needs to understand why a parameter was
found. This still works fine.
For comparison, when a parameter is required you will *never* see
it's name, because the parameter is always there, and never shows
up as a search result.
Change-Id: I6b1dca1c94b2c496930b5bfdfe1c6f76898faa2a
The interface has enough space for 2 or 3 lines of text.
(On mobile, the button has only an icon and no label.)
Bug: T260074
Change-Id: I50b08029f843e91d10b8c81985f6dfacbb96c8e7
By default, many browsers permit resizing the textarea in both
dimensions; however, the SaveDialog doesn’t handle horizontal resizing
very well (the textarea is no longer centered and the options don’t
adapt to the new width), so add some CSS to limit the resizing to
vertical only.
Change-Id: I91bf63357237ddc2e3ede8e661480ab0cb48d10e
While we pretend that the ConfirmEdit CAPTCHA support is added by
ve.init.mw.CaptchaSaveErrorHandler in the ConfirmEdit extension,
we still have a bunch of code here required for it to work.
This commit removes some of it, no longer needed after
I6605017fd31a4f96c529dd0beb69e9f4433cebc1.
Depends-On: I6605017fd31a4f96c529dd0beb69e9f4433cebc1
Change-Id: I41e032fd754927b7ea6cfb767eb9f21b522ccacd
New changes:
77076f828 LinkAnnotationInspector: add a "label" field on mobile
Local changes:
* Updates for mobile link label editing
Bug: T229431
Change-Id: Ib0489f6f59b228ebc4a20f7a0a515be938a8f6d3
New changes:
62f06382c Localisation updates from https://translatewiki.net.
5fc25c0d9 LinkContextItem: Apply ellipsis directly to link
Local changes to fix link ellipsis styles.
Bug: T230267
Depends-On: I25bb4fa9b7288232b08bab9c88f281817a26d6bb
Change-Id: I8a4b04d45979a1f6c375a7c92a340e3e81d7753c
New changes:
28aea2e4d Edit cards v2 design
739017973 Track usage of the new "close context" button
Local changes:
* Edit cards v2 pull through
Bug: T222396
Change-Id: I1ca885e8d8127e7827a059755315ed789a7b9210
Since I7f6fd7ee9 it is now possible for the options bar to be
completely empty if the user is logged out. In this case hide
it and only show it again when the character limit needs to be
show.
Ideally we wouldn't have the height change, but it is quite rare
that a user gets to 400 chars and is logged out.
Bug: T228165
Change-Id: Ifbdf352afcbf4e549889e04fdb70fd30ce233aad
New changes:
6515e03e1 ve.ce.Surface: Rearrange #findBlockSlug test to check other cases
cbfdc8570 Localisation updates from https://translatewiki.net.
708ba0557 Prevent block slugs from overlapping floated elements
3703fd66d Separate the concept of a document node and a root node in CSS
Bug: T211844
Change-Id: Ia86cf9b23e561d3c32601d41c1bc5a9824e9953c
Was removed upstream in OOUI, but we require it to
show that parameters are deprecated.
Resize to fit new 12x12 size for indicators.
Change-Id: I2356de0754a2ccf09b87b152f3023282f2e37f41
Now when using the MonoBook skin, the text size for headings inside the dropdown is the same as their size on the page.
Bug: T72559
Change-Id: Ie0c30369021f8022b788730a6de90e44a288b13b
Reasons why these files should not be in a directory named "themes/":
* They are specific to MediaWiki skins, not OOUI themes
* They are specific to one module, rather than affecting many widgets
The new locations/filenames are consistent with other modules that
have skin-specific styles.
Note that we have one more themes/ directory elsewhere in this repo
(and another in VE core) and that is okay.
Bug: T96704
Change-Id: I70bb61e339aeccb3afea657f665785ceaa091777
This rule was being overridden by a more specific rule from OOUI with
the selector `.oo-ui-fieldLayout.oo-ui-labelElement`. I don't think
the margin tweak would be useful.
Change-Id: If6321ba7ea1cfad83f65f137b2a440957bf2fea6
Also make improvements to the layout, so that the dialog works
in desktop and mobile - most importantly, change from booklet
to index layout.
Bug: T190885
Bug: T118710
Change-Id: I1915d06c9b0e4b7907136e645f60be96e30cc287
We relied on some white space baked into the background-image
to "reserve the space" for the text. If we tried to make the image
smnaller, the text would start overlapping it.
Remove 100px of vertical white space from the image files, adjust
the styles so that text is displayed below the image rather than
overlapping it.
Bug: T191095
Change-Id: I2f19128a2044b3505cdea93c3f587fe62553071d
T190570 (I54d75ab6061de0de79b7a8112eb859a4c8a5e22a) changed old editor's
display of the limit to only show when there's <= 99 remaining. Bring same
behavior into this dialog.
Bug: T194458
Change-Id: I7f6fd7ee95348c39b107131a7e297d158a07c00e
Also allow preview elements to existing with an mw-body-content
area withouth the font size being applied twice.
Depends-On: Ibbf989dcebf2d21fd2ac481f17062f366ff29e41
Change-Id: I284bcd5dd25cdbb883427ebacb41af1bbf50b60f
Remove the image size styles from the class
.ve-ui-mwInternalLinkContextItem-hasImage too
Bug: T97631
Follow up: I84edeec38ecfb90f5d53
Change-Id: I39937bf4ba12f7047545b187c54a1c5fae157e4a
Removing `0.8em` VE special base `font-size` for UI as we're unifying
OOUI interfaces to `14px` equals to `0.875em` at user agent default size.
Bug: T97631
Depends-on: I693d168d2ccf2babbcfe8952af3e1c262aa97773
Change-Id: I84edeec38ecfb90f5d53199f3b26fc3f83ab0611
Set viewBox to "2 2 20 20" to trim 2px off each side of our
existing 24px icons, therefore aligning them to the new 20px
grid. All of them had been drawn with large margins, so none
of the graphic is lost.
Bug: T177432
Bug: T190151
Change-Id: I23a6daa5dc2d4a9afc50f275da5df370d2319277
Align SVG markup across Foundation products by:
- unifying XML declaration,
- removing unnecessary `standalone="no"` attribute as it's default,
- removing all SVG editor metadata
- removing all `g` group elements except where necessary for transforms,
- putting attributes on `path`,
- removing unnecessary ids and
- unifying whitespace.
Saving up to 23% file size before gzipping.
Bug: T178867
Change-Id: If0339073a12f24df1a0f8dcc110c35e0ee2d38a7
OOUI 8e31b2f273 increased changed various icon CSS rules, and increased their
specificity. Increase ours to match. This restores the correct size/ratio of
the images in the link context item.
Bug: T178933
Change-Id: I4f1a6dde363cf99f7665dc83f4b0fa6b1dd3c29e
Also:
* Disconnect change event on this.input, which doesn't
get destroyed on teardown
* Add padding between attributes and this.input
* Assume the alien extensions can have a rendering when
their body is empty.
Bug: T177181
Bug: T177183
Change-Id: I2e59f8195b255f33f91901213c92ea14793635b4
We still expect the user to click on the tool, and
the actions still works (albeit delayed), so we
should use cursor:pointer.
Change-Id: I6d2b0140f5fd918809f05acc6e405ef430c518fd
Since "nbsp" is hard to translate, it is removed from the current
text of visualeditor-mwlanguagevariantcontextitem-rule-code-label,
which was "Language code" - now changed to "Language code".
Instead the table headings (where this message is used) are defined
as non-breaking in CSS.
Bug: T173181
Change-Id: I9794fa010ad908fe772fa6858c25acc6beb973d5
We can place them in bottom center of the toolbar buttons with
just CSS, no need to manually calculate the position (which
doesn't give the correct results if the toolbar is not visible).
Also add z-index for correct rendering inside TargetWidget,
not overlapped by the toolbar border (e.g. in the media dialog).
Bug: T174120
Change-Id: I556ddfcf252669107cf21810fbed7c9a3751e906
New changes:
26085a853 Make author list a ListPopupTool
c4ea53eef Update OOjs to v2.1.0
8c94697f3 Update OOjs UI to v0.22.0
cdebc4817 Follow-up 8c94697f: Actually commit the icon changes I had locally
8be817396 Update OOjs UI to v0.22.1
Local changes for author list popup
Change-Id: I36bcaf122528a4a12882aaff3b33ef936082a391
* Fix focus and resize/scroll into view after the
captcha has loaded (so after the image has loaded
for FancyCaptch).
* Add margin between input and captcha
* Enable enter-to-submit on captch input field.
* Unify code for simple/math/questy and correctly
render math as HTML (by looking at the mime type)
Change-Id: I10433cefbfea8569674c120dde5b489570e20966
OOjs UI v0.21.0 changed DraggableElement's padding. Override it here, so it doesn't look broken any more.
Bug: T163404
Change-Id: Ic0bc4f9e3e060cf89e6bc7cb22068d1fe1441d75
* Pass a wikitext promise, instead of wikitext
* Handle writing of content to the dialog from within
the dialog.
* Handle diff errors within the dialog.
* Never disable the 'Return to save form' (approve) button
* Remove redundant messages
Change-Id: Ibd76e8951998f751abfb4f407682202c2f73ac7e
This gets overridden by "selectorWithoutVariant" and "selectorWithVariant"
in the module definition anyway.
Change-Id: I51b8e76d542058c008d92ce55c7ec6bb66df70b7
The floating tooltip breaks inside OOUI dialogs. In the absence
of an upstream fix, just anchor it to the bottom of the textbox.
Bug: T160245
Change-Id: I9055c4e4947f5581605bd490f076415c1edaf8ec
After 79ccfb9372cb57afa569036ef39ead13abfba673, MediaWiki's `<pre>`
tags get rendered as `<pre typeof="mw:Extension/pre">` in Parsoid HTML.
MediaWiki's indent-pre syntax (block indented by a single space) is
still rendered as `<pre>` in Parsoid HTML, however.
Indent-pre is still handled by MWPreformattedNode (no changes).
Introducing MWPreNode, which will handle `<pre>` extension tags,
and MWPreDialog to change its contents (and allow converting
to MWPreformattedNode).
Pieces copied from MWGalleryNode, MWLinkNodeInspector, CommentInspector.
Possible future improvements:
* Add a specific icon for MWPreContextItem
* Avoid API roundtrips for rendering (but rendering wikitext <pre>
is not as simple as it looks)
* Consider a way to insert these other than '<pre' sequence
Bug: T159900
Change-Id: I5bc4ea6e5d893736f65ef0dd43b08c18cb1a1e85
This is currently used to display a warning about missing edit summary
and to display a CAPTCHA field. They now appear in a separated area at
the bottom of the dialog, which slides into view when a message is
added.
Change-Id: I7541284a92d5fd2fa8f469d479e059098c59c0ac
Align the colors used in the save dialog to OOjs UI's MediaWiki theme,
increasing the contrast of edit summary counter slightly to ensure WCAG
AA accessiblity levels. Also remove unnecessary duplicated CSS
properties, which are already inherited from OOjs UI styles.
Bug: T153086
Change-Id: Iee6b38e0b11f777dd0ffb0f6802d0b3d7349ddee
Make sure the button is always visible in the
gallery dialog menu by fixing it to the bottom.
Bug: T151506
Change-Id: I560b0dffbaad9e18c6f7f703cb155356470580ee
Aligning instances of `progressive` color to WCAG 2.0 level AA compliant
color palette similar to changes in
I6fdb90af8b9dc5e5e026eb0c1bd13138c73da4cd
Change-Id: I2eda190f0a68de6dc8aa33724f2c8975327a061f
This gets us the variants (which we need for OOUI 0.17.9); note that I've
cheated and used 0.17.9's colour for the MediaWiki theme's progressive flag
rather than 0.17.8's value of 347bff.
Change-Id: Ic436970e9298ea31f48c6cfdd04b80847aaebbee
Make new graphical interface for editing existing
galleries and adding new galleries.
NB The dialog does not yet support rich text in the
image captions, nor does it provide separate fields for
e.g. link, alt text, etc. These are dependent on parsing
the text within the tag, which is yet to be implemented
by Parsoid. For now, these attributes should be
specified in wikitext in the image-specific caption
field.
Bug: T45037
Change-Id: I2b4082e991268241a15b9bbd6d85c94cdc2185f2
The editor can also be used on wikis that are not Wikipedia.
By the way, the logo was incorrectly flipped for the RTL version. Heh.
Bug: T135811
Change-Id: I5635da13e8335658079620a46ac265c4ed6bd167
New changes:
c54a48a build: Fix watch list (csslint -> stylelint)
58ba3d9 Add stylelint rules for @-rules
3f8c75a Stylelint: Add rule for unsupported browser features
3b96ff3 Fix minimum Opera version (15 -> 12)
9a1110b Stylelint: No ID selectors
9800bb8 build: Remove remaining references to csslint
b6ab14a stylelint: Re-enable features by names
6cc1f3c Move stylelint to npm
1d15fa0 build: Bump stylelint version to v0.2.0
ccc1724 stylelint: Use the preset rather than extending
Change-Id: I22fa8098592338a5e912aba9ad21131b21d9c0ea
For now just use the rules file in lib/ve, but eventually
this will be a preset.
Change-Id: I7fd79d3e1dce37aef066d416cd969e5fff1e962f
Depends-On: I17e0d23ddfedf64985495ab35d113ea08c03b1df
This makes it degrade to a small dot instead of a huge dot in
browsers which don't support animation (IE9).
Change-Id: Ia457b3caf35ff0ffe7287b2b1e395860d5dbd7d0
* Use TitleInputWidget for wiki-page-name and wiki-template-name parameters
* Use UserInputWidget for wiki-user-name parameters
* Use a custom hacky CheckboxInputWidget child class for boolean parameters
* Borrow some ve.ui.MWExternalLinkAnnotationWidget.prototype.createInputWidget code for url parameters
* Use a TextInputWidget with multiline disabled for line parameters
Not dealt with in this commit, so fallback to existing behaviour:
* string
* number
* unknown
* content
* unbalanced-wikitext
* date
* wiki-file-name
Bug: T55613
Bug: T124734
Bug: T124736
Change-Id: If04944d64303d959e8dd605e75a175895932b788
Depends-On: I87699a93ca1b34c6d248456fcc060f584623d158
Depends-On: I5e97604f0fc24176d5e89899bf0505dc442a1a7e
Make the DOM order sensible so we don't have to
use SearchWidget's position:absolute hacks.
Bug: T129173
Change-Id: I3517e0e0cfe2ab0eee4bed7390e41710d3140eb0
