@Jdlrobson: Why was this added to the sprint? Because it blocks/affects T150174: Registration date isn't localized on user pages?

Yes. We discussed this in standup and Max asked me to create this task to help shepherd this along. You were there!!! :)

I think human readable timestamps for the grade A browsers and simple timestamps for grade C browsers that do not run JS is an acceptable trade off. This is an enhancement after all and exactly what jQuery was designed for.

The flash of unstyled content is unfortunate, but I don't see a better way to do this, unless we limit ourselves to "Edited this month" or maybe "Edited this week" (at the risk of being incorrect some of the time). We could of course move the user page timestamp down the page a la last modified bar but I think that defeats the purpose of it.

Personally, I don't think there's much wrong with our approach here so I want to sit back and hear some reasoning and suggestions for alternative solutions.

@Nirzar could you speak to what the design motivations/constraints are?

GitHub has an interesting approach to this. Instead of reaching back into the page after it has completed loading, they use custom elements that trigger the needed logic while the page is being parsed.

https://github.com/github/time-elements

This is non-trivial to get started with, but could be adopted more widely if MobileFrontend has success with it. It has many performance benefits overall and should simplify logic considerably. Supported in Chrome, Firefox, Safari 6+, IE 9+. With graceful fallback elsewhere to plain text.

See https://github.com/wikimedia/mediawiki and https://github.com/wikimedia/mediawiki/commits/master for a live example

I do note though that from the captures in the task description, the style changes are a bigger problem than the text changing.

Content
The design requirement here and in any other places is to inform user about sense of time passed. Readers cannot translate timestamps easily. time stamp formats are different in different regions of the world. mm-dd-yyyy, ddmmyy, 21 march 2017 etc etc. Time passed in common units like weeks, months, and years is most understandable and can be easily translated.

Display
FOUC should be avoided as in all experiences. but if fallback requires it, maybe we can have empty space till we calculate the time passed. but no moving parts.

In T160675#3108235, @Jdlrobson wrote:

Yes. We discussed this in standup and Max asked me to create this task to help shepherd this along. You were there!!! :)

I was. I don't remember whether we discussed adding the task to this sprint – though we obviously did.

@ovasileva do we want to keep this task in current sprint?

https://phabricator.wikimedia.org/T160675#3108237 is pretty cool however it seems to suffer from the same problem that was complained about with the existing implementation - the FOUC.

I'm still not clear why the current solution is bad. I'm not sure a spike is useful here, just a conversation.
If the goal is simply to minimise the time for the FOUC this can be done by loading the JS earlier.

Can someone have a go at defining the problem - I forget who raised it during standup.