Commit graph

34 commits

Author SHA1 Message Date
Trevor Parscal 4192cbc4d5 Window refactor
Changes:

* Cleanup the window API to use more consistent and intuitive methods - we
  now use initialize/setup/teardown instead of
  initialize/onSetup/onOpen/onClose as methods which are overridden, and
  use open/close methods to control the window
* Change events around to have opening/open and closing/close events which
  act as before/after points during the opening/closing process
* Make WindowSet and Context respond to windows being opened, rather than
  opening them directly
* Fix a LinkInspector creation mode bug where the initial text doesn't get
  reset
* Move inspector, a VisualEditor concept, back to VE
* Cleanup naming of SurfaceDialog, SurfaceToolbar, etc. to use shorter
  names, they were given Surface* names when the generic ones were also in
  VE, but now the generic ones are in OO, so they can return to their
  original names

Change-Id: I82c4fed8bcb3fb5630938c8bc4dd9b2d5f1a8c1d
2013-11-08 12:33:25 -08:00
Trevor Parscal d2dfb9ac4f Split oojs-ui from ve.ui
* Move and rename generic parts of ve.ui to OO.ui
* We now have a UI test suite because ve.Element (outside ve.ui)
  is now part of oojs-ui, so it needs a test suite.
* Added to the MW test run (just like we do for unicodejs).
* Updated csslint config (also added ve-mw and syntaxhighlight
  which were missing).

oojs-ui still depends on the TriggerRegistry in VE, this is addressed
in a follow-up commit.

Change-Id: Iec147155c1ddf20b73a4d15d87b8742207032312
2013-10-28 22:40:08 -07:00
Ed Sanders 3077be6d9c Remove -ms-transition
Because it never existed.

Change-Id: Iaae7e8f11efb0a9853130bcdad8b643c06a1eed8
2013-10-16 15:32:04 +00:00
Trevor Parscal bb03e8f17e Misc UI fixes
* Followup 75270e24: use this.surface directly in MWMetaDialog
* Document that MWDialogTools need a SurfaceToolbar
* Namespace CE events and CSS classes with ve-ce- rather than ve-ui-
* Namespace SurfaceToolbar CSS classes correctly and put them in their
  own CSS file

Change-Id: I9e70917d9c220b39e68833f67ed49fae7f7cbe6a
2013-10-16 12:40:40 +02:00
Trevor Parscal 6ec34a3dee Toolbar action widgetization and UI refactoring
Objectives:

* Use widgets to render toolbar actions
* Remove labels next to help notices and edit notices buttons
* Add a close button to the help notices and edit notices

Overview:

* ve.ui.ButtonWidget is now abstract, use ve.ui.PushButtonWidget instead
* ve.ui.IconButtonWidget now inherits from ve.ui.ButtonWidget
* ve.ui.PopupWidget's display method no longer takes x and y arguments
* Fixup naming issues in MWCategoryPopupWidget
* Fixup naming issues with some ve-init-mw CSS classes
* Rename ve-mw/ui/styles/ve.ui.Widget.css to ve.ui.MWWidget.css
* Change uses of "callout" to "tail"
* Add hyperlink functionality to buttons
* Make buttons accessible through focusing, but make unfocusable by
  clicking
* Add head option to popup for rendering a title and close button

Bug: 52386
Change-Id: Iea2c8df1be64d40f9c039873d89ee540cc56e687
2013-10-04 16:26:13 -07:00
Trevor Parscal 2717ea1645 Add ve.ui.ToolGroup and use within toolbar setup
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
2013-08-07 05:08:20 +00:00
Trevor Parscal 9426dfd54b Cleanup tool styles
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
2013-08-07 05:08:08 +00:00
Timo Tijhof 14343c7bf7 ve.ui.Toolbar: Refactor floating logic for performance
== Renamed methods ==

* enableFloating  -> enableFloatable
* disableFloating -> disableFloatable
* setPosition     -> float
* resetPosition   -> unfloat

== Scroll and resize event ==

Timeline for scroll event reduced from about half a dozen
"Recalculate style" and various forced "Paint" down to 0.

New timeline for scroll is clean (for me: from ~35 to ~59 fps):
* 1 Event (scroll)
* 1 Composite Layer

The composite layer action is the browser changing the viewport
to a different portion of the document drawing. Exactly the one
thing a simple scroll should do.

Timeline for resize event is still pretty crowded and low fps,
but it has improved. Further improvement would likely be around
using requestAnimation and going outside ve.ui.Toolbar.

