Regardless of the implementation, which of the actual styles are we standardizing on? In other words, should we be migrating OOjs UI's styles to match mediawiki-ui or should we be migrating mediawiki-ui's styles to match OOjs UI? If the answer is 'neither', I hope people realize that means that we will have 4 conflicting UI styles in MediaWiki for the forseeable future: * OOjs UI styles (i.e. Trevor's styles) * mediawiki-ui styles (i.e. Jared and May's styles) * jQuery UI/old-Agora styles (i.e. Brandon's styles) * default MediaWiki element styling (skins)
Kaldari On Thu, Jan 8, 2015 at 9:30 AM, Trevor Parscal <[email protected]> wrote: > 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 > >
_______________________________________________ Design mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/design
