2026 JS‐less localized absolute time formatting

WEH 2026 - JS-less localized absolute time formatting

• GitHub issue: https://github.com/Igalia/webengineshackfest/issues/91
• URL: https://meet.jit.si/WEH2026-js-less-time
• Slides: https://docs.google.com/presentation/d/1rW-XUzN9GpmWsOxv33uxizafMt9vOzlolqKkdBNJ7CQ/edit?usp=sharing

Eem: think about the problem we want to solve first, rather than jumping to the solution. The interest seems to be printing time but it's about internalization, DOM localization. The real solution implies not just time but other steps along the way.

Keith: Time element itself is relative straight-forward, the attributes for <time> should probably be married to Intl APIs.

Eem: In messageformat2, we've been considering alternatives other than the ECMA-402 options bag. ECMA-402 allows variability that is not generally needed (e.g June 4:00), we are considering other options. We should probably not discuss that until we've figured out lower level concerns.

Keith: The more interesting meta problem, also in regards to <amount> element etc, we should figure out how these work together. Particularly around how we replace the content, we should be consistent.

Keith: RE CSS content, this doesn't work in <div> right now, only in :before and :after. I think we should use shadow dom for <time>, but I don't think we can use that for all localized content because it would be too costly to have many shadow doms.

Jake: No strong opinion, but doing it in CSS would mean you can use media queries to change formatting. What about relative time?

Anne: The content property does work on other elements, but with some restrictions. We could make it work for a new format function.

Oriol: Overlap with https://github.com/w3c/csswg-drafts/issues/13659, https://github.com/w3c/csswg-drafts/issues/13655, https://github.com/w3c/csswg-drafts/issues/9710.

Daniel: We [Nuxt], have a component in our framework that does exactly this. It would be really nice if what we do here works for relative time also. The "two days ago" works in most cases, but shorter relative times ("two seconds ago") breaks down quickly. We already have options bag for how to format dates, so we should start with that.

Luke: I think the CSS approach fixes most problems like replacing text nodes breaking frameworks. It adds many new problems, like clipboard interaction. Also the a11y side, we need to make sure that's taken into account.

Henri: considering that there are existing frameworks, it seems to me that modifying the DOM would cause problems with frameworks, because they may collide reconsiliation with browsers. I do see the point of clipboard interaction. The <time> element does not have a notion to display a time without a date.

Eem: the current situation is that datetime attribute, and the inner text are not validated together, so I don't think this is a problem. Because of this old browsers still work, while new browsers would replace the inner content.

Jacob: At the OS level users can specify the format of date they want to see. It is annoying if web pages do not respect this.

Eem: This is linking up to user preference discussions that we should probably not discuss here.

Henri: User preferences are a good fingerprinting method. We need to decide early on whether we expose to the rendering more of the user preferences, than we expose to the JS API. If we want this to be more user preferences than the JS API, then we need to design this very early.

Phillip: Follow on from Jacob's point: how much customization of the date format do you want to allow in this element? Eem says it's too customizable, but many users want more customizable (e.g using alt date separators).

Keith: RE Daniel's comment on relative time: at GitHub about two or three times a month we'd get complaints like "1 month ago" is not the same as "29 days ago". Relative time is a really nice feature, but it is very complex.

Luca: lets' take less time discussing how to format the dates and more discussing how we display the formatted date on the page

Brian Kardell: you can take into account user preferences like browser UI, but is it a matter of how much this is content vs how much it's browser ui?

Eem: the potential of the browser ui for local time has been there forever but it's insufficient and we need to solve a broader set of problems

Simon: let's talk about content: text-transform does seem to work, but selection currently does not. It is exposed in a11y tree in Firefox and other browsers.

Marina: we've seen something similar with opengraph things like the publish time, I don't think we should repeat that.

Jacob: we already have in datetime format stuff, "short" "medium" "long", we were discussing how to use this in CSS. It seems like this is an overcomplication. What if we had a way to opt-in or out of the adaptive behaviour proposed before.

Anne: What is "something else" when you say overcomplicated.

Jacob: too many options will be overcomplicated

