The CSS already has this modifier prefixed with -webkit-, -ms- and
-moz-, some browsers now support this without any prefix (according to
caniuse.com: Chrome 54+, Opera 41+).
Change-Id: Icd67250c26bec61be0fb101f1db077ee13ccf6b7
All our highlight content is inside a <pre> block. When this block is
more narrow that the page (due to being pushed aside by floating
context for instance), then the background of this parent element will
extend beyond the contents.
An alternative could be setting overflow:hidden; and then setting
margin:0 on the included <pre> element (which has UA default margins)
Bug: T126010
Change-Id: Id3c9544ea8fa379c7c640afa692d6184ad9c550f
Follow-up to 043969f84e.
It is not needed for current HTML generated by the extension tag,
but is required for compatibility with cached renders generated
between 6484894497 and
043969f84e.
Bug: T105499
Change-Id: Ie15d9c7fb673528b2ab5e40e6beddc580fb6d368
* Use 'nowiki' strip marker to prevent list processing (also known as
doBlockLevels()). This resolves various issues related to using
<syntaxhighlight/> blocks in lists and lists suddenly appearing
inside <syntaxhighlight/> blocks. Fixes T17333, T25674, T104067.
* To prevent <p/>-wrapping resulting from the above, add our own
wrapper <div/> around the output.
* Since we already have our own wrapper, remove Pygments' one and
extend it with custom attributes. This resolves some regressions
from the GeSHi migration. Fixes most of T103964.
Bug: T17333
Bug: T25674
Bug: T103964
Bug: T104067
Change-Id: I3afd1224a18549c62cd4a95fd046affa6d1d3b3f
MZMcBride noticed the red border around '國' in
https://en.wikipedia.org/wiki/Swift_(programming_language)#Example_code
That particular case happens to be a Pygments bug, because multibyte characters
are valid variable names in Swift. But even in cases of legitimate syntax
errors, I don't think we want to show the red border. This behavior may be
useful in code editors, but it is not useful in a wiki environment, especially
given the longstanding habit of using an existing, mostly-compatible lexer to
highlight a language for which no specific lexer exists.
To fix this, override the style in pygments.wrapper.css, and swap the order in
which the two CSS files are concatenated, so that in general we have the
ability to override Pygments-generated CSS.
Change-Id: I304fdaf3a462445d316e0f7fecc983fa87afc629
Before we started using the 'code' tag for inline code snippets,
<code><syntaxhighlight enclose=none ...>...</syntaxhighlight></code>
was a common pattern. Continue supporting it in existing content.
Follow-up to 04293baad9. My IRC comments
about this were seemingly forgotten, and the code I added in
5b7522a5fc to handle this problem
unceremoniously removed.
Bug: T85794
Change-Id: I8e52089fed41e78fb60ddd5b7c12075056265dd9
The 'direction' rules must not be applied to regular preformatted
text in MediaWiki core, only to syntax-highlighted programming
language code.
(Not reverting the part that removes 'monospace' rule, *that* is
superfluous.)
This reverts commit f834b719b9.
Bug: T103780
Change-Id: Ie7e9123ab3456aa6fff0485431fe81cd5eb31fa2
The styles in MediaWiki core for <pre> already cover this. And
for skins that want different styles, SyntaxHighlight should not
have been overriding it.
Bug: T103780
Change-Id: Ib863288a9a4530b183cf5fdb692489363d82a50f
I'm not entirely sure that this will always behave correctly on RTL
wikis, but currently we never behave correctly on RTL wikis.
Bug: T85794
Change-Id: I8af2b18884ec619d581f9ceed737c5628b647086
It was always "none" and not "span", this must've been an accidental change.
Also add a CSS tweak to better render the common pattern of
<code><syntaxhighlight enclose="none">...</syntaxhighlight></code>.
Bug: T85794
Change-Id: I3ed1b7f3c954374b49fc9a97881ea5236415cb6f
GeSHi is unmaintained, lacks support for many popular modern languages, and
suffers from deep architectural flaws, chief among them the inconsistent
tokenization of different languages, each of which requires a custom
stylesheet.
Pygments is a well-maintained alternative. It is, by my count, the most popular
syntax highlighting library around. It is BSD-licensed, actively maintained,
and is widely used in PHP projects.
To keep this easy to review, this change does not include update for l10n
files, and it does not delete the geshi/ directory. I will do those in a
separate patch.
The chief change between this and the previous implementation is that errors
result in the code block not being highlighted, as opposed to not being printed
at all, having been replaced by an angry red error message. I think that is the
right user experience. If you go to StackOverflow or GitHub and try to mark up
your code block as being written in some language that their highlighter
doesn't know about, you don't get an error message -- the code simply doesn't
get highlighted.
Because we don't recursively load dependencies for extensions, to test this,
you will need to create a composer.local.json in $IP and add:
{
"extra": {
"merge-plugin": {
"include": [
"extensions/SyntaxHighlight_GeSHi/composer.json"
]
}
}
}
Then run `composer update`.
Bug: T85794
Change-Id: I07446ec9893fae3d1e394f435d3d95cf8be6bc33
