commented: Note: I’m assuming some Tooltip component written in your favorite framework, e.g. React, Svelte, Vue, etc. There’s also the bleeding-edge popover="hint" and Interest Invokers API, which would give us a succinct way to do this in native HTML/CSS. AAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!1 <span title="tootltip">some stuff</span> my life commented: I didn't mention title because 1) it has serious accessibility issues and 2) it's kind of ugly. But yes it works okay in a pinch. commented: This is one of several confusing accessibility sections on MDN. title is literally an accessibility feature. Screen readers do read it. Yes you can't see it on mobile because.... It's a tooltip? Obviously don't put things that should be visible without hover in it. And ugly? It uses the OS tooltips. Maybe the OS should be less ugly? commented: AIUI screen reader support is patchy at best. And yes touchscreen users and keyboard users cannot use it. I would love for title to be more broadly usable, but sadly we don't seem to live in that world. commented: The reason touchscreen and keyboard users can’t see tooltips is because tooltips are bad UX for touchscreen users. Don’t write your own bad UX to undo that. If you want a tooltip everyone can use, you don’t want a tooltip, you want some other affordance. commented: It's so annoying that implementations screw up accessibility of simple features, so then the platform has to add more complex features to compensate, and then every website has to individually reimplement the behavior that the browser should have had all along. commented: The biggest issues of title are that they're tooltips... amusingly I wrote a blog post about pretty much just this in March of this year too: https://dpldocs.info/this-week-in-arsd/Blog.Posted_2025_03_03.html#tip-of-the-month I rant about tooltips in the context of using them for time! But yeah, if you're doing <time> element specifically, the attribute does feel redundant, especially if you do what my blog said and just put the text up there (the example I used there was " just show "2025-02-27 (Yesterday)". ") but that's ok if it is a bit redundant, I still say html is a kind of api so having formatted data is nice and like I said in my other comment too, you can use it in some progressive enhancement javascript or user css as well. Even if the browser doesn't do anything, you can use it yourself sometimes. commented: title must be only a plain string. The Popover API lets you use HTML inside the tooltip. Also, title does not work on focus. But for time both are irrelevant. A UA should just parse the datetime attribute and produce whatever the user expects. commented: Do you really have to yell? A tooltip is not the same thing as a popover. And that's kinda not what the article is about. commented: I think the frustration being expressed - one which I share - is that front-end developers seemingly do not care to let the user-agent do what it's supposed to do and instead implement complicated site-specific workarounds and functionality which break all too often and slow down the website. And that's kinda not what the article is about. The article is about having the browser do more with the semantic information given to it via the time tag. Makes it even more frustrating to be honest. commented: Some of the credit for this also goes to the subset of designers and product owners who insist that, say, a web app's drop-down menus need to be pixel-perfect implementations of an immutable, word-of-God Figma mockup; if the browser's built-in controls can't get it quite right, then obviously the only possible remaining option is to implement a custom drop-down menu, accessibility and maintainability be damned. commented: One cute thing you can do is make a css rule to display attributes as content too. For example, you could do time::after { content: attr(datetime); } and then it'll show it next to it. But you'd probably want to format it differently, a little script on load could let the browser localize it, like set the title attribute to element.setAttribute("title", new Date(element.getAttribute("datetime").toString();). since the Date toString localizes by default for the user, and then title automatically does a hover tooltip. of course yeah would be nice if the browsers did a bit more by default too... commented: Browsers should actually use the <time> element for something. There, fixed that for you. commented: I think I heard Mozilla's Eemeli Aro talk about making <time> into an actual semantic time element this summer at Web Engines Hackfest. commented: On my blog I have a script which finds all time elements and replaces the content with a human friendly representation. The title attribute is set to a date formatted with the user's locale. The content of close times (future or past) is a (live updating!) relative time (not localized unfortunately). Other times just display a date formatted in the user's locale. Which is quite nice. But I agree that it really feels like something that should be built in. I told the browser what the time is, it should present it to the user in their preferred format (fully localized, user preference for using relative times, ...). commented: I have a similar feature on a project of mine where the server sends UTC time and a client side library just converts it to the local time zone. I've been meaning to set it to relative time for recent events though and also publish the code for others. I couldn't find a tool that already did this and I'm sure you're in the same boat. Maybe we should collaborate on an OSS library? commented: Before the time element does anything, it should probably mean something. Right now it is basically just a type hint. But what does the time mean? On its own, there is no semantic meaning behind it like published date / edit date / etc. commented: microformats2 offers dt-published / dt-updated / etc. here. commented: Schema.org itself supports using the itemprop attribute with the time element commented: Yes. I screamed when the author said “not even HTML”. HTML can apply ontologies from ANYWHERE (wikidata.org had a lot of them, and so do other WikiBase-powered projects) just fine with the item and itemprop attributes. commented: On my blog, I use time tags like this to show the publication time (yes I cheat on the dates): <time datetime="2020-11-11T22:30:00+00:00">2020-11-11 22:30:00 UTC</time> Then I use JavaScript to transform it to: <time datetime="2020-11-11T22:30:00+00:00" title="2020-11-11 22:30:00 UTC">2020-11-11 23:30:00 CET</time> My timezone handling is far from perfect but it's a start. .