Anne: ah I see, this is about API again. I think we should start with something similar, so maybe not everything that TC39 has done for Intl, but it should allow for growing towards that feature set.

Keith: back to relative time, at GitHub we also add title to the time elements, but that doesn't work for screen readers because it's not focusable.

Simon: comment on the complexity of the css solution, the browser should provide user-agent stylesheet, we need to provide a way to opt-in in html

Eem: It sounds like making the element media query aware would be very powerful. Making the text selectable and copyable does seem very useful.

Daniel: an attribute on <time> seems much more polyfillable than the CSS approach. The moment you start looking at CSS, it becomes much more complicated.

Marina: Just going thru CSS because of media queries seems like a stretch. One could imagine other things like having two elements, that are hidden/shown based on media queries. I would go for HTML and build ontop of that.

Jake: there would be nothing stopping us from adding media queries into the attributes also, or micro syntax like the sizes attribute. We should consider individual styles for parts of the times and dates.

Anne: not being polyfillable sounds like a feature because polyfills may limit what we can do.

Eem: for durations, it would be a script that updates the durations.

Anne: but if the element natively computes the durations.

Andreas: constantly updating the text is hard, mobile browsers will hate it, so maybe not spec it

Luca: I don't think it's useful to say we can not do this at all because of power consumption, because if browsers don't do it, users will do it in JS which is even worse.

Eem: We are discussing doing that for absolute time format. Is anybody oposed with RalativeTimeFormat?

Keith: Relative time formats are complex, server can be mismatched to client especially with short periods, users see comments posted in the future.

Anne: It would be the number 1 feature request if we didn't do it.

Simon: Perf of css vs script, in CSS we can optimise away stuff out of the viewport, if we update the light dom that's observable to script so we can't do that.

Jake: even if it wasn't DOM, CSS would change the width of the element.

Simon: we may need to allow not updating if the element is not visible.

Keith: But it could become visible if re-rendering would make it collide with the viewport. Maybe could use some scroll watcher but that's just moving the problem

Luke/Simon: We do already have a scroll window for lazy images.

Simon: we'd need intersection observer for all time elements.

Marina: IMO, I'd solve relative time in another follow-up PR. This in itself is already a big thing. Maybe we could do some middle thing that we do absolute timing in HTML and decide whether to show relative time in CSS. The absolute value is there so screen readers can read it

Andreu: For relative time updates, can we set a contain: size with !important in the UA stylesheets, or would that be confusing?

Keith: What size

Andreu: Maybe height: 1lh, some width, and let the author override it.

Keith: There was a comment about screen readers. Screen readers need to read out what is displayed (the formatted time), not some other transposed date.

Keith: Also, the content property in CSS allows putting a / and then an alt for the screen reader.

Luca: Want to get back to HTML vs CSS thing. What are the issues we foresee with each of these? From what I've heard, for CSS, the problems are selection and copying. Are there other things?L

Eem: The way I see this, is that HTML defines what we are displaying, and CSS defines how we are displaying things.

Luke: I think the correct way would be to start with HTML, and then the way the browser implements this is akin to CSS content rather than light/shadow dom updates. Not exposing that to the user makes things simpler, we don't have to expose those CSS functions. Another thing about HTML vs CSS is localization in languages, like "2 seconds ago". If the browser does the localization it's workable, but in a state with e.g. a Google Translate extension it's going to be able to do stuff in shadow DOM but not in CSS.

Jacob: CSS is supposed to be about how pretty it is (multiple "erms" and laughs), or lack there-of, and this makes content different, so I'd think this is an HTML thing.

Luca: Luke said "akin to CSS". We have elements that do this, like <input>, where the text that you see is not visible in the light DOM but it's rendered by the browser, as a widget. But again it has probelms with selection inside/outside the element, and CSS highlights.

Keith: Those problems are different. <summary> elements are in the shadow dom and don't have the same problems. I don't think selection in the shadow dom is necessarily a problem here.

