Re: [w3ctag/design-reviews] Page-Embedded Permission Controls (Issue #1079)

lolaodelola left a comment (w3ctag/design-reviews#1079)

Hi @andypaicu,

Thanks for this submission, this looks to be a promising area to investigate. It seems like you are in active discussion with Mozilla and WebKit about the details, which is good.

The TAG has two pieces of design feedback, both of which we think are fairly fundamental.

Our view is that mode-switching elements are not a good fit for HTML.  In retrospect, `<input type=foo>` probably not the choice we would make today, given experience and hindsight.  These should each have been separate elements (mostly).  The types of API are just too diverse to justify having a single element that tries to address all of the different use cases.  (There are some reasons why fallback to `<input type=text>` or other types might be appealing, but on balance it would have been better to have `<text>`, `<checkbox>`, `<radiobutton>`, etc...).

All of the capabilities that we're talking about here are existing capabilities with existing APIs.  That means that these new controls will be *new* and *redundant* ways of activating those capabilities.  That means that these need to deliver concrete improvements to justify the additional complexity burden on both sites and browser implementers needs.  It's possible that only some of the permissions will derive enough benefit from a control to make it worth defining one, in the same way that the Chrome experiment has prioritized camera, mic, and geolocation.

We also encourage you to think about the [WebKit feedback](https://github.com/WebKit/standards-positions/issues/270#issuecomment-2046572759), which also mentions this latter point.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1079#issuecomment-2990795640
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1079/2990795640@github.com>