It'd still be nice to not have this tied to hover, relative dates are more useful to get a gist of how long you've got - those absolute dates are usually what you need to sell it to management.
As far as I know, no browser actually does anything special with `<time>` elements. Might be nice for screenreaders though, so I'll see if I can switch.
I don’t know if this has been done but I suppose a good use of the `<time>` element would be for browser addons to target it and use the `datetime` attribute for something like “add to calendar (ical)” or “translate the text content to my locale” or something similar.
It's an annoying UX antipattern. It doesn't work on mobile, and forces one to use the mouse instead of just seeing the information in its more useful form.
If anything, why not put the "N days from now" text in the title attr instead?
Not every pattern that is controversial is an anti-pattern. Relative time is useful for a different reason than absolute time. One use case is not worse than the other, they're just different.
In our case, we moved a blog from WP to a static Gatsby.js site. It's hosted on Netlify and all content is driven by Contentful where updates trigger a webhook on Netlify to rebuild the blog (new posts are pulled during this build process).
So now you're using 2 different services to host a site, instead of just using hosted Wordpress (or squarespace, wix, etc). Does Contentful provide the same content editing experience? What are the advantages here?
The advantage is that the resulting website being just static pages will be much faster and secure that your hosted wordpress. And compared to wix etc, you have a lot more control on the appearance and structure of your website, because you can use wathever static website builder you choose
How is it more secure when you're still accessing an API? Wordpress itself might not be the best product but other fully-hosted services are all the same, whether they render the site or just give you an API.
A CDN is equally fast when the content is cached, and if you're building the entire site as static pages then it's not really a dynamic site in the first place and can also be done with HTML or markdown in the same repo.
The fine control seems the be the only real advantage, at the cost of more moving pieces.
> How is it more secure when you're still accessing an API?
It only accesses the API with a read-only token during the build process.
> it's not really a dynamic site in the first place and can also be done with HTML or markdown in the same repo
This is definitely true and was an option we considered, however colocating hundreds+ posts with code made the repo unnecessarily heavy and slowed our build time drastically. Our content creators also didn't want to use git to edit their content (they would have to learn git / or use the web UI which is a suboptimal editing experience), nor did I want content creators in our repos.
> The fine control seems the be the only real advantage, at the cost of more moving pieces.
Lots of other advantages that I won't outline here, but our data is completely decoupled from our frontend now, so we can do cool stuff like crossposting to different properties via webhook, data cleanup via API (I ran all the blog posts from WP through some remark tools so we have a more standard look and feel), etc... Might not be the right setup for you, but it works really well for us!
If you're using Contentful then how is that different or better than wordpress or any hosted system that is made for writing posts?
The only 2 advantages of splitting this into separate systems is extra customization (even though hosted solutions are already very flexible) and compiling the entire site into static files. The 2nd seems to be more of a thing for devs to enjoy rather than something that makes a real difference to users, especially when you're already using a CDN.
I think GitHub wanted an option to express "I don't understand this," and decided :confused: was a better fit. Which makes sense, because :thinking_face: could mean "I'm considering this" or "Interesting point," which is not, I think, what that option is meant to convey.
react-styl (https://github.com/nick/react-styl) looks interesting too, but it looks like any preprocessing needs to be done on the client. I'd be worried about performance with that approach on a production app.
