Re: [w3ctag/design-reviews] `<geolocation>` element (part of PEPC) (Issue #1140)

marcoscaceres left a comment (w3ctag/design-reviews#1140)

The TAG is generally positive about the direction that this work is taking.  Though we can see that this will be duplicative of the existing geolocation API, there are substantive improvements in this design that make it worth pursing.  We are optimistic that encouraging sites to use this new element will allow browsers to make the existing API less obtrusive as sites are able to use this to make more user-friendly experiences.

We encourage you to avoid generalizing from a sample set of one in the design.  We don't think that a `<permission>` element is the right strategy; as we are seeing with `<geolocation>`, the set of requirements for each element will depend greatly on what the element seeks to achieve.  Element(s) for user media element are likely to be very different.  The reliance on a set of generic capabilities without having had the experience of deploying multiple elements.  We advise seeking to generalize from multiple concrete instantiations -- ideally more than two -- rather than seek to build a generic core.  Ideally, these details are not visible to developers, except through having things like a consistent interface across controls.

The integration of intersection observers in the specification is something we think should not be mandatory.  We acknowledge that different browser implementation will want to have some amount of freedom in terms of how they present confirmation UX and how they manage rejection and refreshing of grants.  However, we think it is better to create space for variation in the design, rather than attempt to normalize this behavior.

As a new form element, it might be worth more complete integration with the norms for form element design.  That means having an `onchange` event handler, which might be an alias for the `onlocation` event.  There might also be a need for `:valid`/`:invalid` support, even if that is not presently hooked up to anything.  Describing the bounds of what is an isn't valid might need to be programmatic rather than declarative, at least in the near term.  Consider also what happens if a form is submitted prior to getting a location, including the case where the location is granted and pending.

Similarly, it may be worth considering if it's worth while exposing the permissions state via CSS. 

Though we might expect sites to grab location permission and then remove elements, consider adding pseudoclasses for when location is actively being delivered so that sites can provide feedback through styling.

We're going to mark this as validated and close this issue. If there is anything else you'd like from us, feel free to reopen this issue.

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

Message ID: <w3ctag/design-reviews/issues/1140/3496156012@github.com>