This CSS exists since I2ab47e7 from August 2014. The original idea
was to dim the default "General references" when you edit a <ref> or
<references> list in VisualEditor.
Steps to reproduce:
* Start VisualEditor.
* Edit a <ref> or <references> list.
* Edit the group.
* You will see the dimmed text "General references". This is not the
CSS in this patch, but the default styling for OOUI placeholders.
* Open the dropdown. The list will show a "General references" item.
It's not dimmed. This is where the CSS was meant to be.
The CSS class name in the OOUI mixin was actually changed from
"oo-ui-flaggableElement-…" to "oo-ui-flaggedElement-…" via I1abecd8,
just a few days later.
In addition the selector wouldn't work anyway for other reasons.
The dropdown is not inside the `.ve-ui-mwReferenceGroupInputWidget`
container any more but placed outside by the OOUI window manager.
And the selector's specifity is to low, at least since Ic57b3ff.
I argue it's not worth fixing it. Nobody missed it for 10 years.
Light gray text would be illegible anyway on the light gray/light
blue backgrounds used in the dropdown menu. Let's consider it dead
code and just remove it.
The class name doesn't appear anywhere else (any more):
https://codesearch.wmcloud.org/search/?q=flaggableElement
Change-Id: Ia802303737ba35cd4b14fae924b7227472f905fd
This can be quite confusing:
* A node does have attributes. One of the attributes is called
"refGroup", another one "mw".
* mw contains a JSON structure with just a few elements, most
notably a "body" and an "attrs" element. These reflect what was
originally written in the wikitext.
* mw.attrs reflects the original properties a.k.a. attributes from
the <ref …> or <references …> tag.
Deleting mw.refGroup doesn't do anything because the attribute is
called <ref group="…"> in the wikitext, not <ref refGroup="…">.
You can actually see this bug in action on all wikis: Go to a page
that uses references in non-standard groups, e.g.
https://en.wikipedia.org/wiki/Historic_Cherokee_settlements
Start VisualEditor. Find e.g. the [notes 1] reference. Edit it
and change the group from "notes" to "General references". Click
"Publish…" and "Review" your changes. The visual diff works because
it apparently uses other information. The wikitext diff is empty.
This is also what's saved: nothing. The edit is lost.
Bug: T359943
Change-Id: I798605d2fd60a6b8f317ec85a4e4d08fd245e084
* Include the README in generated JS docs.
* Tweak stray top-level files to explain their role. Note that the
wmf template forces these files to appear on the docs home page...
Bug: T358641
Change-Id: If421414340903991f50a06a76551bd7cd2904c5e
The first two files have been added to the root modules/ directory
via I487095d in 2015. No problem.
Many, many more files have been added via I000b453 in 2022. It's
really hard to tell what is what since then.
I'm not absolutely sure what the naming convention for this folder
should be. Could as well be "localized-styles/" or just "Parsoid/".
Bug: T156350
Change-Id: Ibcf8c7a6db5400ed8a9811244a070e03ff372a39
This didn't mean what it looked like: `||` has higher priority, so an
undefined elem would not result in an empty string.
Change-Id: I1e361842f060815b04802a1ab8f077faa1a8bc6b
Some of the annotations were used in a way that confused jsdoc. This
cleans up redundant annotations and uses more canonical tags.
These changes cause all classes to now appear in the generated pages.
Includes linking to external docs.
Bug: T358641
Change-Id: Iaee1dadcc19a70c27839d0d27dfa6a07a70fb46b
These tags are 10 years old. Current documentation generators don't
need them.
Tagging something explicitely as being a @method can be useful in
an interface where the elements are initialized with e.g. `= null;`
instead of having an implementation. But we have implementations
here. Sure these are methods. No need to say that in the
documentation.
Also removing a comment that's obviously a copy-paste mistake from
what was the ve.ui.MWMediaSearchWidget back then. See Ib244ff6 and
before.
Change-Id: I7df6c789d10fd89e7fe97d56c942fd22c56d8458
No need to manually scan for the currently selected item. And no
need to do it twice. The feature is a little hidden (calling the
method with no parameter) but always was supported.
Bug: T356871
Change-Id: I02401284eef5687eb0825d8d9ae0df294b3b4e03
I find it very helpful to use the name "mwAttrs" specifically for the
mw.attrs thingy that contains the original key-value pairs from the
wikitext.
An alternative is to use ve.getProp, which is helpful in other
situations.
Change-Id: I3edf0dfe5b9629fcda0bf8cb3b734215377a5c77
This reverts commit 0566a495f3.
Reason for revert: Merged too soon, while discussion of the whole
approach is still ongoing.
Change-Id: I2d3d6455cd4ea12067e2020f6b41cfbb4672bbb5
It's fine to copy attributes directly from the reference node rather
than go through the specialized model object.
Bug: T336417
Change-Id: Idaca192137dc762ddced2ee8446a7d838f97e317
Begin a QUnit test module for the reference model. Tests demonstrate
that a new ref and a normal ref reuse from the full document both
behave as expected.
Bug: T336417
Change-Id: I1337806d41b50329ba971c8e68e1a62b52cc9a52
Intentionally no other change is made (yet). This is for a later,
separate patch.
Intentionally not touching the huge list of per-language
ext.cite.style.*.css files for the moment. Again, I would prefer to
do this in a separate patch.
Change-Id: I4e392c7bd1c69849a6c7946676a64c749ddbcd60
The current tracking is wrong for several reasons. Mainly because
of a race condition if the Popups extension fininshed loading
before the Cite tracking script is executed. But further more
wgPopupsReferencePreviews was not a good choice to see if the user
sees previews or not.
The logging now uses the monoschema and only checks for enabled
previews when the click events are fired. The chances that Popups
finished initilizing then are much higher then. We still can see
if the init is not finished and the variable not set though.
Also we won't track the overall pageviews in here but use the
generic pageview_hourly from the data lake instead.
Bug: T353798
Depends-On: I1c434f0098ae23bd62256686a658e3d5ef7f70b9
Change-Id: I7a9524274efb58286f520c6148d5463bb0a78dbf
Same as Icfa8215 where we removed the …_suffix messages.
This patch is not blocked on anything according to CodeSearch:
https://codesearch.wmcloud.org/search/?q=cite_references%3F_link_prefix
According to GlobalSearch there are 2 usages we need to talk about:
https://global-search.toolforge.org/?q=.®ex=1&namespaces=8&title=Cite.references%3F.link.prefix.*
zh.wiktionary replaces "cite_ref-" with "_ref-", and "cite_note-"
with "_note-", i.e. they did nothing but remove the word "cite". This
happened in 2006, with no explanation.
ka.wikibooks and ka.wikiquote replace "cite_note-" with "_შენიშვნა-",
which translates back to "_note-". One user did this in 2007,
16 seconds apart.
It appears like both are attempts to localize what can be localized,
no matter if it's really necessary or not.
https://zh.wiktionary.org/wiki/Special:Contributions/Shibo77?offset=20060510https://ka.wikiquote.org/wiki/Special:Contributions/Trulala?offset=20070219
Note how one user experimented with an "a" in some of the edits to
see what effect the change might have, to imediatelly revert it.
The modifications don't really have an effect on anything, except on
the anchors in the resulting <a href="#_ref-5"> and <sup id="_ref-5">
HTML. It might also be briefly visible in the browser's address bar
when such a link is clicked. We can only assume the two users did this
to make the URL appear shorter (?). A discussion apparently never
happened. Bot users are inactive.
Both pieces of HTML are generated in the Cite code. Removing the
messages will change all places the same time. All links will
continue to work. The only possible effect is that hard-coded
weblinks to an individual reference will link to the top of the
article instead. But:
a) This is extremely unlikely to happen. There is no reason to link
to a reference from outside of the article.
b) Such links are not guaranteed to work anyway as they can break
for a multitude of other reasons, e.g. the <ref> being renamed,
removed, or replaced.
c) Even if such a link breaks, it still links to the correct article.
There is also no on-wiki code on zh.wiktionary that would do anything
with the shortened prefix:
https://zh.wiktionary.org/w/index.php?search=insource%3A%2F_%28ref%7Cnote%29-%2F&title=Special%3A%E6%90%9C%E7%B4%A2&profile=advanced&fulltext=1&ns2=1&ns4=1&ns8=1&ns10=1&ns12=1&ns828=1&ns2300=1
I argue this is safe to remove, even without contacting the mentioned
communities first.
Bug: T321217
Change-Id: I160a119710dc35679dbdc2f39ddf453dbd5a5dfa
WikiEditor also uses 'html' instead of 'text' on headings. At the
moment both keys have the same behavior, but the original intended idea
is to have 'html' as already valid HTML (like on .parse()) and 'text'
on plain text which has to be escaped.
Change-Id: I1b4035a86ed56bfeb12d33b463d67099f7ae40e3
In this JavaScript files the closure is not needed to prevent
declarations of functions and variables in the global scope.
Change-Id: I169a74c69a5e00b86fbcc9f56886a3c4157ebd0f
In articles with references, a reference list is generated. If you
try to visual edit the reference list, it displays a message "This
reference list is generated by a template, and for now can only be
edited in source mode." However it is actually editable now that
T54750 (Community Wishlist 2023 wish #2) is complete.
Bug: T54750
Change-Id: Id8115ae6045f371e4619c85aeb610fe78927d802
ext.cite.style.css is very close to ext.cite.styles.css and is
often confusing.
In about 3 weeks (the current PC expiry time), we should be able to
get rid of the ext.cite.style module from extension.json after
removing all references to it from other repos and caches.
I don't see a reason to rename all the other language specific
CSS files since there is no room for being confused there.
Change-Id: I3a41f435b0cbe51f8c9a6dde8a9f6eb13a9879f7
* Be more specific about the type of context which a
context item belongs to.
* Make grammar clearer.
Change-Id: I9bcc129766c3386582def0f346d6f175e54d6ff6
Some of the methods used for mw.message were incorrect, which could
potentially lead to double escaping.
This follows up I4bc60570012bcd8eab5ad32c5004d06b3af42798
Change-Id: Iceb819c8fa6c46c234fc79d1c81bd3252440269c
This reverts commit da30b2b626.
Reason for revert: Caused a regression. Feature is not enabled on public wikis so reverting is harmless for now.
Bug: T247922
Bug: T340757
Change-Id: I83434afaf1b76425bddb575dd724f462a247c83d
The WikiEditor extension has a button and some help text that
is only applicable if the Cite extension is enabled. Move
that (with some modifications) to the Cite extension instead.
Bug: T339973
Depends-On: I8256660f9c6886d6764b45735284e00308fc56e5
Change-Id: Ib3fdc897dd3330f69c5832003d4c3cb1e6dba2f3
This is a first demo that it is possible to get the text of the parent.
This is hidden behind a feature flag.
Next: see if the parent ref can be added to the rendering
Bug: T247922
Change-Id: Idd409f25b253a19c20ed8623737ecc49315587dc
To warn users when they are editing a sub-reference we
add a warning containing the text of the parent reference.
This is hidden behind a feature flag.
Bug: T247922
Change-Id: I3749683d8a18e502bf16e5bd5f2fe385581625be
* 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
