Move popover=hint to partial given new spec

[jakearchibald]

Summary

A large change was made to popover=hint to fix weird behaviours, so the current implementations don't match the spec.

• Original issue
• Spec PR

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[keithamus]

This LGTM, FWIW.

[mfreed7]

I've shipped the new behaviors in Chromium as of version 150:

https://chromestatus.com/feature/6282804208992256

I'm not sure how to recommend we capture that here.

[jakearchibald]

@mfreed7 does that include the bug where clicking on a hint loses it's association with it's parent auto?

[caugner]

Rather than marking the pre-existing implementation as partial, what we do in cases like this is to add a behavioral subfeature (@ddbeck to correct me if I'm wrong here) that describes the spec change.

The description of that subfeature could mention the most important changes, and link to the spec PR for further details.

As for the spec_url, it will probably be hard to pin-point a specific text fragment, since the changes are spread, so we would just duplicate the spec_url of the parent feature (css.global_attributes.hint).

[jakearchibald]

In this case, the old behaviour was buggy and pretty hard to use or even explain. So it's not really like "we changed the design", and more "it was full of bugs and we fixed it".

Yes, in this case, the bugs were in the spec & the tests, but from a developer's point of view, the behaviour of the feature was buggy.

I don't mind doing it the way you say, but I wanted to make it clear that this situation is different to other re-designs of behaviour.

[ddbeck]

I don't think we should merge this as written, nor should we create a behavioral subfeature. Instead, I think we wait until there's an actual difference between two engines and the specification. Only then could we mark the current implementations as partial.

Adding a behavioral subfeature here is… challenging. Some of this might just be the complexity of popover hint itself, but I don't really see a handle for creating a subfeature. Subfeatures tend to mark a difference in kind (e.g., a new return type), a restriction (i.e., a thing you could do before which is now forbidden or a noop), or a new capability. Reading the Chrome Status entry, I'm not seeing a lot that fits neatly into those buckets (except maybe something like "safely nest an auto popover inside a hint popover") and also doesn't invite making several subfeatures.

But going directly to a partial now is confusing and weird. In BCD, our typical stance is to privilege implementations over specifications, when the implementations are compatible (i.e., if three engines all do the same thing, but that same thing is slightly divergent from the spec, then we treat the spec as the faulty one). AFAICT, in today's Firefox and Chrome, you get compatible behavior with popover="hint", so it would be unusual to mark the two compatible implementers as partially implemented.

So when Chrome 150 reaches beta, then I'd expect something like this:

• Chrome
  • Added 150, no partial, no note.
  • Added 133, partial with the proposed note.
• Firefox
  • Partial with the proposed note.

Chrome 150 is a little early to receive this treatment today—we don't typically trust that things that aren't even in a beta to ship in their predicted version number. It probably needs to wait a couple of weeks, unless you're absolutely certain it'll make it to stable without further changes.

[jakearchibald]

AFAICT, in today's Firefox and Chrome, you get compatible behavior with popover="hint",

That is true. It's just that the behaviour is mostly inexplicable.

I think it's misleading to developers to give these implementations a ✅, but I don't feel strongly enough to push for it further. I can wait until it hits beta.