This makes the dialog's behavior much more robust, especially when
confronted with overly long and complex references.
* Limit the height of list items to avoid the situation where a
single item overflows the dialog. This makes it especially hard
to navigate with the cursor keys. We can't see any more what's
going on. The proposed height is intentionally a very high upper
bound, equivalent to about 2/3 of the dialog's height.
* Limit the name on the right side to take up less than half of an
item. The left side is for the content. Usually the names are very
short anyway. But if a name is long it currently creates a mess
where the name is intertwined with the content.
* Break overly long words in references.
* Changing the opacity to use upstream values makes the dimmed names
a bit darker. I think this is good, even necessary for legibility.
Technical changes:
* Use LESS variables from upstream, where possible.
* Remove redundant `relative` already set upstream.
Bug: T372385
Change-Id: Ie59b7b7e4aa7eadc8f82b39884313f5aa8cfd950
I think that the message is more clear when it starts with the
subject we're describing. That also seems to be the case in other
messages here.
It also aligns with the wording in referenceslist-missing-parent:
"There are subreferences with a missing parent reference."
Bug: T372871
Change-Id: If9a49faccb6cbe2000b15a2d28bd66565cce0e90
Pushes per-group knowledge down into a structured object and give it
an interface, separated from the singleton cache across all groups.
Also changes the behavior of orphaned subrefs so that they're still
rendered as subrefs, with an error placeholder where the parent
should be.
Bug: T372871
Change-Id: I84e679a8365f3fbfabaf344d99f56f6d069c0776
The model is now fully owned by the edit panel and I could not find
any usages of this outside of that class using codesearch.
Bug: T369005
Change-Id: I911fee99d6c910e6e40e0b3cbdb4c7ab60b413c6
Making sure that change events form the fields are handled in the
panel and forwarded to the dialog with the information needed.
Also slighly moving some calls in the setup process that inits
the dialog and removing some duplication. Calling focus on the
edit panel only makes sense in the ready step. Not during setup.
Bug: T369005
Change-Id: I4f9a022a06ec6543b106620eae030235b8f6712b
That's another step to separate the editing form the dialog. The dialog should not know about internals of the edit panel.
And eventually the dialog can get rid of the referenceModel property.
Bug: T369005
Change-Id: I9cf3a68ef58bc5791497af362c0572734e4bcadd
I could not find any connect() was applied from this codebase to
the SurfaceModel. Looking back it seems that the code that connects
the event was removed in Icba13d84e10cf18a6c68e26448b2efe93b8c42b8
and the disconnect was never touched.
Bug: T369005
Change-Id: Ieab623751dd946ba43c42a1be144e6b3725abce3
There's no need to populate and use the form fields when we're
reusing a reference. The group and content are already stored
in the model and we can insert more directly.
I found that it's also not needed to update the internal item
because we're not changing the content or group. The same is done
in Citoid when reusing a reference.
Bug: T369003
Change-Id: I57315aafb73b0cd68a0d397d2f79833ac54a7c7f
Singleton always steps up to the original document from fragments, to
give absolute numbering.
Bug: T370874
Change-Id: I0353649289f6c8fe26fa6bdff5d2367b7b575bac
Mainly leaving out the event handling for the change detection to
still keep it simple.
Also the data flow back for editing the content is still somewhat
opaque because the relevant data is passed by reference. I might
change that in follow up patches so it's more clear.
Bug: T369005
Change-Id: I93b62791ef10bf318697905af8a0c5b5d438fdb5
This patch gives us the same number as will appear in the document,
even when subrefs are present.
Tests could be improved using sinon to check some call assertions
but should be fine for now.
Removed the test for placeholders, because these should be filtered
in MWDocumentReferences.getGroupRefsByParents()
Bug: T370874
Change-Id: I7543a6593308c529bcfbeb0835a7c0882cbf8621
Minor tweak to render the parent as HTML, without fixing anything
else about the layout.
Bug: T370873
Change-Id: I507acf7b86a20d1965bbb32fdc0132b41c929d0c
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
Some wikis prefer to use Western Arabic numerals rather than the
digit transformation table associated with the content language
script. For these, we should respect the existing
$wgTranslateNumerals configuration settings.
Bug: T370585
Change-Id: I663ae28c5b5d4fdd66b8590eb0b453ec25c2db84
This is really just a bug. The reuse tab in the reference dialog
always supported keyboard actions (cursor up and down). It was just
impossible to see it because the OOUI base widget we use here doesn't
come with a default styling for this. I suspect this got lost with
some OOUI update years ago. Let's just fix it.
The colors are what OOUI dictates for this situation.
Bug: T360034
Change-Id: I6cfd423830bc0cc86b1aff5dc08a53c49b6e2d9f
Note this actually changes the "subtle" color to be darker. As far
as I understand this is an intentional decision. The old color token
from OOUI is deprecated and intentionally made darker in Codex.
See Ie667c35 and most notably T313502.
Change-Id: I37ad25aa6821d61fe3321e1390d1ccf987075250
The internal search index is optimized and expects everything to be
lowercase. This was already done for the text, but not for the name
and group. As far as I can see in the Git history this problem always
existed ever since this code was written.
This fixes an 11 (!) year old bug.
Bug: T53838
Change-Id: I12b3b7c23d34d49b630e9151525409dbddfac24e
When Citoid uses these from the new class they can be removed here.
Bug: T369005
Depends-On: I46fa9fe72b4d095291a01c208cac6c98df2ec088
Change-Id: I1aef5d6a05308191d7d8608902a38c801039af7e
First step to move the UI parts that are relevant for creating,
editing (and extending) a reference to it's own class.
There remains some duplication because of the sub-referencing in
Citoid currently depending on the static properties to build its
own editing interface.
More patches follow, I just wanted to keep it small for reviewers.
Bug: T369005
Change-Id: I8588cde1a54cd505a57a36ed97fc591653c9fb6f
Note that the duplicated search panel is most probably a temporary
solution anyway. We probably want a single search panel that can do
both kinds of "reuse with/without different details".
This is also inconsequential for production. Nothing related to
extended references is currently visible on production.
Added to the otherwise unrelated T369005 for code review purposes.
Bug: T369005
Change-Id: Iedee38dacc01ae59fb1a681e49e655ca91b25b64
Mainly to support the activity tracking use case where we want to
track an active use everytime the user starts anew in this UI.
Bug: T368533
Change-Id: Iecf7e697bbbd637c4a00a44debf615c2351eb390
I found that the code is in some cases not clear with the
terminlogy. Let's start by making it at least more clear what's
related to the "reuse" use case.
Change-Id: I5325489be3b14276b0163d8cb8b84215b55d041e
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
Citoid uses placeholder refs to preview where a new/re-used ref
would be added. This also influences the counting and preview in
the reference list for the moment the placeholder is visible.
I can image this that this might become a feature in the future
but for the moment it's a distraction IMO.
Bug: T247921
Change-Id: I5c5e84ae4b183f99530fda0736a58139e9e25d1a
Also introducing a line break to make the difference a bit more
clear what's part of the message.
We still probably want parsed content and not only text here.
Bug: T247922
Change-Id: If545ab2fe1d807a6bcbcdfc0c3b7de83817554e6
This isn't the ideal solution since it doesn't exactly match the
rendered reader view, but it's a reasonable workaround and an
improvement on "undefined" numbering.
Bug: T247921
Change-Id: Ic0d88123d50e2fcb7f25e897280dbfdb6d494501
MVP implementation for adding a warning when editing a reference
that's the extension of another. In the current approach we're
just using the elements .text() like we do when you create an
extended reference.
Bug: T247922
Change-Id: I2fc574152059937b4aa3fc25ee486d363cc809d5
We only need to set some values that are needed by the `insert`
action triggered that then handles the insertion of the ref.
The form to edit or add a reference will never be visible
in the re-use workflow. No need to update that message then.
Change-Id: I710862bdc1bde6a8ce663d863d721cbf075494f0
Includes renaming the method so it's more clear what it's doing.
As preparation for adding the extends warning to the edit pane and
to allow easier identification of parts belonging to the edit
workflow.
Change-Id: If84c5dbdee19c0ebc0a28b50dda93fef3f558c6e
With this patch, we show reflists in a hierarchical view with subrefs
listed under their parent.
TODO in follow-up patch: numbering of subrefs is still incorrect.
Change-Id: Ia82658af72caebd29241b9bd329d236ddc3f1e6d
Pure refactor which shouldn't change output in production. Switches
to interfacing with MWDocumentReferences to get refs in index order.
Temporarily suppresses any subrefs, we only show top-level refs.
Bug: T247921
Change-Id: I9c8347b064173027f436722c87e15e0381c958bd
C&P mistake in the original implementation. Otherwise we end up
with an undefined in the name.
Bug: T362347
Change-Id: I5c6957ca9fc81e6a5211aab050025eea5d0addbe
Same as in I7e82e03. The extra "shield" element was added in
2013 (!), see Ib244ff6. Back then we couldn't use the CSS property.
But nowadays we can.
Bug: T360034
Bug: T367030
Change-Id: Ib41e062491e65eabc8a52facefe283ba04ce16ff
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
I believe this was a mistake in the previous patch Idd57997. Using
only the .text() of the parent reference is not sufficient. Think of
a reference that contains a <math> formula or – even worse – is
nothing but a <math> formula. The preview will be empty in this case.
Click handlers in the preview need to be disabled. It's only a
preview.
Bug: T367030
Change-Id: I7e82e03ecfeb4e9cf132985684cff5e191506307
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
