* Use OOUI message widget to make code cleaner
* By default message is toggled off and only displayed when needed
* To prevent visible changes the message widget is slightly adapted:
* Use black alert icon to prevent yellow default icon for warning messages
* Remove bold text (in css)
* Some padding to top and bottom
* Changes can easily be removed if message should be closer to the standard
Bug: T247922
Change-Id: I2296cd497c935ea4638650bdb4b3c833a71a6c6a
I assume the code was using lastIndexOf as some kind of performance
optimization. Certain StackOverflow threads suggest it without going
into detail. It's not correct here. You can actually name a group
"mwReference/", which will result in the (valid) internal name
"mwReference/mwReference/". This works as expected with indexOf but
not with lastIndexOf.
Change-Id: I8e85ae5c11a74016c7720fcdb6ac6478431aaa8e
* reads the new attribute extends from wikitext
* saves it into the reference model
* adds a message to the VE popup of an extension as a first demo
* tests will be added in a separate patch
Bug: T247922
Change-Id: If4d309c4678022642f39e21565950dc45e557d47
This means the reference list is always in sync with the model's
understanding of which references are available to edit.
An exception is left in if there are no references in the model
at all, as will be the case on he.wiki, as all references are
template generated. In this case we continue to use the Parsoid
DOM, so that there is a static rendering of the reference list.
Bug: T336865
Change-Id: Iaf1089c9de532e7749c9cb70a9e697917955dca8
Minimal test case:
<ref name=a>a</ref>
<ref name=a/>
<references/>
This renders as "1. ↑ 1.0 1.1 a" in both the legacy parser as well
as Parsoid. The moment you start editing this in VisualEditor the
space before "a" disappears. This patch fixes this inconsistency.
Change-Id: Idfea1a445fc98a0433640b4f706fafcc4e236c18
This fixes a minor inconsistency: A reference that comes from a
template and is already reused outside of the template is only
partially available to VE, and previewed with a warning message
because of this:
"This reference is defined in a template or other generated block,
and for now can only be previewed in source mode."
This was missing in the reuse dialog.
Note this patch is not meant to make any design decision, but to use
the existing design consistently.
You can test this with and without the Citoid extension. It works in
both cases.
Bug: T336372
Change-Id: I962cf111b1882bcd736f1090ca17d2b176495d2f
This fixes a minor regression introduced in Ib003b8a. The problem is
that undefined is not equal to anything in JavaScript, and not smaller
than 2 either.
Bug: T241885
Bug: T335410
Change-Id: Ia6deb291d923b88a08ceac8fbc0efb682e14f358
This patch also updates a second place that does almost the same.
That other place also excludes placeholders. We intentionally don't
do this in this new place.
Bug: T241885
Change-Id: Ib003b8a7bbe247db6f7da0a4efcfd4e5967fd033
This issue was introduced in I7a8ec9f. I tried to understand what this
does but can't see an effect. The behavior and appearence seems to be
identical with and without this code. In case it turns out this is dead
code (e.g. not needed any more with our current browser requirements)
it should be removed. Otherwise the selector fixed.
Change-Id: I0bfae951aa4543c528dd7e04c00a0e978f1ce49e
* Add a file-level comment in the cite tests file.
* Document the CSS rule that hides the Parsoid HTML.
Change-Id: I27dc6d5f6ab09b67e28ce88a2e13bf2d1a13e9c0
This is a prerequisite before any work related to T52568 (being able
to manually name references in VisualEditor) can start.
Why these names should not be hidden:
* We don't know if the name is actually part of the auto-generated
sequence in the current article or copy-pasted from somewhere else.
* Manually given names that start with a colon are currently hidden
even if they are unrelated to the auto-generated sequence.
* The information is highly relevant for users switching between VE
and wikitext. Especially when a reference is used multiple times
the relevant wikitext can be as short as <ref name=":0" />. The
literally only information in this case is the number.
Since these numbers are still more technical than anything we make
them very dim to emphasize the contrast to non-numeric names.
Bug: T52568
Bug: T92432
Change-Id: I65cb6998cb5f8659cd9043f3d4aaeac1c5f69da8
This original use case at T187495 is for he.wiki, where it is likely
that all the references are defined in templates, so the model
will always be empty, even though $originalRefList is populated.
Change-Id: Ia2785a20bf82ab97466276a57936bc9299e1cabe
I copied these from the visualdiffing repo, but I may have
over-generalized these from some wiki that might have customized
this to all wikis. enwiki doesn't use this, for example.
In any case, this styling should be left to individual wikis.
similar to the argument in 8412fb64 where I removed CSS rules
for standard refgroups as overreach.
Change-Id: Ie37408d7a92af88e39e345eb464c6fa2210d57e3
* This ensures that Safari can also render these counter styles
since Safari doesn't support @counter-style CSS rules yet.
Change-Id: Ib104a6d22197037bae0c58766d3363176022add3
* This has always been a bug but was hidden because enwiki
uses lower-alpha custom rendering and so we never noticed it
when we tested this on enwiki.
* Fixing the default gets rid of the need to override this for
every single language that defined a non-decimal counter.
* This also eliminates the need for some rules where the overrides
were identical to the baseline definitions (counter-type is
decimal and separator is '.').
Bug: T86782
Bug: T156350
Change-Id: I51f8a06c80bb897b66a0978b117fbc5560efd6cb
* This was obviously a mistake for 'decimal' since the previous CSS
would have rendered refs with the "decimal" group and refs without
any group identically making it hard to distinguish between the
two ref types.
* But, not all wikis define custom messages for these "standard"
ref groups. So, by providing default rendering for these, we would
need custom overrides for wikis that didn't define them (the vast
majority). Instead, for wikis that define them, define wiki-specific
CSS for these groups that can be added to their Common.css pages.
* Discovered as I set about trying to update CSS on wikis and my
test wikitext with different groups were rendering decimal groups
differently and I had no custom CSS for it anywhere.
Bug: T86782
Change-Id: I5598580e96eead94bb09574b2af5cef3ce4241c5
In both cases:
(a) ref counter display for .mw-ref sups
(b) backlink labels in the references section for multiple named refs
the a-tags are direct children of the <sup>/<span> tag.
The child selectors are more precise. I am not really sure why we
went with descendant selectors in the first place.
Bug: T156350
Change-Id: If5be7cd14de40c2372f27ae5e2f32671c0a4e20c
* Turned out there were 2 counters defined on references li nodes.
* One was added as part of the extends functionality added by WMDE's
book referenceing project.
* The other one was added as part of Parsoid's Cite CSS work.
* Since the counter increments were defined separately and applied
to the same node, only one of the increments would apply.
This breaks counter rendering on wikis where custom wiki-specific
rules aren't defined in that wiki's Mediawiki:Common.css
* Discovered after running visual diff tests after ad919e37
was deployed.
Change-Id: I826faac3564d63b8a4fbd80015fd5cc8f0069b7a
Lower-alpha is enwiki/community specific preference and as such should
be defined in Common.css of that wiki.
Bug: T326467
Change-Id: I1c254031185b130de90fad2410a21533e8c3ba96
Signed-off-by: eranroz <eranroz89@gmail.com>
* These files were generated with the script in
I3623e42d4cad7975813892a8f0f7765b74a638c5
* These styles mimic the behavior of Language::formatNumNoSeparators
and Language::localizeSeparators used by a couple of methods.
ReferencesFormatter:referencesFormatEntryNumericBacklinkLabel
calls ReferenceMessageLocalizer::localizeDigits which calls
that core Language method.
FootnoteMarkFormatter::linkRef calls localizeDigits as well.
- '.reference a*' CSS rules mimic linkRef localization
- 'span[rel="mw:referencedBy" ]*' rule mimics localization
of referencesFormatEntryNumericBacklinkLabel
* Overrode all hand-crafted language CSS files from previous
patches. The content of some of those hand-crafted CSS files
will end up in those wikipedia's Common.css -- specifically
for es, fr, sv wikipedias.
sv and es have non-canonical formatting strings that aren't
handled by the script right now and so leaving them behind.
I need to look at fr output more carefully, so leaving that
behind as well. But the generated ones are more accurate when
combined with the wiki-specific CSS files genreated by the other
script that processes site messages.
* Some files could potentially be removed by looking at
language fallback chains, but the redundancy is not a
problem for now.
* Tweak the resource loader script to use "_" instead of "-"
when looking for a resource file.
Bug: T156350
Change-Id: I000b4538bf2be681b85df5813efed083458a4281
* The default formatting for linkbacks for multiple named refs is
determined by the "cite_references_link_many_format" message.
It is only defined in en.json as "<sup>[[$1|$2]]</sup>". $2 is
the output of referencesFormatEntryNumericBacklinkLabel.
So, change the default Parsoid CSS rule to match that.
* But, since we have shipped Parsoid CSS all this while with the enwiki
default, temporarily add "ext.cite.style.en.json" with that enwiki
default so that on deploy, enwiki citations in VE continue to display
as before.
Change-Id: I6f4b0e25189284ad0950977752739e7dc2951fec
When these styles are loaded on a normal MediaWiki page containing
output from the old parser, they cause references to be duplicated.
Use .mw-ref for now, which is only present in Parsoid output.
This partially reverts d6705eb3f8.
Bug: T323343
Change-Id: I6f2d43a060bea7aa175bed80f1be2c3d8a4924b0
Parsoid now uses <sup> tags instead of <span>.
We already changed it in DM HTML a long time ago
(see ve.dm.MWReferenceNode.static.toDomElements).
Bug: T323343
Change-Id: If04a8bd36e0bb0c31e5f60ae54cb54f13fa65720
