We print error messages in red, bold, large text so that they stand
out from content. "<code>" spans, which are prevalent in our messages,
were styled with black text by accident, this patch turns them red.
This should cause less annoyance on readers.
Change-Id: Ic911552909ecc5ace4be927cad5b835e1006355e
Same as Ib6e9de6.
We must reset the build-in "list-item" counter to make this code behave
sane in Firefox. It looks like this is even described in the CSS spec
and it is not Firefox having a bug, but Chrome being "clever" and not
following the spec.
Bug: T229307
Change-Id: I955786e2b68d087c819a962ded3c571946c61f78
All mock screenshots on
https://de.wikipedia.org/wiki/Wikipedia:Technische_W%C3%BCnsche/Topw%C3%BCnsche/Erweiterung_der_Einzelnachweise
show this extra dot.
Note the numbering scheme "1." and "1.1" (without the dot) was not a
mistake. It's not uncommon to only have the extra dot on the first
level.
However, I feel the scheme "1." and "1.1." might be a little more
consistent and less surprising.
Change-Id: I0dc467755926f82d88a48fb7594af0bde8bbee21
This patch applies a few closely related changes:
1. Instead of reusing and possibly messing with the existing
"mw-ref-linkback" counter, I start a new one.
2. I also gave both new counters better names, following the
"mw-ref-…" naming scheme.
3. We must reset the build-in "list-item" counter to make this code
behave sane in Firefox. It looks like this is even described in the
CSS spec and it is not Firefox having a bug, but Chrome being "clever"
and not following the spec.
Bug: T239787
Change-Id: Ib6e9de689129b7c2d50e3a1c720c0d2d5a0c0986
Forked from Icd933fc983.
Bugs and unimplemented features are documented as TODOs in the parser test
fixtures.
Bug: T237241
Change-Id: I9427e025ea0bcf2fa24fd539a775429cc64767cc
This code is typically not executed on special pages and such, so we
assume the isArticle check doesn't make much of a difference. The main
difference we are aware of is that this will exclude previews.
Bug: T214493
Change-Id: I5155329b8a549adbd3b17c1f1014bb8bbc6768f4
There are so few users with this configuration that we need to stop
sampling in order to get data. Sampling is still in effect for
"baseline" users with the feature disabled.
We use separate schemas to simplify analytics on the two populations.
Bug: T214493
Change-Id: I16e4ed236e50e1e246ff28ff0dba3e52e4b56caf
Collect EventLogging metrics for footnote and reference link
interactions, so that we can compare behavior with and without
Reference Previews enabled.
This tracking will be reverted once analysis is complete.
A mostly arbitrary sample rate of 1/1000 is hardcoded here. This is
loosely based on the latest tuning of Popups sampling at 1/100,
divided by a conservative factor of 10 to ensure headroom.
The sample is skewed by skipping clients without sendBeacon support,
but we're avoiding the mw.track synchronous fallback, which injects an
image tag and introduces lag any time the user clicks external links
in the references.
Bug: T231529
Change-Id: Iad32b64114f88675eecbb01712418c968e3cf661
The ve-mw change I0479116b51cc3135a992fdf36b8edfb2c44916ba removes the
stripping of solitary paragraph wrappers (which is moved into
ve.ce.Surface in VE core).
Depends-On: I0479116b51cc3135a992fdf36b8edfb2c44916ba
Change-Id: I2429b5291d8505d586cf4edc4cae9875f8abc347
This stopped working correctly after T218946, when we merged
MobileFrontendArticleTarget with its parent class MobileArticleTarget.
Bug: T233181
Change-Id: I9ec3f42508809431aef86157c20d8d6bb2fb12e5
The ve-mw change I0479116b51cc3135a992fdf36b8edfb2c44916ba removes the
stripping of solitary paragraph wrappers (which is moved into
ve.ce.Surface in VE core). We can't merge it without removing the
failing tests here for a moment.
Change-Id: I8799d51958b966c99307f4c70546ea326e67385c
