(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