I think the Popover API will be really transformative when CSS Anchor Positioning[1] arrives as well. Anchor positioning will let you position elements relative to others on the page. Combined with the Popover API it will let you implement things like custom tooltips and context menus in a declarative way and without any need for libraries like PopperJS [2]
This is the critical missing piece. Tried playing with and ship something with the new popover API last week, but missing positioning support in all browsers is really holding this back from more use-cases.
Looks like the last browser (FF) has already shipped anchor positioning in beta, so it won't be long!
Safari and Mobile Safari are common and are neither Firefox nor Chrome derivatives.
Uncommon and neither Firefox nor Chrome Derivatives: Netsurf, Dillo, Ladybird each have their own engines. A few browsers also use a Gecko fork called Goanna. (Pale Moon comes to mind first, but there are at least a couple others that use the same engine.) Then there's Konqueror. It's not common, but can either use old KHTML or WebKit (Safari's engine).
The title attribute is not accessible, so its use is generally discouraged as an accessible label because screen readers can't pick it up (it's fine to use if you combine it with aria-label). Also, you can only show text in a title attribute, so the Popover API would allow you to add rich content to a tooltip (for better or worse :))
They do pick up the "title" attribute sometimes and apply it as a label. But it's not really the same as being able to keyboard navigate to the browser-generated tooltip.
Not just screen readers. Basically no support for anyone not using a mouse to navigate. Also really annoying when people put link text in a title on links.
That's incorrect. There's nothing inherently inaccessible about the title attribute.
Voiceover, for example, reads the content of title attributes.
There are a bunch of reasons why title is pretty useless (the main one being it does nothing on every touch screen interface, where the concept of hover doesn't exist). But accessibility is not one of them.
> That's incorrect. There's nothing inherently inaccessible about the title attribute.
I think we might be splitting hairs here. There are accessibility concerns with the title attribute. MDN describes why the title attribute is problematic from an accessibility perspective [1] and provides a list of links with additional details. That MDN page also indicates that the title attribute is problematic for:
- People using touch-only devices
- People navigating with keyboards
- People navigating with assistive technology such as screen readers or magnifiers
- People experiencing fine motor control impairment
- People with cognitive concerns
That's a non-trivial amount of web users. So is it technically accessible? Yes. But if you want to deliver an accessible experience to everyone, and the title attribute is going to cause issues, I personally would define that as not being accessible.
The article I linked goes into the details, but basically a relative approach constrains your markup: The positioned thing must be a child of the relatively positioned anchor or a wrapper element, and you often cannot sensibly position it without using JS to check the location of the anchor. E.g. a popover menu for a button must check if the button is close to an edge of the viewport and position the menu element appropriately. Anchor positioning will do this automatically.
Also, if support for multiple anchors is included, then it opens up some very interesting capabilities to do things like draw arbitrary diagram connectors between elements: https://kizu.dev/anchor-positioning-experiments/
I've been eagerly awaiting anchor positioning, but using it for diagram connectors had not occurred to me yet! That would solve so many problems that I currently have (or plan) to use D3 for.
position: relative adds a fixed offset to the position the element would have been placed in normally, but position: anchor can be used to place an element near any arbitrary element, regardless of its place in the DOM hierarchy.