Page MenuHomePhabricator

Add mediawiki.ui dialogs
Closed, DeclinedPublic

Description

mediawiki.ui should have dialogs/modals. The new dialogs in GettingStarted can be used as a starting point, but more work is needed. This includes choosing the right level of abstraction, and how to implement them.


Version: unspecified
Severity: enhancement

Details

Reference
bz55534

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:21 AM
bzimport set Reference to bz55534.
bzimport added a subscriber: Unknown Object (MLST).

swalling wrote:

For reference, the dialogs being used in the currently-released GettingStarted A/B test are in Extension:GettingStarted's resources.

Trevor and Roan mentioned that they may be trying to make ve.ui (aka oo.ui) dialogs available to non-VisualEditor products and wikis. Those may be appropriate to use/adapt for our purposes, we just need to compare it all.

This should include the grey overlay as well. Ideally, this dialog code will be general enough that GuidedTour can be ported to use it as well.

(In reply to comment #1)

Trevor and Roan mentioned that they may be trying to make ve.ui (aka oo.ui)
dialogs available to non-VisualEditor products and wikis. Those may be
appropriate to use/adapt for our purposes, we just need to compare it all.

A WIP for that was just put in Gerrit: https://gerrit.wikimedia.org/r/#/c/88896/

Are you planning to put oo.ui in core? If so, are you going to merge it with mediawiki.ui?

Created attachment 13462
Modal from GettingStarted

This shows an example modal from GettingStarted. This appearance is not necessarily exactly how the core version would look.

Attached:

GettingStarted_modal_and_icon_buttons.png (930×1 px, 302 KB)

(In reply to comment #4)

Are you planning to put oo.ui in core? If so, are you going to merge it with
mediawiki.ui?

oo.ui is going to be a standalone library, but we're planning for MW core to depend on it and bundle it, same as with e.g. jQuery.

I personally would like to make mw.ui an extension of oo.ui, making MW-specific things in mw.ui extensions of generic things in oo.ui, and moving any generic functionality from mw.ui into oo.ui if oo.ui doesn't already have it.

oo.ui is about two years ahead of mw.ui in development time, but we built things as we needed them in VisualEditor so there might be certain kinds of widgets that mw.ui has that aren't in oo.ui yet. Things like dialog support, though, have existed in oo.ui for a long time. oo.ui also fully supports running all of its widgets in iframes (which is how dialogs are done as well).

(In reply to comment #6)

(In reply to comment #4)

Are you planning to put oo.ui in core? If so, are you going to merge it with
mediawiki.ui?

oo.ui is going to be a standalone library, but we're planning for MW core to
depend on it and bundle it, same as with e.g. jQuery.

Makes sense.

I personally would like to make mw.ui an extension of oo.ui, making
MW-specific things in mw.ui extensions of generic things in oo.ui, and moving
any generic functionality from mw.ui into oo.ui if oo.ui doesn't already have
it.

That seems reasonable, though it might take some practice drawing that line.

oo.ui is about two years ahead of mw.ui in development time, but we built
things as we needed them in VisualEditor so there might be certain kinds of
widgets that mw.ui has that aren't in oo.ui yet. Things like dialog support,
though, have existed in oo.ui for a long time. oo.ui also fully supports
running all of its widgets in iframes (which is how dialogs are done as
well).

I don't really know much about the advantages of iframes for this kind of thing. However, I did have some issues (e.g. full horizontal and modal centering), so if it solves that, that would be nice.

We'll be supporting more browsers than VE does, so oo.ui will need to do the same if we take that approach.

(In reply to comment #7)

(In reply to comment #6)

(In reply to comment #4)
oo.ui is about two years ahead of mw.ui in development time, but we built
things as we needed them in VisualEditor so there might be certain kinds of
widgets that mw.ui has that aren't in oo.ui yet. Things like dialog support,
though, have existed in oo.ui for a long time. oo.ui also fully supports
running all of its widgets in iframes (which is how dialogs are done as
well).

I don't really know much about the advantages of iframes for this kind of
thing. However, I did have some issues (e.g. full horizontal and modal
centering), so if it solves that, that would be nice.

iframes are mostly to allow text selection, focus and other complicated and cross-browser unstable states to remain while the dialog is up.

As for centring, the iframes don't particularly help there but I do know that in VE we have a satisfying way of centring the dialog vertically/horizontally.

The centring of dialogs is generally a solved problem in web development afaik. There's different ways to go about it, but there's at least 1 commonly used way that works.

On the subject, oo.ui dialogs do have an interesting aspect that is worth mentioning. They don't require a fixed width/height. CSS min-height / max-height is dynamically honoured (it can shrink/grow, and overflow:auto will show scrollbars if needed), and browser resizing as well.

(In reply to comment #7)

We'll be supporting more browsers than VE does, so oo.ui will need to do the
same if we take that approach.

As far as javascript code itself, we currently require the browser to support most ES5 features (IE8 is missing some ES5 features, but we haven't needed those yet, and we keep an eye out for those with feature tests).

At this point we only use ES5 features that have established polyfills (Array#filter, Function#bind, Object#create, String#trim, JSON.stringify etc., full list at[1]). We don't polyfill them right now because we don't have to, but we can easily bring in an es5shim if we have to.

As for the CSS, that's going to be the area that'll need most manual testing and fixing. I think most browser bugs we account for date back pretty far (we tend to IE8, Opera 12 and recent Firefox/Chrome).

Though IE6, IE7 and Firefox 4 (which would be the main browsers missing between VE requirements and MW requirements) do have a ton of specific quirks, afaik those are all bugs that can be worked around, not actual missing CSS features that would be blockers (aside from CSS3 enhancements, which will be absent but those degrade gracefully).

[1] https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/4da68b71d11f15b10e2e1f418025b438954e7da5/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js#L68-L85

(In reply to comment #8)

As for centring, the iframes don't particularly help there but I do know that
in VE we have a satisfying way of centring the dialog
vertically/horizontally.

The centring of dialogs is generally a solved problem in web development
afaik.
There's different ways to go about it, but there's at least 1 commonly used
way that works.

I have a working solution, but it doesn't work in IE 6 or 7 (bug 55487). If you have a recommendation, I'd be glad to look at it.

On the subject, oo.ui dialogs do have an interesting aspect that is worth
mentioning. They don't require a fixed width/height. CSS min-height /
max-height is dynamically honoured (it can shrink/grow, and overflow:auto
will show scrollbars if needed), and browser resizing as well.

Unfortunately, that's an example of a compatibility issue which we're going to have to grapple with. IE6 apparently can't support both min-height and max-height on the same element (http://stackoverflow.com/questions/1467664/how-to-implement-cross-browser-min-height-and-max-height-at-the-same-time)

As for the CSS, that's going to be the area that'll need most manual testing
and fixing. I think most browser bugs we account for date back pretty far (we
tend to IE8, Opera 12 and recent Firefox/Chrome).

Though IE6, IE7 and Firefox 4 (which would be the main browsers missing
between
VE requirements and MW requirements) do have a ton of specific quirks, afaik
those are all bugs that can be worked around, not actual missing CSS features
that would be blockers (aside from CSS3 enhancements, which will be absent
but
those degrade gracefully).

Yeah, I primarily meant CSS and rendering. I agree some have relatively simple workarounds. However, others are a bit more complicated.

Matt originally wrote:

The new dialogs in GettingStarted can be used as a starting point, but more work is needed

Flow has implemented a general-purpose mw.Modal in mw.ui.modal.js, see Shahyar's e-mail to the design list in October "MW UI Modals First Version & Concept" (in ASCII, but much easier to read the original HTML). There are a lot of features in Flow's modal tailored to the design spec in Trello. It use OOjs' EventEmitter.

OOUI's dialogs with the mediawiki.ui skin are probably a viable alternative.

OOUI's dialogs with the mediawiki.ui skin are probably a viable alternative.

Yeah. If there is a general consensus to move to OOJS-UI, this is probably a WONTFIX.

Krinkle claimed this task.

The mediawiki-ui styles in core are still maintained a little while longer, but dialogs seems like quite a significant task to take on. Engineering effort that is probably better invested elsewhere.

Closing for now, though patches welcome if someone can volunteer reviewing it.