[Gutenberg] Add amp-timeago block

[miina]

Adds amp-timeago Gutenberg block.

Note: see discussion in #1146 on the usefulness of having this as a standalone block.

[westonruter]

To quote #1146 (comment):

It seems difficult to use amp-timeago in an a non-block context, though. Here I'm just talking about block and inline elements, not specifically Gutenberg blocks. For example:

<p>The new year started <amp-timeago width="auto" height="20" datetime="2018-01-01T00:00:00.000Z">January 1st, 2108</amp-timeago> and I am so glad.</p>

Comes out:

And:

<p>The new year started <amp-timeago width="100" height="20" datetime="2018-01-01T00:00:00.000Z">January 1st, 2108</amp-timeago> and I am so glad.</p>

Comes out:

Both of these clearly are not right in an inline context where flowing text is desired. I'm sure it has to do with AMP's need for layout as for why the element has these constraints which make it difficult for use in an inline context. I've noticed a similar issue with amp-mathml, where I'd normally want Math to appear inline, but this again is a challenge for layout.

If these constraints remain, I'm not sure that amp-timeago really makes sense as a Gutenberg block or a shortcode. It would make more sense in the theme templates like for the post's publish time, where it does not exist in the context of flowing text.

[westonruter]

I think the attributes should be sourced from the children element attributes, as done in amp-fit-text: c3d9915

This prevents the data from being duplicated between the block comment attributes and the content of the block. This means that if you edit the HTML you don't have to make sure that the two sets of attributes are in sync.

[westonruter]

Please do the same for amp-mathml and any other blocks.

[miina]

Good point, added the sources, currently within this PR, however, not sure if this PR will get merged anytime soon, let me know if it would be better to add in a separate PR.

[westonruter]

@miina I think we might as well merge amp-timeago as an experimental block for testing. So I think we should go ahead and merge the PR. Nevertheless, one thing is blocking this. I'm getting an error:

Jed localization error:

Error: Domain amp was not found.

I have both languages/amp.pot and languages/amp-js.pot files in the filesystem.

Also, it seems JS source maps aren't being when compiling? It's making it hard to debug. Can that be enabled?

[westonruter]

@miina Actually, the error fixed in f65439a and the localization error are both in develop too. So this PR is a good place to fix them.

[miina]

@westonruter Looks like this error occurs if amp domain is used in JS files before locale data is set (wp.i18n.setLocaleData), this was the case for block files (/blocks/*) -- locale data was set after the script. Making sure that it's done before fixes the error. (Should we fixed now.)