Henri: I think this is not the right thing to consider. The question is "is this owned by the UA or by the script?". We have some complex features where it's kind of owned by the UA, but it's too complex to hide it from the script so it's visible, and the UA and script poke at the same place. Those tend to lead to bugs. When the UA is meant to be in control, CSS is where the UA already controls what goes on and where. While inserting a node, somebody can observe a node being observed and run scripts. I'm less interested in having the UA take an action that is visible to scripts, and the script can inject itself in a UA taking an action. So this feels like it should be CSS. Compared to DOM Localization this feels small too so fits more for CSS

Keith: One problem with CSS is flash of unstyled content and layout shift. If it was just HTML, we could render on the closing tag. Or on the open tag.

Eemeli: One aspect that Henri mentions is if is DOM localization another step from this. We should be aware that the way we format datetime might be locale dependent, so we might want to include a <time> element in localizable content. This becomes straightforward to define if the attributes are defined in HTML, but if it's in CSS it becomes complex.

Luke: There are two conversations happening: what does the API look like to the web author, and how it's actually implemented. If the UA sees this HTML element and does it with CSS, it solves some problems, and it does not mean that the web author has to also do it through CSS. And you don't have FUC.

Keith: You still do have layout shift problem, if you customize it. So only as long as you don't customize it.

Luke: If the web author only interacts through CSS, and the CSS feature is an implementation detail, then we get the solutions of CSS without the complexity of the authors coming and doing that stuff.

Henri: To clarify, I don't intend to say you'd configure it only via CSS. You'd primarily configure it through HTML attributes, but then the formatted string goes in the layout tree and not in the shadow or light dom.

Luca: Let's dig in to the selection problem

Luke: It doesn't work

Keith: Is the problem with selection because of content, or because they are pseudo elements?

Olli: Selection is DOM range based.

Thomas: Question about find-in-page: should this show up? Users might search e.g. for "seconds ago" to look for comments.

Jacob: About content from CSS not being selectable: it's what we were saying before, CSS is only supposed to be about the visual. If we change that, it's going against its intention.

Jake: Could you speak about the impact on hidration in frameworks?

Daniel: There is a challange, but it's fixable. Frameworks have ways to ignore hidration mismatches. A question I have is what happens if we write to the text content: do we discard it? Like, if a frameworks writes content because it's what frameworks do today, but then if the browser it's taking care of it, it should discard the write. Then it would be fine.

Ryosuke: The fact that you can't select the pseudo-element is really a bug. The fact that it's a pseudo-element is not relevant to users. They see text, they want to select said text. We've been discussing how to address selection inside of input elements, and I think this also applies here. OpaqueRange or similar object could be suitable. We should holistically solve this for all generated text.

Henri: you have to update the element all because it's visible. If the UA goes and changes script observable dom and script reacts on the change, it adds security problem. And the timing becomes compatibility sensitive. Using CSS vs HTML matters on running scripts, e.g. setTimeout timings

Luke: script runnability problem also existing on CSS with resizing

Keith: selectedcontent element has been an issue for developers as it clones the selected option element into the light node tree which can be a problem when you expect to be in full control of that tree. Shadow tree might be a solution.

Oriol: In CSS, it is allowed to allow user-select being set on ::before and ::after, don't think it's implemented anywhere though. https://drafts.csswg.org/css-ui/#propdef-user-select

Simon: I don't think we have properly addressed the shadow tree option. It's not script-visible, might solve selection. Is there a reason not to pursue that?

Luke/Eemeli: seems okay for the general localization effort to use shadow trees.

Brian: if we use custom elements and shadow trees, you can polyfill.. with a custom element.

Henri: Would script managed and browser managed shadow doms collide?

Luca: We don't need to explore if this is a problem. It's a problem. We should explore the shape and the solution.

Eemeli: I don't think we need to solve polyfilling.

Luca: I think everyone agrees the light tree is a no-go. So shadow vs CSS.

Keith: with shadow you lose out of media queries?

Luca: for CSS we mainly have to figure out selection (inclusive of ranges).

Jacob: When I first saw the <time> element, this is what I expected it to do (turns out, it actually does basically nothing, so this's an opportunity). I expect that is what many people will also expect. So if we go another route (CSS content), we're kind of saying "we know what you want, but go over here instead".

[Anne: that was the idea.]