fixes bug 1304108 - call the custom time tag time-tag

[peterbe]

No description provided.

[lonnen]

There are a couple different places that we use time and timeago -- did you consider the other patterns and possible re-use or refactoring?

[peterbe]

As far as I know there are no other places. We use a jinja template function to generate these tags and the file (timeutils.js) to go with it. If I'm wrong, @adngdb might just know by heart because he worked on this quite recently.

[adngdb]

I don't understand this. The point of that helper was to create these <time> tags. They are semantically correct: they represent "either a time on a 24-hour clock or a precise date in the Gregorian calendar". What is wrong with that?

[adngdb]

OK, after reading the bug, I understand why you are doing this, but I strongly believe this is not the right solution. Our HTML here is correct, the bug must lie somewhere else.

[peterbe]

Yeah, there is something strange going on. It's so weird that I can, on the first run, change the time tag's color and border css. But I can't change its text.
But if you wait a couple of seconds, (even after the $(function() callback has executed) you suddenly CAN change its text. It was reproducible in Chrome too. But I couldn't make a jsFiddle that demonstrated it.

I suspect that the browsers are full of optimizations to handle these <time> HTML5 tags. These optimizations somehow, maybe, kick in right after DOM-render-ready and thus block jQuery's ability to update the text.

Another option would be to try to upgrade jQuery to either the latest 2.x version or even jump to 3.x. This doesn't necessarily solve it.

[peterbe]

By the way, I think it was my idea in the first place to call the tag time. If so, I'm sorry. I now know that it's better to use a hyphen in the tag name when you use a custom tag.
I don't remember the reason but one of them was for the sake of Internet Explorer. (Only 2.5% of our traffic) But also a good reason for using a hyphen in a custom tag is to really cement to the code reader that it is a custom tag.

I addressed this in airmozilla but sadly I didn't take any notes about why.
mozilla/airmozilla#738
I do remember doing it after running the html5 validator on the code and this was one of the things I got encouraged to change.

[peterbe]

@adngdb Any chance you can up this one a bit?

[adngdb]

I investigated this a bit more and it turns out the issue was caused by a conflict between our timeutils.js file and profile.js. Both files were trying to do the same thing, and the second one to come in was failing at parsing the date, thus showing an error.

I'm closing this in favor of #3536.