Last modified: 2014-08-28 18:01:46 UTC
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.
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 [details] Modal from GettingStarted This shows an example modal from GettingStarted. This appearance is not necessarily exactly how the core version would look.
(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.
