Page MenuHomePhabricator

Parsoid HTML/RDF for mobile devices
Closed, DeclinedPublic


A Parsoid HTML/RDF mobile output, similar to what can be found at would be really useful. In my case, I would use it to create mobile specific ZIM files.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:57 AM
bzimport added a project: Parsoid.
bzimport set Reference to bz53018.

This can be implemented as a post-processing step on Parsoid HTML. The rich RDFa information in our DOM (see should make selective massaging easier.

Arlolra set Security to None.

I see we have now a mobile HTML output, for example here:

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

Jhernandez subscribed.

We'll reopen if there is a need for this. We're not planning on working on it right now.

@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:

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.

I'll keep it as stalled while we discuss, declined may have been to strong.

LGoto closed this task as Declined.Oct 9 2020, 4:50 PM