Thanks everyone. On Wed, Nov 20, 2024 at 7:57 AM Daniel Bratell <bratel...@gmail.com> wrote:
> LGTM3 > > I see Apple's concerns about this being not great for mobile devices with > current UI models, but the value to devices that have useful pointer > devices seems great enough to motivate shipping it anyway. > > /Daniel > On 2024-11-18 18:06, Mason Freed wrote: > > Thanks for the LGTMs. One comment... > > On Mon, Nov 18, 2024 at 8:30 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> LGTM2 - I agree that the use cases are compelling and see there is >> significant demand for popover=hint. >> On 11/18/24 2:49 AM, Domenic Denicola wrote: >> >> LGTM1. >> >> The only open spec issue I found related to this feature is >> https://github.com/openui/open-ui/issues/781 which I don't believe is >> blocking. >> >> Thanks for asking about that one. I just re-titled it, since it's > actually related to `interesttarget` (about the delays in showing and > hiding after "interest" is shown/lost). But thanks for making sure! > > Thanks, > Mason > > > >> I think it's unfortunate that Apple is opposed to this feature, but I >> agree that there is strong reasoning and web developer support for shipping >> it. In particular it seems multiple folks have attempted to address Apple's >> objections about hover patterns, pointing out that popover=hint can be used >> independently of hover patterns. I hope that the community produces nice >> polyfills for this additional attribute state so that web users and >> developers can get the benefits of this feature regardless. >> >> >> >> On Saturday, November 16, 2024 at 2:54:32 AM UTC+9 Mason Freed wrote: >> >>> On Fri, Nov 15, 2024 at 9:20 AM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> Specification https://github.com/whatwg/html/pull/9778 >>>> >>>> I see that WebKit is opposed to landing this PR. I don't fully >>>> understand the objection - there are other instances of different UX >>>> patterns between Desktop and Mobile that users seem to understand - e.g., >>>> pull to refresh vs ctrl/cmd-r - so thank you for asking for more >>>> specifics >>>> <https://github.com/whatwg/html/pull/9778#issuecomment-2430021512> >>>> some 3 weeks ago. >>>> >>>> 👍 >>> >>> >>>> TAG review >>>> >>>> Is it worth asking TAG for input here? Or have they already given it? >>>> >>> >>> So the original popover API included this feature (`popover=hint`). That >>> original API had not just one, but three TAG reviews (1 >>> <https://github.com/w3ctag/design-reviews/issues/599>, 2 >>> <https://github.com/w3ctag/design-reviews/issues/680>, 3 >>> <https://github.com/w3ctag/design-reviews/issues/743>), and 2.5 of them >>> included the `popover=hint` behavior. I was hoping I reached my TAG quota >>> and could avoid another review. LMK if that makes sense. >>> >>> >>>> >>>> >>>> *Gecko*: Positive ( >>>> https://github.com/mozilla/standards-positions/issues/965) >>>> >>>> (non-blocking note here: I see there was a patch submitted 5 months >>>> ago, but there hasn't been any visible activity around it. I wonder why.) >>>> >>> >>> I'm guessing (without evidence) that this is because of the >>> Webkit-induced uncertainty around this feature. I'm hoping this I2S >>> alleviates some of that uncertainty. I think this is a good feature, and >>> Mozilla <https://github.com/mozilla/standards-positions/issues/965> and >>> developers >>> <https://github.com/openui/open-ui/issues/1114#issuecomment-2463048194> >>> both seem to agree. >>> >>> Thanks, >>> Mason >>> >>> >>>> *WebKit*: Negative ( >>>> https://github.com/WebKit/standards-positions/issues/305) Apple is >>>> negative, because they see this feature as inextricably tied to the >>>> `interesttarget` feature. >>>> >>>> *Web developers*: Positive ( >>>> https://github.com/openui/open-ui/issues/1114#issuecomment-2463048194) >>>> I specifically discussed the utility of this feature with the developer >>>> community, at several OpenUI meetings. The response was overwhelmingly >>>> supportive of this feature in isolation, even without `interesttarget`. >>>> Developers think that it removes the burden of implementing all of the >>>> popover light dismiss behaviors themselves on `popover=manual` popovers, >>>> which is the only way to implement hovercards/tooltips today using >>>> popovers, if they want to avoid bad interactions with `popover=auto` >>>> popovers. >>>> >>>> *Other signals*: >>>> >>>> WebView application risks >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> >>>> >>>> Debuggability >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)? Yes >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? Yes >>>> >>>> https://wpt.fyi/results/html/semantics/popovers >>>> >>>> >>>> Flag name on about://flags Experimental Web Platform Features >>>> >>>> Finch feature name HTMLPopoverHint >>>> >>>> Requires code in //chrome? False >>>> >>>> Tracking bug https://crbug.com/1416284 >>>> >>>> Estimated milestones >>>> Shipping on desktop 133 >>>> Shipping on Android 133 >>>> Shipping on WebView 133 >>>> >>>> Anticipated spec changes >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5073251081912320?gate=5177431016603648 >>>> >>>> Links to previous Intent discussions Intent to Prototype: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgd1JZuBkpHud7QsJchZVOr0mDMZxWch1enf%3DuyU98QCw%40mail.gmail.com >>>> >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com/>. >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgzF-L9OSyr6sdarJHD-2UFPZ0D3Bvus53v-bXKxwRXyA%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgzF-L9OSyr6sdarJHD-2UFPZ0D3Bvus53v-bXKxwRXyA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDigYHVDQSEmv3rHKf4VN0qRwqF91gYfzE5qSwKX7PwmZg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDigYHVDQSEmv3rHKf4VN0qRwqF91gYfzE5qSwKX7PwmZg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjm5-ZbXP-8kVEHvHSgHXgru0ogvL1akLMSQwqeychdpA%40mail.gmail.com.