Jonathan Aquilina wrote: https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering https://lists.wikimedia.org/mailman/listinfo/mobile-l irc://irc.freenode.net/wikimedia-mobile Yes we have some mobile things. Admittedly the mobile web world is a bit broken and browsers don't use localStorage reliably and don't work on the default CSS being pretty; we end up putting some sweat into writing "native" apps. Mark A. Hershberger linked to more details. I would like to stress that the MobileFrontend is a bit like a skin and it needs YOUR help to make it reasonable. Last I tried, it was rather limited. I wouldn't mind us writing more mobile-friendly skins which don't involve PHP and redesigning the preferences screen just for one platform. -- svetlana

Jonathan Aquilina wrote: I have no idea whether mediawiki allows to write "layouts" without touching PHP. Would suggest to check that first. -- svetlana

On Thu, 11 Dec 2014 05:58:48 +0100, Jonathan Aquilina <eagles051387(a)gmail.com> wrote: I am not sure what you mean. You can't avoid writing PHP entirely when creating a skin (it's not a real "templating" language), but you don't need to write a lot of it and you can copy-paste samples. https://www.mediawiki.org/wiki/Manual:Skinning is helpful. -- Bartosz Dziewoński

The answer is not as simple as that. First let's try to explain the structure a bit. All existing skins are a combination of a PHP template and a set of CSS. When we say Vector, we mean the PHP UI template vector, and the CSS that goes with that template. This template itself only handles everything outside the 'content', which is usually the sidebar, topbar, footer, the 'mostly static' areas of every single viewed page. The Vector CSS targets these elements as well, but in addition also targets elements of the content (some of which it shares with other skins). As you might note, it already sounds chaotic. The currently shipped by default CSS skins (and especially the MobileFrontend one) are as responsive as is useful, considering the constraints of the user base, our not too consistent classnames and IDs and the totally 'unstructured' content that is created by MediaWiki or that is the output of the wikitext of a page. There are also a lot of constraints on these classnames and identifiers, because they are widely used inside scripts of 100s of modules and extensions etc and used and defined all over the place internally wherever 'content' is generated. And then there are things like rtl and mixed rtl and ltr environments, accessibility etc to consider, which most sites happily ignore :) These constraints are what makes the authoring of a skin a complex task in MediaWiki-land, especially if you want to target existing audiences. Writing a bunch of CSS and PHP is easy, making it work across everything that is currently already in use without pissing of existing customers is what is hard. Improving the structure, the responsiveness and removing the technical and historical debt are things we work on all the time, but by the nature of our Wiki landscape it will be a very slow process, still requiring some 4 more years to get to where we need to be (just my guess). To get closer to the answer you were probably looking for: there are no existing layout classes in use by mediawiki, other than the very new and not yet widely deployed https://www.mediawiki.org/wiki/OOjs_UI layouts, If you make a new PHP skin, you can add such classes of course (or u add them by way of JS), but u will break some pages and fixing this 'long tail' is where your biggest challenges would likely be (and the separately shipped and maintained responsive MW skins Chameleon and Foreground, might feel non-responsive due to similar long tails). Experiments in this area are very welcome, and will feed into the improvements we make. Use the skin wherever u want, but don't get your hopes up for a deployment to a WMF wiki, because that is unlikely. Hope that answers your questions. DJ On Thu, Dec 11, 2014 at 10:22 AM, Jonathan Aquilina <eagles051387(a)gmail.com> wrote: