Adds a custom class for matched brackets to allow better integration
with custom bracket styles. The brackets won't be bold in the 2017WTE.
Bold font might lead to misalignment there. See ticket.
Note: box-shadow seems to be supported for quite some time by all
relevant browsers
Bug: T270926
Change-Id: Ica1e301f63a106a96db3bfaba4b2f322af64b009
I had to make some CSS selectors more specific, because the
library changed
.CodeMirror pre
to
.CodeMirror pre.CodeMirror-line,
.CodeMirror pre.CodeMirror-line-like
This is only relevant for entire lines (implemented as <pre>
elements). Most of the custom CSS is for characters, not lines.
In my tests in the Wikitext editor as well as VisualEditor I
could not spot any difference between the old and new version.
Bug: T258999
Change-Id: I6f0f030f972838727f3ef220feb105264f122798
The rgba() syntax is supported for a very, very long time now:
https://caniuse.com/#feat=mdn-css_types_color_alpha
Notes:
I realized the numbers in these file names are actually their
transparency in percent (more precisely their opaqueness).
4 is 4% which translates to 0.04 in the rgba() syntax.
I used Gimp to pick the opaque color values from the images.
Gimp makes this easy. No guesswork or calculations needed.
For multiple, stacked images I calculated the colors by
averaging their RGB values (considering how opaque each color
is). Note this is actually *more* precise than the stacked
images before. Stacking alpha colors is flawed. For example:
Let's say we have an rgba(255, 255, 255, 1) background.
Layering a half transparent rgba(255, 0, 0, 0.5) on top means
half the background shines through. This averages to
rgba( 255, 127, 127, 1). Now we stack rgba(0, 0, 0, 0.5) on
top. Again, half the background shines through, resulting in
rgba(127, 63, 63, 1).
When we apply the two colors the other way around, the result
is rgba(191, 63, 63, 1), a much brighter red.
This flaw doesn't happen when precalculating the averages, as
done in this patch.
Change-Id: I29026864714c5f90c2613af57f08693e7e2b996c
This patch changes the comment text color
to #84A0A0, as suggested by Kaldari in T170067.
Bug: T170067
Change-Id: I016b8ce360a06f14b02cee13b629fa578c889347
For testing:
__NOTOC__
___NOTOC___
____NOTOC____
_____NOTOC_____
______NO!TOC__NOTOC____
______NO{{TOC}}_____
______NO[[TOC]]_____
______NO'''TOC'''_____
__nOtOc__
FFFFF___NOtoc______
'''____________NOTOC______'''
__TOC___TOC__
__TOC____TOC__
___TOC_____TOC___
__TOC___TOC__
___NOTOC___
____NOTOC____
_____NOTOC_____
______NO!TOC__NOTOC____
______NO{{TOC}}_____
______NO[[TOC]]_____
______NO'''TOC'''_____
__nOtOc__
FFFFF___NOtoc______
{{__TOC__|__TOC__}}
Wrong, but not a big problem:
[[__TOC__|__TOC__]]
Bug: T170041
Change-Id: I0b2cfd02550c2685d241bdf3596507c5972878d5
This changes the green for HTML entities to a slightly lighter
shade of green to match the green of HTML tags.
Change-Id: Ice51e96b0f5fac67d88375fe76630098d380afc9
* Move CSS out of mediawiki.css which is for wikitext
highlighting rules.
* Account for wikieditor-ui adding wrappers even when
disabled.
Change-Id: I0fca693a6771ee1d790800c9afd5c7091fda20c1
* Fix state toggle in WikiEditor
* Update options API code
* Fix font-size and line-height so text doesn't move
* Append to WikiEditor after loading so it appends in
correct part of DOM.
* Only add border in classic editor
Change-Id: I5e80298030633d4859d01a92b6c61ef1fa969e96