== Changes ==

* New: ve.ui.Toolbar#initialize.
  Similar to what surface has. Users of Toolbar should decide
  whether to call enableFloatable, append it to the DOM at some
  point and then call initialize() once.

* Don't compute offset() every time.
  Eliminated by doing it once in #initialize. These 'top' and
  'left' offsets do not change.

* Don't compute outerWidth() and $window.width() every time.
  Reduced by doing it once in #initialize to compute the 'right'
  offset. Updating it only on resize.

* Don't set 'top' every time.
  This is already in the stylesheet. It was never set to anything
  else so the abstraction for it in #float has been removed.
  This also made it obvious that code for "ve-ui-toolbar-bottom"
  was unused and left behind. Tha class was only ever being
  removed from something (never added).
  The one addClass call for it was in a condition that is always
  false ("if top > 0").

* Don't set 'left' every time.
  Eliminated by doing it once in #float.

* Don't set 'right' every time.
  Reduced by no longer doing it on scroll. Done once in #float,
  and on resize after computing the new value for it.

* Remove no-op style operations.
  Wrapped methods in if-floatable, if-floated etc. to reduce a
  fair amount of easily avoided re-paint overhead.

* Avoid double re-paint in mw.ViewPageTarget.
  Though we prevent a lot of redundant re-paints now, whenever
  we do repaint we want to do it in 1 repaint instead of 2.

  ve.ui.Toolbar emits #toolbarPosition, which tells
  mw.ViewPageTarget to update toolbarTracker which would read
  the new $bar style properties and copy them over to the
  $toolbarTracker. However, this read operation forces the browser
  to do an immediate re-paint half-way just for $bar.

  Browsers only repaint when style properties are changed and
  JS has yielded. The exception to this is JS reading style
  properties: in that case the browser is forced to do those
  deferred repaints directly and reflect the new values.

  We can avoid this double repaint by passing the updated values
  as data instead of requiring the receiver to read the DOM (and
  thus a keep the deferred repaint). Now toolbarTracker can use
  them directly whilst the browser hasn't even repainted $bar yet.

== Clean up ==

* Redundant "border-radius: 0". This would reset something, but
  it never does. None of the things it inherits from set a
  border-radius. There is one subclass where toolbar is used
  with a border-radius (".ve-ui-surfaceWidget .ve-ui-toolbar-bar"
  sets a border-radius) which overrides this on purpose, so the
  default of 0 is redundant.

* Pattern "if ( .. ) addClass() else removeClass()" changed to:
  "toggleClass( , .. )"

Bug: 52014
Change-Id: I9be855148962eee068a77fe83e98eb20bbdcfeec
2013-07-30 01:47:54 +02:00
Rob Moen 25b937c496 Adjust toolbar group margins for equal vertical alignment
Change-Id: I4596e50c941b1cb628f2ccba983d4b60b7939174
2013-07-11 11:22:45 -07:00
Trevor Parscal 9297f33989 Tool and context menu size and alignment fixes
Objectives:

* Make context menu toolbar consistently sized and aligned, especially
  in monobook

Changes:

ve.ui.Toolbar.css
* Remove vertical line between groups, just use whitespace
* Switch from padding to margins to avoid size calculation issues

ve.ui.Tool.css
* Remove tiny margin on button tools, tightening them up a bit
* Replace 50% 50% with center center

ve.ui.Context.css
* Switch from padding to margins to avoid size calculation issues
* Use different margins depending on text direction
* Reverse the 0.8em rule used in the dialog - this is a hack, it should
  be cleanup up later with a better strategy for normalizing the size
  of text within VE elements

Change-Id: If65f12382625efa33777e284bd23a94dc509436a
2013-07-10 01:33:37 +00:00
Trevor Parscal 461e518fca Remove dead CSS code
Reference counting indicates these styles are not in use, so they can now be safely garbage collected.

Change-Id: I432f73490eeb00ff414f150fcf26c718607bac95
2013-07-10 01:32:57 +00:00
Niklas Laxström 96b7dbacb5 Moved embed statement where it does something
Followup to Ibdc2410cc

Change-Id: I5e665f5d720366650c362ed603693a223c96ee77
2013-07-05 09:47:12 +00:00
Inez Korczyński b0b832a796 Make toolbar look correct with non-standard browser font size settings
Assumption about toolbar height never exceeding 88px is not correct. At
least in Chrome, after setting in advanced configuration font size to
"Large" instead of "Medium", the toolbar's height is 110px and part of it
is transparent. Because it is transparent user can see content behind it
when scrolled down, which makes for a not really good experience.

