There were issues with shadows, and the sprite creating weird
offsetted buttons on Chrome.
Subsequent attempts have been incomplete at solving these, so
reverting this and hoping that the next person to attempt a conversion
to SVG is more successful.
This reverts commit e027051c58.
Bug: 35342
Change-Id: Id296899a2c3746957c17068ab17ca8266f6ff0d3
Since we now have a full fledged mobile solution, I think we should
strive to have the site 'proper' work as much on any platform as
possible.
WikiEditor traditionally was not loaded on iOS.
No one really knows why this was not loaded. It can have been bugs or
just to 'slim down'. It works on iOS 6 and iOS 7, so for that reason
I'm now changing the blacklist in this respect. It might work with
earlier versions, but I can't really test that right now.
Bug: 63277
Change-Id: I605eb0e093b84203f1157d9e20788eaa0040ddbf
jQuery's show/hide/fadeIn/fadeOut methods makes changes to the
style attributes of elements. That makes them rather hard to override
their visibility, without adding an entire API to the module to do so.
This replaces the default animations with one using classes to control
visibility and only animates the animatable properties using
the style attributes.
Follow-up to: Iadaae3fb9ae1899e12605d653b2688616b8f7c40
Change-Id: I4652ade66c6de864ee3e74b3817ed9b93967ce3d
In I0f53a68e50fc950d7f407ee81b2bf0d81ef4948d and
I47119d6cfdde4b40ff5b07be0c7d327b80598142 I forgot to remove the images
of the corresponding modules.
Change-Id: I8de59f6ce54d0cc7f67f56853386d4338c693b98
Add a new styles module. This module makes sure that the textarea is
already properly styled (jumping lineheight bug) before we start the
JS. Also hide the toolbar before it's styles have finished loading, so
you don't see it being constructed on the fly. Move inline styling for
the old toolbar into this stylesheet as well.
Bug: 47708
Change-Id: I40bec0a24dbd295db301e7faefb93d8991981acb
* Rename 'collection' to 'loadmodules'.
* Consistently close parentheses and brackets at the same
indentation level as they were opened.
* Use $.ajax directly instead of $.post, especially the fourth
argument to $.post makes it hard to read.
* Use promise interface of $.ajax and $.post instead of the
(deprecated) callback parameter.
Change-Id: I48924c9a1ce29829f8994be05c46d5563b2c25d6
Ib97f47ef1d66420682bd429c9c12e66c3392e77d Didn't cause
problems so this is now safe to reapply (to wmf2).
This reverts commit 908e7cc56c.
Change-Id: I510536959b58ff0adacd7908f6150c95bfdb3ec1
Sadly this caused bug 64289; so we're going to revert this for now;
then redeploy this and Ib97f47ef1d66420682bd429c9c12e66c3392e77d
in one of the swats next week.
This reverts commit effd98be7e.
Change-Id: Idde3e51e894f8c92f47fb06f0cf08d01e82ccb48
When we are wrapping the textarea in the Editor UI, the focus state,
cursor position and the scrollposition might get lost. This is
especially annoying on slower machines, where users might have started
using the textarea before the WikiEditor UI was constructed.
Bug: 41911
Change-Id: Ie472c6c88d98f7ba89873a2db73463ef01bd995a
We had some crazy stuff here with negative margins, border boxes and
what not. There were some problems with IE versions, zooming in and out
in pages and with the side by side preview.
This should take care of those. Mostly it moves the borders inside the
elements that are 100%. This was also required because of the
side-by-side preview which was using a dirty trick to hide the border at
the top
Bug: 26828
Change-Id: I3c3466fac53df3e79de6f12f404005e55409fa7c
This makes sure that on narrow page views, it's contents won't bleed
into the textarea.
Bug: 37392
Change-Id: Ia14b354a5a2de049d219e735795a9bd9f558f660
because apparently we do have empty tools boxes. Alternative
implementation in I4652ade66c6de864ee3e74b3817ed9b93967ce3d
This reverts commit dd46fc383b.
Change-Id: I358c34d63261989d49b0a4156cbc05b544727d5c
According to the jQuery documentation (and code) all kinds of
$( '<element>' )
$( '<element/>' )
$( '<element />' )
$( '<element></element>' )
are identical. So yes, this patch does not change anything. All it
does is removing characters that are ignored anyway. Using the same
style everywhere makes the code easier to read and understand and
may save a few bytes when it is gzipped.
The current WikiEditor code contains 67 usages of that jQuery call.
Only very few of them are not in the most simple <element> style.
Personally I consider the style <div/> confusing since a <div> can
not be a void element.
Change-Id: I816b4cccc9ee329e9bcdd9bd2353e5653fd10c36
This line forces sections to be visible after you edit the toolbar.
There is no apparent reason why this should be necessary. It has been
in there almost from the start, but doesn't seem to be used
Change-Id: Iadaae3fb9ae1899e12605d653b2688616b8f7c40
IE11 replaced document.selection by window.getSelection, which breaks
dialogs in WikiEditor, because document.selection.createRange was
accessed without check. Inserting this check unbreaks the dialogs.
Bug: 57489
Change-Id: I70d49fb43bbf7602f43e9a8086ecd32027cb6d6f
