This can be implemented as a post-processing step on Parsoid HTML. The rich RDFa information in our DOM (see http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec) should make selective massaging easier.

I see we have now a mobile HTML output, for example here:
http://rest.wikimedia.org/en.wikipedia.org/v1/page/mobile-html/Paris

But the problem is that the (mobile) dependencies are not loaded (to the contrary to the desktop version)

Tagging this for the Web and Infrastructure teams.

@Jhernandez I understand that priorities need to be set but this is quite sad and a really concrete problem for offline projects. Parsoid output is the only one output which allows to properly re-render our textual content. Not providing a proper mobile version seems to me quite a problem considering how people access the content these days. For openZIM/Kiwix problem, it means higher maintenance costs (if possible at all) to try to maintain a mobile rendering similar as online. CC @atgo.

Hi @Kelson, I'm using priorities as stated on mediawiki. Low is not a bad thing, it means:

Less priority than Normal, but someone is still planning to work on it. This does not necessarily mean the task is not important; it is just not on the to-do list of anybody as the task is not considered urgent.

I'm interested in discussing more about this and understanding the meaning and the usecases, and how it could relate to the things that we have planned.

We are building indeed a mobile specific HTML endpoint right now and a set of JSON endpoints to go with it, that the apps will switch to consume, and hopefully mobile web could use them in the future too.

This are the most relevant epics:

• T169242: Develop Page Content Service for Reading Clients
  • T177426: Develop structured JSON APIs for general consumption
  • T177433: Develop HTML Content API to be used with companion structured JSON APIs

In summary, there will be a /page/mobile-html endpoint based on parsoid HTML with many transforms applied to the content to make it leaner and more mobile friendly. There will be /data/mobile/css endpoints and /data/mobile/js endpoints that will provide mobile specific styles for that mobile HTML and some mobile specific JS to act on the mobile HTML for things like lazy loading of images.

There will also be a set of JSON endpoints that will provide the additional information about the page, like /page/summary, /page/metadata/, /page/media, and /page/references.

When you mention before in your comment:

But the problem is that the (mobile) dependencies are not loaded (to the contrary to the desktop version)

What does that mean? What difference do you see from /page/html?

I'm happy to expand more and keep talking about what of the pieces we have can fit your use case.

For example, apps will have offline article storage, and the way that they will do it initially (as far as we have talked about it until now) will be to fetch the mobile-html endpoint, the CSS and JS endpoints + the other 4 endpoints, and store them in cache, and with those things, they will be able to show the full article as needed without a network connection. It will give them the flexibility as well to cache more or less things if they want to, improving how much space they take.