Change-Id: Ibdc2410cc4ab29bfe774961fc062d172386975d4
2013-06-30 19:46:00 +00:00
Trevor Parscal c2196b1fe7 Remove use of filter property for CSS opacity
Was used for IE8 support, no longer needed.

Change-Id: I1e7a1e676022dd7607c808bd44848cbf22a9e958
2013-06-25 16:44:06 -07:00
Trevor Parscal 2e76271b4e The Great ve.ui.Surface refactor of 2013
Prologue:

Farewell ve.Editor my good chap… Oh, hey there HTML frames - I didn't
see you there! In a world where iframes are outlaws, and symbols like
document and window are global, there were more than a few assumptions
about which document or window was being used. But fear not - for this
commit (probably) tracks them all down, leaving a trail of
iframe-compatible awesomeness in its wake. With the great ve.ui.Surface
now able to be used inside of iframes, let the reference editing
commence. But there, lurking in the darkness is a DM issue so fierce it
may take Roan and/or Ed up to 3 whole hours to sort it out.

Note to Roan and/or Ed:

Editing references seems to work fine, but when saving the page there
are "no changes" which is a reasonable indication to the contrary.

Objectives:

* Make it possible to have multiple surfaces be instantiated, get along
  nicely, and be embedded inside of iframes if needed.
* Make reference content editable within a dialog

Approach:

* Move what's left of ve.Editor to ve.ui.Surface and essentially
  obliterate all use of it
* Make even more stuff inherit from ve.Element (long live this.$$)
* Use the correct document or window anywhere it was being assumed to be
  the top level one
* Resolve stacking order issues by removing the excessive use of z-index
  and introducing global and local overlay elements for each editor
* Add a surface to the reference dialog, load up the reference contents
  and save them back on apply
* Actually destroy what we create in ce and ui surfaces
* Add recursive frame offset calculation method to ve.Element
* Moved ve.ce.Surface's getSelectionRect method to the prototype

Bonus:

