I did some reverse engeneering and derived the three base colors for
nested templates and parser functions as well as links, together with
a formula to calculate any mixture of the three.
You can manually compile the .less file:
lessc resources/mode/mediawiki/mediawiki.less resources/mode/mediawiki/mediawiki.css
Then compare:
git diff --word-diff=color -w HEAD^ -- resources/mode/mediawiki/mediawiki.css
You will see that some numbers change. These are rounding errors in
the old .css code.
Bug: T307188
Change-Id: Ic534a2fac73f9f737ae5238b87aa80b705b37786
When there are standalone special characters '<', '[', '{', and '~' in the section header, the ending '=' will not be highlighted while the ending characters in the next line are incorrectly highlighted. This is because the ending '=' is eaten as plain text at the end of function eatWikiText(). A less aggressive plain text matching does not hurt.
Bug: T309143
Depends-On: I47dad71df97f38c55550f71baf6dae67dbe0a2ba
Change-Id: I4a9c6c6cb2f7fbc212808e386124a56676fdbfb1
Including an user options to enable/disable the scheme. Defaults
to false. Feature is only availible together with the new more
accessibile color scheme as the CSS depends on each other.
Set behind a new temporary feature flag.
Bug: T305027
Change-Id: I46d240a30eda5a1526ada1fe9b724f7b4594b426
CodeMirror is already able to highlight multi-line tags if the tag name is followed by any non-whitespace characters in the same line. This commit fixes the other condition where the tag name is followed by whitespace only in the same line.
Bug: T201684
Change-Id: I8cb4a53ee0fe7fc8612a58331a1a3e57d00d7630
HTML and extension tags should be highlighted as the text of internal or external links.
Bug: T184341
Change-Id: Ib1f2047936b395afd86720e2a7c921e382229cdd
* What we care about is the <pre>. The class="CodeMirror-line" is
added to every <pre>. We don't really learn anything new when we
include it in our tests.
* Testing the ARIA role is testing a CodeMirror feature, not a
feature of the mediawiki mode under test.
Change-Id: I33bfedb304228240c4e835cc983117668c398c61
I forgot this when I added this test case in I03a1e1a.
Also:
* Use another method to detect if the Cite extension is active. This
is the same method used in the actual code.
* Move a line of code into the `if` it belongs to.
Change-Id: I1efd3f945150aeb08db3c771e579d9a6114a4c21
* Append to the hidden #qunit-fixture instead of directly to the body
* Use the right selector when cleaning up
Change-Id: I8be38900e6c5f4592f06dfc8f7c2cfc348627716
In T270880 an example with a slash in <ref name="a/b"> is
described. The same issue happens with several other characters
including the closing bracket, e.g. <ref name="a>b">. This patch
fixes all of this by accepting _all_ characters between double
and single quotes.
Bug: T270880
Change-Id: I03a1e1a25af692dc703b44a57b2d23d6fc15c8c9
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
These changes to the color scheme are hidden behind a feature
flag for the time being.
Bug: T271895
Change-Id: I0a4b03e0f3bc8239f31edbbd5ae55661607b76f6
I was wondering why the performance when editing wikitext is
still so bad, and profiled it again. Turns out
StringStream.match() is still the bottleneck (even if already
100 times better than before Icbb1122).
The method is called with many different patterns from
mode/mediawiki/mediawiki.js. I profiled them individually and
found a single outlier. The idea is the same as in Icbb1122.
A pattern that is able to find something *in* a string is
doing nothing but wasting time, as StringStream.match() ignores
every result that is not at the start of the string.
The change adds the missing ^ anchor and wraps the regex pattern
from mw.config.get( 'wgUrlProtocols' ) (that is something like
"ftp:\/\/|http:\/\/|https:\/\/|…") in (?:…), which is a
non-matching group. This is necessary because of the | in the
pattern. The result is a pattern that looks like /^(?:…|…|…)/i.
I remember looking at this code while working on Icbb1122, but
didn't include it in the patch, and then forgot about it.
Bug: T270237
Bug: T270317
Change-Id: Iea2fd116b68704c3186b0edf965006cc7c6eda82
I continued profiling the matchbrackets addon for T270237 and run into
performance issues that turned out to be unrelated to the addon. The
flame graph highlighted a "match" function. Note this is not the
String.match() from JavaScript, but something in the CodeMirror lib:
StringStream.prototype.match = function (pattern) {
var match = this.string.match(pattern);
if (match && match.index > 0) {
return null;
}
return match;
}
(Note: I simplified this code so we can focus on the bug.)
When the pattern is a regular expression, it's executed via
JavaScript's String.match(). The function then checks if there was a
match and if it's at the start of the string. If not, it's not a
match and doesn't return one.
In other words: Even if there is a match somewhere in the string, the
function acts as if there was no match.
When we change all patterns to be anchored via ^, they don't scan the
entire string any more but return much ealier when there is no match
at the start of the string. We are effectively replacing nested loops
(hidden in the patterns) with single calls.
This bug exists since 2014.
The disabled line in the matchbrackets addon is just dead code. I
don't remove it to document the fact that we disabled it.
Bug: T270237
Bug: T270317
Change-Id: Icbb1122e6a3b26c0606726ff405e108931d185be
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
CodeMirror inserts
style="padding-right: 0.1px;"
only on Webkit.
The test case now strips this pattern from the rendered HTML before
comparing with the expected test case output.
Change-Id: I34b201f790d3d85a5f51d8200bf8219f11d14506
This patch changes the comment text color
to #84A0A0, as suggested by Kaldari in T170067.
Bug: T170067
Change-Id: I016b8ce360a06f14b02cee13b629fa578c889347
