mediawiki-extensions-Visual.../modules/ve/ui/styles/ve.ui.Toolbar.css

90 lines
1.7 KiB
CSS
Raw Normal View History

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-04 08:54:17 +00:00
/*!
* VisualEditor UserInterface Toolbar styles.
*
* @copyright 2011-2013 VisualEditor Team and others; see AUTHORS.txt
* @license The MIT License (MIT); see LICENSE.txt
*/
.ve-ui-toolbar {
clear: both;
}
.ve-ui-toolbar-bar {
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-13 00:06:57 +00:00
border-bottom: solid 1px #ccc;
background-color: white;
/* @embed */
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-13 00:06:57 +00:00
background-image: url(images/fade-up.png);
background-position: left bottom;
background-repeat: repeat-x;
padding-bottom: 1px;
line-height: 1em;
}
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-20 22:45:50 +00:00
.ve-ui-toolbar-floating .ve-ui-toolbar-bar {
position: fixed;
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-25 02:36:01 +00:00
top: 0;
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-20 22:45:50 +00:00
z-index: 100;
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-25 02:36:01 +00:00
border-top: none; /* TODO: Do we need this? What does it reset? */
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-20 22:45:50 +00:00
}
.ve-ui-toolbar-bottom .ve-ui-toolbar-bar {
position: absolute;
}
.ve-ui-toolbar-actions {
float: right;
padding: 0.25em;
font-size: 0.8em;
}
.ve-ui-toolbar-tools {
float: left;
}
.ve-ui-toolbar-tools,
.ve-ui-toolbar-actions,
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-13 00:06:57 +00:00
.ve-ui-toolbar-shadow {
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
-o-user-select: none;
user-select: none;
}
.ve-ui-toolbar-group {
display: inline-block;
margin: 0.3em;
vertical-align: middle;
2011-11-30 23:21:17 +00:00
}
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 19:15:23 +00:00
.ve-ui-toolbar-label {
display: inline-block;
2011-11-30 23:21:17 +00:00
padding: 0.5em 0.75em;
line-height: 22px;
font-size: 0.8em;
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 19:15:23 +00:00
color: #555;
vertical-align: top;
2011-11-30 23:21:17 +00:00
}
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-13 00:06:57 +00:00
.ve-ui-toolbar-shadow {
/* @embed */
background-image: url(images/toolbar-shadow.png);
background-position: left top;
background-repeat: repeat-x;
position: absolute;
bottom: -9px;
height: 9px;
width: 100%;
pointer-events: none;
-webkit-transition: opacity 500ms ease-in-out;
-moz-transition: opacity 500ms ease-in-out;
-ms-transition: opacity 500ms ease-in-out;
-o-transition: opacity 500ms ease-in-out;
transition: opacity 500ms ease-in-out;
opacity: 0.125;
}
.ve-ui-toolbar-floating .ve-ui-toolbar-shadow {
opacity: 0.5;
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-13 00:06:57 +00:00
}