* Move ve.ce.DocumentNode.css contents to ve.ce.Node.css (not sure why it
  was separate in the first place, but I'm likely the one to blame)
* Fix blatant lies in documentation
* Whitespace cleanup here and there
* Get rid of ve.ui.Window overlays - not used or needed

Change-Id: Iede83e7d24f7cb249b6ba3dc45d770445b862e08
2013-05-24 14:01:02 +02:00
Timo Tijhof 917fbc6f30 ve.ui.Toolbar: Clear the float before the toolbar
On wikis where certain "topicons" exist the toolbar showed a
weird blank space pushing the entire toolbar down and
ve-ui-toolbar-actions to the left.

Bug: 48734
Change-Id: Ic5f73ac1eb8c41b891dd1c67b71795cb6c456141
2013-05-23 01:07:51 +02:00
Trevor Parscal a56e795f58 ve.Editor
Objectives:

* Split ve.Surface into ve.Editor and ve.ui.Surface
* Move actions, triggers and commands to ve.ui
* Move toolbar wrapping, floating, shadow and actions functionality to configurable options of ve.ui.Toolbar
* Make ve.ce.Surface and ve.ui.Surface inherit ve.Element and use this.$$ for iframe friendliness
* Make the toolbar separately initialized so it's possible to have a surface without one, as well as control where the toolbar is

Some change notes:

VisualEditor.php
* Added standalone module for mediawiki integrated unit testing

ve.ce.Surface.js
* Remove requirement to pass in an attached container to construct object
* Inherit ve.Element and use this.$$ instead of $
* Make getSelectionRect iframe friendly
* Move most of the initialize stuff to a new initialize method to be called after the surface is attached to the DOM

ve.init.mw.ViewPageTarget.js
* Merge toolbar functions into setup/teardown methods
* Add toolbar manually (since it's not added by the surface anymore)

ve.init.sa.Target.js
* Update new init procedure for editor, surface and toolbar separately
* Move toolbar floating stuff to ve.Toolbar

Change-Id: If91a9d6e76a8be8d1b5a2566394765a37d29a8a7
2013-05-15 10:39:12 -07:00
Trevor Parscal 4ee9e1f28d Get back to where you once belonged
The toolbar has a high z-index when being floated, it doesn't need one
otherwise. This was causing an issue where the Vector actions drop-down
menu was being obscured.

Change-Id: I3c0ff7c4cf3b4a6c3d94f00ef56d7f299aeb6020
2013-04-29 22:59:46 +00:00
Trevor Parscal 949722c392 Toolbar actions not floating
Spurious semi-colon caused class to not be parsed, making toolbar actions not float right

Change-Id: I1ef88358908002cd7feb8c02b5da80d4f1ffe46d
2013-03-14 16:47:23 -07:00
Trevor Parscal 1572ec1569 Context, frame, window, dialog and inspector refactor
This is a major refactor of user interface context, frame, dialog
and inspector classes, including adding several new classes which
generalize managing inspectors/dialogs (which are now subclasses
of window).

New classes:
* ve.ui.Window.js - base class for inspector and dialog classes
* ve.ui.WindowSet.js - manages mutually exclusive windows, used
  by surface and context for dialogs and inspectors respectively
* ve.ui.DialogFactory - generates dialogs
* ve.ui.IconButtonWidget - used in inspector for buttons in the head

Refactored classes:
* ve.ui.Context - moved inspector management to window set
* ve.ui.Frame - made iframes initialize asynchronously
* ve.ui.Dialog and ve.ui.Inspector - moved initialization to async
  initialize method

Other interesting bits:

ve.ui.*Icons*.css, *.svg, *.png, *.ai
* Merged icon stylesheets so all icons are available inside windows
* Renamed inspector icon to window

ve.ui.*.css
* Reorganized styles so that different windows can include only
  what they need
* Moved things to where they belonged (some things were in strange places)

ve.init.Target.js, ve.init.mw.ViewPageTarget.js, ve.init.sa.Target.js
* Removed dialog management - dialogs are managed by the surface now

ve.ui.*Dialog.js
* Renamed title message static property
* Added registration

ve.ui.*Inspector.js
* Switch to accept surface object rather than context, which conforms
  to the more general window class without losing any functionality
  (in fact, most of the time the surface was what we actually wanted)

ve.ui.MenuWidget.js, ve.ui.MWLinkTargetInputWidget.js
* Using surface overly rather than passing an overlay around
  through constructors

Change-Id: Ifd16a1003ff44c48ee7b2c66928cf9cc858b2564
2013-03-14 00:03:31 +00:00
James D. Forrester 82114467f1 Bump copyright notice year range to -2013 over -2012
199 files touched. Whee!

Change-Id: Id82ce4a32f833406db4a1cc585674f2bdb39ba0d
2013-02-19 15:37:34 -08:00
Trevor Parscal 8d33a3de0d Major Documentation Cleanup
* Made method descriptions imperative: "Do this" rather than "Does this"
* Changed use of "this object" to "the object" in method documentation
* Added missing documentation
* Fixed incorrect documentation
* Fixed incorrect debug method names (as in those VeDmClassName tags we add to functions so they make sense when dumped into in the console)
* Normalized use of package names throughout
* Normalized class descriptions
* Removed incorrect @abstract tags
* Added missing @method tags
* Lots of other minor cleanup

Change-Id: I4ea66a2dd107613e2ea3a5f56ff54d675d72957e
2013-01-16 15:37:59 -08:00
Timo Tijhof b11bbed7a6 JSDuck: Generated code documentation!
See CODING.md for how to run it.

Mistakes fixed:
* Warning: Unknown type function
  -> Function
* Warning: Unknown type DOMElement
  -> HTMLElement
* Warning: Unknown type DOM Node
  -> HTMLElement
* Warning: Unknown type Integer
  -> Mixed
* Warning: Unknown type Command
  -> ve.Command
* Warning: Unknown type any
  -> number
* Warning: Unknown type ve.Transaction
  -> ve.dm.Transaction
* Warning: Unknown type ve.dm.AnnotationSet
  -> ve.AnnotationSet
* Warning: Unknown type false
  -> boolean
* Warning: Unknown type ve.dm.AlienNode
  ve.dm doesn't have a generic AlienNode like ve.ce
  -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode
* Warning: Unknown type ve.ve.Surface
  -> ve.ce.Surface
* ve.example.lookupNode:
  -> Last @param should be @return
* ve.dm.Transaction.prototype.pushReplace:
  -> @param {Array] should be @param {Array}
* Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member
  -> (removed)
* Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member
  -> (removed)

Differences fixed:
* Variadic arguments are like @param {Type...} [name]
  instead of @param {Type} [name...]
* Convert all file headers from /** to /*! because JSDuck tries
  to parse all /** blocks and fails to parse with all sorts of
   errors for "Global property", "Unnamed property", and
  "Duplicate property".
  Find: \/\*\*([^@]+)(@copyright)
  Replace: /*!$1$2
* Indented blocks are considered code examples.
  A few methods had documentation with numbered lists that were
  indented, which have now been updated to not be intended.
* The free-form text descriptions are parsed with Markdown,
  which requires lists to be separated from paragraphs by an
  empty line.
  And we should use `backticks` instead of {braces} for inline
  code in text paragraphs.
* Doc blocks for classes and their constructor have to be
  in the correct order (@constructor, @param, @return must be
  before @class, @abstract, @extends etc.)
* `@extends Class` must not have Class {wrapped}
* @throws must start with a {Type}
* @example means something else. It is used for an  inline demo
  iframe, not code block. For that simply indent with spaces.
* @member means something else.
  Non-function properties are marked with @property, not @member.
* To create a link to a class or member, in most cases the name
  is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux,
  where a hash stands for "instance member", so Foo.bar#quux,
  links to Foo.bar.prototype.quux (the is not supported, as
  "prototype" is considered an implementation detail, it only
  indexes class name and method name).
  If the magic linker doesn't work for some case, the
  verbose syntax is {@link #target label}.
* @property can't have sub-properties (nested @param and @return
  values are supported, only @static @property can't be nested).
  We only have one case of this, which can be worked around by
  moving those in a new virtual class. The code is unaltered
  (only moved down so that it isn't with the scope of the main
  @class block). ve.dm.TransactionProcessor.processors.

New:
* @mixins: Classes mixed into the current class.
* @event: Events that can be emitted by a class. These are also
  inherited by subclasses. (+ @param, @return and @preventable).
  So ve.Node#event-attach is inherited to ve.dm.BreakNode,
  just like @method is.
* @singleton: Plain objects such as ve, ve.dm, ve.ce were missing
  documentation causing a tree error. Documented those as a
  JSDuck singleton, which they but just weren't documented yet.
  NB: Members of @singleton don't need @static (if present,
  triggers a compiler warning).
* @chainable: Shorthand for "@return this". We were using
  "@return {classname}" which is ambiguous (returns the same
  instance or another instance?), @chainable is specifically
  for "@return this". Creates proper labels in the generated
  HTML pages.

Removed:
* @mixin: (not to be confused with @mixins). Not supported by
  JSDuck. Every class is standalone anyway. Where needed marked
  them @class + @abstract instead.

Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-05 01:16:32 +01:00
Trevor Parscal cab7f84b55 Fixed line-height variations between sa and mw integrations
* Also fixed format drop-down's preformatted label styling

Change-Id: I983ff71959f5e78e52fbe4c585db20357b7ca2d5
2012-11-06 10:24:58 -08:00
Trevor Parscal 238feeb881 Tools changes
* Rewrite of all tools, dramatically simplifiying them and decreasing
  duplication
* Tools are now created using a tool factory instead of
  a make-shift facility built into the toolbar
* All UI object have a surface or a toolbar reference instead of a
  surface view

Change-Id: I589ecba36bf715b452d03c8fd5c0547dc3c1dc61
2012-10-26 14:48:27 -07:00
Trevor Parscal b370bbd0bc Improved icons
* Moved icons into Illustrator (used to be in Photoshop)
* Added SVG icons too
* Added support for devices with pixel ratio > 1 (they use SVG)
* Cleaned up icons (little rendering errors here and there)
* Organized icons into their own folder
* Increased the horizontal margin of the down arrows in the formatting (in the toolbar) and location (in the link inspector) drop down menus

Change-Id: I29b7084c9b1145051b2a76f514cfca9826d53ddb
2012-08-31 13:23:04 -07:00
Trevor Parscal a52d7ff65a Finally getting rid of all the es-* stuff and other cruft
* Switched a lot of classes from es-* to ve-ui-*
* Removed all the DOM structure left over from the old sandbox demo
* Got rid of transparent backgrounds
* Added menu font-size rule to stand-alone target
* Moved some rules around that were in the wrong places
* Got rid of some unused/unneeded methods in the mw target (attach and detach surface methods)
* Added active class to context icon with shallower shadow effect so it doesn't break your spacial perception when you click on it
* Renamed the iframe and iframe wrapper elements so it's easier to see where they came from
* Removed unused CSS rules
* Fixed some uses of prop( 'class', … ) to addClass

Change-Id: I54a660ca0baf0baa4463faca7a1edcf648130b6b
2012-08-28 13:59:35 -07:00
Timo Tijhof 077e21867e Kranitor #3: jQuerlyfornication ft. The Cascaders
* Classicifation (JS)
 Use addClass instead of attr( 'class' ) whenever possible.
 addClass will manipulate the properties directly instead of
 (re-)setting an attribute which (most) browsers then sync
 with the properties.

 Difference between:
 elem.className
 and
 elem.setAttribute( 'class', .. );

 Just like .checked, .value, .disabled and other interactive
 properties, the HTML attributes should only be used for initial
 values from the html document. When in javascript, only set
 properties. Attributes are either ignored or slow.

* Styling (JS)
 Use .css() instead of attr( 'style' ).

 Again, setting properties instead of attributes is much faster,
 easier and safer. And this way it takes care of cross-browser
 issues where applicable, and less prone to error due to dealing
 with key-value pairs instead of css strings.

 Difference between:
 elem.style.foo = 'bar';
 and
 elem.setAttribute( 'style', 'foo: bar;' );

* Finding (JS)
 Use .find( 'foo bar' ) instead of .find( 'foo' ).find( 'bar' ).
 It is CSS!

* Vendor prefixes (CSS)
 It is important to always list newer (standards-compliant) versions
 *after* the older/prefixed variants.

 See also http://css-tricks.com/ordering-css3-properties/

 So the following three:
 -webkit-gradient (Chrome, Safari 4)
 -webkit-linear-gradient (Chrome 10, Safari 5+)
 linear-gradient (CSS3 standard)

 ... must be in that order.

 Notes:
  - "-moz-opacity" is from before Mozilla 1.7 (Firefox < 0.8)
    Has not been renamed to "opacity" since Firefox 0.9.
  - Removed redundant "-moz-opacity"
  - Added "filter: alpha(opacity=**);" where missing
  - Fixed order of css3 properties (old to new)
  - Add standardized css3 versions where missing
    (some 'border-radius' groups didn't have the non-prefixed version)
  - Spacing
  - @embed
  - Shorten hex colors where possible (#dddddd -> #ddd)
    $ ack '#([0-9a-f])\1{5}' --css
    $ ack '#([0-9a-f])\1{2};' --css

Change-Id: I386fedb9058c2567fd0af5f55291e9859a53329d
2012-07-28 13:05:57 -07:00
Rob Moen 3c9a4e7027 Restore arrow-down to original size because it is needed in context menu.
Add element for arrow icon in dropdown tool and new css rules which
support RTL.

Change-Id: I4193f9cac7af7b84cf8400e9bdcbcb4967b57932
2012-07-25 12:18:51 -07:00
Amir E. Aharoni fd0af6541b (bug 38545) Fix RTL position of the drop-down arrow
In RTL interface the drop-down arrow overlaps with the text.

The arrow was positioned explicitly in relation to the left margin, and this
can't work in a flipped RTL environment. I changed the position to "right"
and modified the arrow image a bit.

Some visual tweaks to the arrow may still be needed. Another option can be
to convert the image to SVG or to use a character like ▼.

Change-Id: Ib09a2a20b150de6e8a9531fc0db7dfffe4e95525
2012-07-23 19:27:53 -07:00
Trevor Parscal 6b34f09df2 Removed some whitespace
And added a license to some files that didn't have it yet

Change-Id: I3a7e60374d1198d369a0475b8f65f7415012a337
2012-07-19 14:25:16 -07:00
Trevor Parscal c40174b60c Changed to use MIT license per agreement with the VisualEditor team
This license change is aimed at maximizing the reusability of this code
in other projects. VisualEditor is more than just an awesome editor for
MediaWiki, it's the new editor for the entire internet.

Added license and author files, plus mentions of the license to all
VisualEditor PHP, JavaScript and CSS files. Parser files have not been
modified but are effectively re-licensed since there's no overriding
license information. 3rd party libraries are not changed, but are all
already MIT licensed.

Change-Id: I895b256325db7c8689756edab34523de4418b0f2
2012-07-19 13:25:45 -07:00
Catrope 6afed5e5cc Move ve2/ back to ve/
Change-Id: Ie51d8e48171fb1f84045d1560ee603cee62b91f6
2012-06-19 18:20:28 -07:00
Trevor Parscal 6dcc39fe11 Migrated es.* to new ve.* namespace which is more structured, and will make it easier to keep data model, edit surface, user interface and content editable work separated cleanly 2012-02-06 23:50:56 +00:00
Renamed from modules/es/styles/es.ToolbarView.css (Browse further)