Previously we assumed that embedded icons mean we weren't
dealing with an inspector, but that is not always the case
(e.g. MWExtensionInspector).
Bug: 52845
Change-Id: Ifc5b054568661cb9badf6d7991f512b81e649b36
VisualEditor.i18n.php, VisualEditor.php
* Button title
* New experimental files
ve.*.MWAlienExtensionNode.js
* Very basic extension of ve.*.MWExtensionNode
ve.ui.MWAlienExtensionInspector.js
* Default to inline-block for wrapper. Should probably
get rid of styled wrappers for GeneratedContent eventually.
ve.ui.MWAlienExtensionInspector.js
* Basic extension of MWExtensionInspector. Override title to
use tag name e.g. '<easytimeline>'. Could be changed in future
to 'Extension: easytimeline' or similar.
*.png, *.svg, *Icons*.css, ve.ui.MWAlienExtensionButtonTool.js
* Angle bracket icon for button (open to suggestions)
ve.ui.MWInspector.css
* Make extension inspector text input tall by default.
Change-Id: I07f0686839192cad3cd8dfd3233ae907fe5cdf6a
Roan and I think this is way too light. The only way
I can tell it's a group is by mousing over all of
the icons back and forth really quickly :)
Increasing to 10% alpha.
Change-Id: Iab55bf64921de5247d10d611318e545efe74fe4a
If you had an HTML element that was matched by two models, one with
a direct string match and one with a regex match, then the string
match would beat the regex match (which is correct) if they both
specified a tag name, but the regex match would win (which is wrong)
if they both didn't specify a tag name.
The fix is to only check for tagName === null if we're in tag-agnostic
mode (tag === '').
Change-Id: I9943611111e4c4ff498cdd95b7b3e72f95fb413b
Mostly as a demonstration of how easy this is with MWExtensionNode.
The icon was chosen with the following criteria:
1. Recognisable (the ankh is quite common in popular culture, right?)
2. Doesn't look idiotic to academics (I've consulted an Egyptology
PhD and they can confirm it's not the glyph for penis)
3. Renders well at <16x16
That said it does look a little like a stick man...
Bug: 43118
Change-Id: I9f9e8af501401866bfeecf0eec3690a705fbd4db
MWMath and other simple extensions all behave in a similar way, e.g.
<tagname>Foreign syntax</tagname>.
This creates a base class that should make supporting such extensions,
and editing their contents in a plain text box, very simple.
Change-Id: Icc0acb33fe32704f71dacb552d9dfa3142eaef2b
This allows abstract classes to specify RDFa types based on a static
property overridden by a child class. The default implementation is to
just use .static.matchRdfaTypes.
Change-Id: Ic71fc552a6a1626d94f998e9517af971e8198e79
Objectives:
* Use a class for toolbar groups to add more functionality later
* Rename addTools method to setup
Changes:
*.php
* Add link to new file
* Move ui element classes up for more general use
ve.init.mw.ViewPageTarget.js, ve.init.sa.Target.js, ve.ui.Context.js,
ve.ui.SurfaceWidget.js
* Update use of addTools method
ve.ui.Tool.css, ve.ui.Toolbar.css
* Move styles between sheets
ve.ui.Toolbar.js
* Rename addTools to setup
* Use ve.ui.ToolGroup objects when building tools
ve.ui.ToolGroup.js
* New class, encapsulates tools
Change-Id: Ic3a643634a80a8ac7d6f6f47f031d001c7efaee7
Objectives:
* Make drop down tools look more like buttons and less like inputs, since they aren't text input and are buttons
* Make context toolbars inside surface widgets render correctly
* Show outlines of groups on hover to hint tool relationships
* Make neighboring active tools look cleaner
Changes:
ve.ui.Tool.css
* Merge ButtonTool and DropdownTool styles as much as possible
* Add styles for DropdownTool active states
* Only round the corners of the first and last tool in a group
* Soften the borders between consecutive active tools
ve.ui.Toolbar.css
* Add border to groups on hover
ve.ui.Widget.css
* Isolate surface widget toolbar styles by using stricter selector
ve.ui.Tool.js
* Fix incorrect capitalization of class name
ve.ui.SurfaceWidget.js
* Add classes to toolbar and surface for better style targeting
Change-Id: Ib5ae8f705ef1e9c481e5bdf8c8dcef9c1eb22c4d
Objective:
* Remove ve.ui.DropdownTool's dependency on ve.ui.SurfaceToolbar so it
can be used with any ve.ui.Toolbar
Changes:
ve.ui.DropdownTool.js
* Bind onBlur to document mousedown in capture mode instead of trying to
add more and more things we are listening to which is a losing battle
* Refactor activate/deactivate mode changes
* Get rid of isEnabled check - surface should disable toolbar, the tools
shouldn't be checking if the surface is enabled after the fact (also,
this is harmless and doesn't change any actual interactions)
Change-Id: I738209d17649358c2f9812f9abac576960af867b
I trusted you guys when you told me to use DOM .focus() instead of
jQuery's .focus() and didn't test well enough :( The former doesn't
work, the latter does.
Follow-up to I7962f59b.
Bug: 47793
Change-Id: Iddfb8d7c99325b6c7a5d151948b57cfa5f0a6a62
See ApiVisualEditor.php#parsefragment.
Error code is also incorrectly about Parsoid, method
parseWikitextFragment does a FauxRequest to MediaWiki. Fixed
error.info. Keeping the same error.code for now for consistency.
Bug: 52483
Change-Id: Ic473ae4a5c1e9706140f6ec4cc8157fadd02c318
Objective:
* Make it possible to make a toolbar without a surface
Changes:
*.php
* Links to new file
ve.ui.Toolbar.js, ve.ui.SurfaceToolbar.js
* Split toolbar into generic and surface specific classes
*.js
* Update symbol names
Change-Id: Ice063a2fb67b5ce5155cdc96a0d47af49eee48cb
Follows-up ced2a8a which moved the tab layout to the server-side
and changed it to set up "source" tab and section links always
everywhere (even if VE would not be availabe in the namespace
or browser).
The JS logic (which continues to exist to take care of pages
cached before we moved it to PHP and/or to fix up pages cached
with a different configuration in the future) didn't do this yet
causing the "Edit source" tab to inconsistently appear on pages
for anonymous users viewing pages where VE is not available.
Change-Id: Ic575b3fcef17e636adaa338abc7748a4388ed9a9
This is bit of a hack, as leading whitespace could be
significant if styled with white-space:pre.
Long term VE shouldn't be editing the user's HTML, and
should just highlight potential formatting issues.
We avoid the stripping in preformatted elements as we
expect they will have that styling.
Bug: 51462
Change-Id: I654d98e17dd604cb2a192831ff3f3597f95b9962
Specifically: transclusions, formulae & references.
Captions also allowed to contain other images and reference lists
but we should probably not encourage that.
Change-Id: Ia1c99e51640a3f9ee53281a1e3ebd67dc13c8990
Because trying to work out how broken your test case is
by looking at two (potentially multi-page) serialisations
of the DOM summary is a pain in the arse. Diffing two
HTML strings may highlight the problem much more clearly.
TODO: Is it possible to defer the calculation of the HTML
infused summary object until we have determined the assertion
has failed. Otherwise we're slowing down our tests for no
reason.
Change-Id: I873bf2479ab81d15389792bd59d15580da63941a
Code speaks for itself, see also bug 52441.
Though not introduced by 14343c7bf7, that made the bug worse.
Bug: 52441
Change-Id: Ie2b80b22df03eb563de8812a47fb25152527e786
