The whole point of having a living style guide was to prevent the endless
proliferation of outdated MediaWiki style guides (as we were creating about
1 a year for a while). Now we're somehow doing the same thing yet again. Is
it really impossible for us to stick to a single style guide?
On Fri, Jan 30, 2015 at 4:22 PM, MZMcBride <z(a)mzmcbride.com> wrote:
> Hi.
>
> Re: https://www.mediawiki.org/wiki/Design/Living_style_guide
>
> This page is kind of sad right now. It references
> <http://tools.wmflabs.org/styleguide> pretty heavily, but my understanding
> from <https://phabricator.wikimedia.org/T88036> is that
> <http://living-style-guide.wmflabs.org> is the actual style guide now? I'm
> not really sure and I'm worried that if I can't keep up, nobody else
> stands a chance! ;-) But really, we want to make sure everyone is
> discussing the same project.
>
> It would be great if someone more knowledgable than me (about the living
> style guide!) could update the wiki page and the description of
> <https://phabricator.wikimedia.org/tag/living-style-guide/>, at least with
> the best URL, if tools.wmflabs.org/styleguide is no longer it.
>
> MZMcBride
>
>
>
> _______________________________________________
> Design mailing list
> Design(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/design
>
That was an embarrassing overlook, fixed!
On Tue, Feb 3, 2015 at 5:41 PM, Rob Moen <rmoen(a)wikimedia.org> wrote:
> On Tue, Feb 3, 2015 at 4:29 PM, May Tee-Galloway <mgalloway(a)wikimedia.org>
> wrote:
>
>> displayed
>
>
> Great job May!
>
> Is the white stripe in the unflag_icon un-intentional? (see what I did
> there?) Seems it should be a transparent line going through like the other
> Un_icons
>
>
> --
> Rob Moen
> Wikimedia Foundation
> rmoen(a)wikimedia.org
>
--
mm
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#Fr…
On Thu, Jan 8, 2015 at 2:33 AM, Timo Tijhof <ttijhof(a)wikimedia.org> 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 <spage(a)wikimedia.org> 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
>
>
>
