Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Drop local-time concern, relative-time is whats interesting #9

Closed
josh opened this issue Apr 28, 2014 · 4 comments · Fixed by #12
Closed

RFC: Drop local-time concern, relative-time is whats interesting #9

josh opened this issue Apr 28, 2014 · 4 comments · Fixed by #12
Assignees
Labels
Milestone

Comments

@josh
Copy link
Contributor

josh commented Apr 28, 2014

We really don't even use the regular date localization in github itself. It was probably premature to even try to extract it.

Maybe we can rename and focus this library on <relative-time>.

what do you guys think?

/cc @mislav @eanakashima @dgraham

@dgraham
Copy link
Contributor

dgraham commented May 8, 2014

To summarize the conversation @josh and I had in chat:

  • Not much code can be deleted if we remove local-time. The sizable amount of strftime code, in particular, needs to stay regardless, because it's used in relative date formats older than two days (e.g. on May 6, yesterday at 11:45am).
  • Separating the behavior into two elements–local-time and relative-time–makes sense because relative-time needs a periodic JavaScript timer function running, while local-time doesn't. It also removes the magic relative keyword value in <local-time format="relative">. The format attribute is then strictly for strftime formatting strings.

So without much code size savings, the question is whether we need local-time at all. We used it in only one place on the site, which @josh recently converted back into static Ruby rendering in UTC time. I'd like to keep local-time, though. We're almost getting it for free since most of the JavaScript is related to formatting and updating relative times.

@dgraham
Copy link
Contributor

dgraham commented May 8, 2014

One other approach we could take is to subclass the standard <time> element with the web component is attribute. So a standard <time datetime="2014-05-08T14:35:00-06:00"></time> element becomes:

  • <time is="local" format="%l:%M%P" datetime="2014-05-08T14:35:00-06:00"></time>
  • <time is="relative" datetime="2014-05-08T14:35:00-06:00"></time>

@josh Any reason you originally opted for a new custom element rather than subclassing time?

@josh
Copy link
Contributor Author

josh commented May 8, 2014

I actually kinda like dig that idea.

I'd say I didn't originally subclass because <time> itself offers nothing interesting over the basic HTMLElement.

Its a bummer, but even is requires a - prefix in the name. So its going to have to be

<time is="local-time">
<time is="relative-time">

I really like this, lets do it!

@eanakashima
Copy link

👍 ✨ Really like the look of <time is="local-time"> and <time is="relative-time">.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants