Timo is spot on, as usual. Everything he said, I am being completely. Additionally, the lack of public communication is not an oversight. It's planned, and we are on schedule. Give it a week. Documentation is already being moved to the wiki over the next few work days[1], the finishing touches are waiting to be merged for the PHP implementation[2], the first interfaces are being converted[3] the template stuff is stalled on the Flow team conforming their code to upstream light-n-candy[4].
Also, high-level notes about our activities were discussed October's monthly engineering report[5]. - Trevor [1] http://www.mediawiki.org/wiki/OOjs_UI/Documentation [2] https://gerrit.wikimedia.org/r/#/c/182875/ [3] https://gerrit.wikimedia.org/r/#/c/183390/ [4] https://phabricator.wikimedia.org/T75440 [5] https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/October#Front-end On Thu, Jan 8, 2015 at 2:33 AM, Timo Tijhof <[email protected]> wrote: > A few quick thoughts: > > * One could argue the mediawiki.ui implementation was never destined to > become a standard/default implementation to begin with. The design is > staying (or that direction at least), but not the implementation. However > that didn't prevent people from using those classes outside the intended > usage area (e.g. selected areas in core and certain extensions that need > the look and feel now, while OOjs UI was being worked on). I warned against > this when it was added to the default page modules, but alas. I guess > people either didn't realise what it meant or are okay with having to > migrate twice (once to mw.ui.less and now to oojs-ui). > > * The factor of how easy a class is for a human to grok is mostly > irrelevant. OOjs UI's API isn't single classes. The HTML isn't meant to be > written by hand on a page.[2] To achieve the features we need and, more > importantly, browser support; a single element with some classes doesn't > suffice. The browser's themselves have a lot more than one element, too. > They just hide it via ShadowDOM.[1] Until we can either reliably use CSS3 > and CSS4 features or HTML5 Web Components across browsers, we'll need most > widgets to be two or three elements in the public DOM. Another reason for > not maintaining such HTML by hand is because it can change and you'll want > to keep maintenance central and minimal for when that happens. We'll keep > breaking changes to a minimum (especially those requiring html changes), > but expect them to happen (especially in the first year). > > * Perhaps we should freeze mediawiki-ui. Then keep around until we're > comfortable removing it. No new features, design syncs or other changes. > Focus efforts on OOjs UI, and slowly migrate towards that. Including OOjs > UI "no-js" entry point where a lighter html footprint is required. > > — Timo > > [1] Here's an example of Chrome rendering a simple input field with > placeholder and a number input field, exposing the internal elements the > browser utilises to render it: http://i.imgur.com/CWQ2Htj.png > [2] This is easy for JS and PHP, but for wiki pages the community should > use an abstraction for that html. Templates or Lua modules are the > appropriate venue for that. > > > On 8 Jan 2015, at 04:18, S Page <[email protected]> wrote: > > (I couldn't find a list for "Frontend standards group" and I'm not sure if > all its engineers are on the design list.) > > I congratulated James_F on IRC for VisualEditor/ OOjs UI adopting the > mediawiki.ui style, but then it went topsy-turvy: > > *spagewmf* I missed that VisualEditor is now using the mediawiki.ui > style formerly known as "Agora" > *James_F* No, we are not. > Agora and MediaWiki.ui are both previous designs. This one is different, > apparently. > Don't ask me how. :-) It's mostly similar, at least. > It's the MediaWiki Theme for OOjs UI. > > *spagewmf* How is WMF keeping the "simple" mw-ui-button > mw-ui-constructive and OOjs UI's more elaborate oo-ui-widget > > oo-ui-buttonElement oo-ui-flaggedElement-constructive CSS in sync? Are > we able to share LESS rules? > *James_F* MW UI isn't being kept in sync with the new design, I believe. > I don't think it's credible to try to marry the technologies together with > shared files – it'd be a huge amount of work for a short-term hack. > > *spagewmf* The mw-ui- classes are a lot easier for humans to grok/reuse, > e.g. https://en.wikipedia.org/wiki/Template:Clickable_button It could be > very cool for pages to have OOjs UI gadgets someday. > *James_F* Well, tough. :-) MW-UI won't be around for much longer. > > > How soon is "short-term" and "not much longer"? It's less than a year > since mediawiki.ui.button made it into the default set of page modules and > the Living Style Guide > <http://tools.wmflabs.org/styleguide/desktop/section-2.html> appeared. > Are devs going to continue working on $wgUseMediaWikiUIEverywhere to > deliver UX consistency? > > I understand the approach espoused by the Frontend standards group > <https://www.mediawiki.org/wiki/Frontend_standards_group> is "use OOjs UI > <https://www.mediawiki.org/wiki/OOjs_UI> components" and I'm excited to > see Bartosz prototyping the UserLogin form in oojs-ui/php. But it'll be a > long time before the 15 extensions using mediawiki.ui have all transitioned > to OOjs UI. > > I look forward to the "Frontend standards" session at the developer > summit. “The future has arrived — it’s just not evenly distributed yet.” > > Cheers, > -- > =S Page WMF Tech writer > > >
_______________________________________________ Design mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/design
