Some wikis such as eswiki and frwiki prefer to hide the square
brackets by default. Adding a selector-friendly DOM element around
the brackets supports this customization.
This makes it possible to hide the brackets with CSS:
.cite-bracket {
display: none;
}
And it also becomes possible to hide the brackets but make them
appear in copy-pasted article content:
.cite-bracket {
font-size: 0;
}
Bug: T370512
Depends-On: I56b52c399d2c76689fdcb0bc7fd50a8c0ced28fd
Change-Id: Id8684ccee2e6725af2c861da20fc31af1067e614
Significant change is that footnote marker numbers are changed from
being a CSS-rendered marker to using the rendered "fallback" text.
This could be avoided using the same trick as is implemented for the
reflist: send an inline style variable with the marker content; but
let's only do this if really necessary for user experience.
Template-produced refs are still wrong, but this patch continues to
render them as they come from Parsoid, in the content script.
TODO in later patches:
* reuse of a subref is rendered as '3.2.1' in reader view but '3.0'
and '3.1' in the editor.
* subref numbering is backwards in RTL languages
Bug: T247921
Change-Id: Ieff73769f8ebbc3724f6a9b498487c4e7d09aa2e
To make sure also the parent gets a name even if it is not re-used
we need to iterate the list of reference to see if there's at least
one child that matches the parent.
The rest will be taken care of by getUniqueListKey that makes sure
that the matching temporary names will result in matching literal
names.
TODO:
- Write a ve.dm.Convertor test which shows the auto-name being
added.
Bug: T367031
Change-Id: I6ef42c8ffc8a4ff9224bfb2a910682d2c44f0dd2
This makes it much easier to deal with the internal auto names
used on new elements created during one edit session.
We're ignoring the correct generation of the auto name literals
for now.
Bug: T367031
Bug: T367030
Change-Id: Idd579970cb64500dac27053213e9b116f23b6d76
mw.attrs does have a special meaning in this code. Together with
mw.body it reflects 1:1 what was written in the original wikitext
in the <ref …> and <references …> tags. Let's avoid using the same
(or almost same) variable name for other kinds of attributes.
Bug: T363096
Change-Id: I3e599ab910b9639e121f9b9d532b0f57f08f1e73
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
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
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
* 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 is a bit of an abuse of the originalDomElementsHash property.
In future we could add a 'uniqueId' attribute, but this would need
to be ignored in a few places in core.
Bug: T299378
Change-Id: I7d1eb362aeb74ba93f5225330226a95535746b92
In Ifb0ba3caf8d we removed this reference equality check and replaced
it with a deep object comparison, however due to the fact that
hashes for MWReferenceNodes were simplified in I8c26686d7b to
improve visual diffs, this resulted in a overly simplified comparison
that couldn't distinguish references with the same "name".
Instead do a deep object comparions of the standard node hash object.
Tests added in Ia0bbd40528 assert that this doesn't result in the
regression that caused T296044.
Bug: T296086
Change-Id: I7b37fb54e14bfe28a07f722a2c45fd4e4a2d44f2
Previously we checked the elements were reference-equal
which is fragile and breaks when linear data freezing is
enabled in debug mode.
Change-Id: Ifb0ba3caf8d3e5a67c9694358cac12cc412fe723
This means that all reference nodes are treated as comparable
in the diff (provided they are in the same group) so will
not show up in the article diff if their index changes.
Changes to the reference list are already handled separately
by the visual diff.
Bug: T170235
Change-Id: I8c26686d7b2fe3bf91af7d4dcab1caf3247dbe47
* Add it to CE HTML, for compatibility with site styles.
* Add it to DM HTML of newly created references only. Existing
references just use whatever classes we got from Parsoid, to avoid
unnecessary DOM changes and dirty diffs.
Bug: T265930
Depends-On: I61a2132f3876e2d9567d985358f51eb51c479813
Change-Id: I9d6856f03071c09617b8ae7db938135a3e30fe8e
If a ref node is highlighted as changed because its index
has changed (e.g. because an earlier reference was inserted
or removed), describe this more elegantly.
Bug: T170235
Bug: T171377
Change-Id: I2513bb82099a92529516e4e217e61a2d0a2dd43b
