Testowanie origin nowego elementu <uprawnień> HTML

Thomas Steiner

Istnieje kilka koniecznych metod proszenia o zezwolenie na korzystanie z zaawansowanych funkcji, takich jak dostęp do lokalizacji w aplikacjach internetowych. Te metody wiążą się z wieloma problemami, dlatego zespół ds. uprawnień w Chrome eksperymentuje z nową metodą deklaratywną: specjalnym elementem HTML <permission>. Ten element jest testowany w Chrome od wersji 126 i mamy nadzieję, że w przyszłości zostanie ustandaryzowany.

Metody imperatywne proszenia o uprawnienia

Gdy aplikacje internetowe potrzebują dostępu do zaawansowanych funkcji, muszą poprosić o zgodę. Na przykład, gdy Mapy Google wymagają lokalizacji użytkownika za pomocą interfejsu Geolocation API, przeglądarki wyświetlają użytkownikowi pytanie, często z opcją zapisania decyzji. Jest to dobrze zdefiniowane pojęcie w specyfikacji uprawnień.

Dorozumiane pytanie przy pierwszym użyciu a wyraźna prośba z wyprzedzeniem

Interfejs Geolocation API to zaawansowany interfejs API, który opiera się na metodzie niejawnego pytania przy pierwszym użyciu. Na przykład, gdy aplikacja wywoła metodę navigator.geolocation.getCurrentPosition() przy pierwszym wywołaniu automatycznie pojawi się prośba o uprawnienia. Inny przykład to navigator.mediaDevices.getUserMedia().

Inne interfejsy API, takie jak Notification API czy Device Orientation and Motion API, zwykle mają wyraźny sposób na żądanie uprawnień za pomocą metody statycznej, np. Notification.requestPermission() lub DeviceMotionEvent.requestPermission().

Problemy z metodami imperatywnymi proszenia o uprawnienia

Spam związany z prośbami o uprawnienia

W przeszłości witryny mogły wywoływać metody takie jak navigator.mediaDevices.getUserMedia() lub Notification.requestPermission(), a także navigator.geolocation.getCurrentPosition() natychmiast po załadowaniu witryny. Zanim użytkownik wejdzie w interakcję z witryną, pojawi się prośba o przyznanie uprawnień. Czasami jest to określane jako spam związany z prośbą o zgodę. Dotyczy to obu podejść: zarówno pośredniego pytania przy pierwszym użyciu, jak i bezpośredniej prośby o zgodę z wyprzedzeniem.

Ograniczenia przeglądarki i wymagania dotyczące gestów użytkownika

Spam związany z prośbami o uprawnienia spowodował, że dostawcy przeglądarek zaczęli wymagać od użytkowników wykonania gestu, takiego jak kliknięcie przycisku lub naciśnięcie klawisza, zanim wyświetlą prośbę o uprawnienia. Problem z tym podejściem polega na tym, że przeglądarce bardzo trudno jest określić, czy dany gest użytkownika powinien spowodować wyświetlenie prośby o uprawnienia. Może użytkownik klikał stronę w dowolnym miejscu z frustracji, ponieważ strona zbyt długo się wczytywała, a może rzeczywiście klikał przycisk Zlokalizuj mnie. Niektóre witryny nauczyły się też bardzo dobrze nakłaniać użytkowników do klikania treści, aby wywołać prośbę.

Innym sposobem jest dodanie środków ograniczających nadużycia promptów, takich jak całkowite blokowanie funkcji od samego początku lub wyświetlanie promptu z prośbą o uprawnienia w sposób nieblokujący i mniej natrętny.

Kontekstowe uprawnienia

Kolejnym wyzwaniem, zwłaszcza na dużych ekranach, jest sposób wyświetlania prośby o uprawnienia: nad linią śmierci, czyli poza obszarem okna przeglądarki, w którym aplikacja może rysować. Zdarza się, że użytkownicy nie zauważają komunikatu u góry okna przeglądarki, gdy klikną przycisk u dołu okna. Ten problem często nasila się, gdy w przeglądarce są włączone mechanizmy ograniczające spam.

Nie można łatwo cofnąć czynności

Wreszcie użytkownicy mogą łatwo trafić w ślepy zaułek. Na przykład po zablokowaniu dostępu do funkcji użytkownik musi wiedzieć, że w menu informacji o witrynie może zresetować uprawnienia lub ponownie włączyć zablokowane uprawnienia. W najgorszym przypadku obie opcje wymagają pełnego ponownego załadowania strony, zanim zaktualizowane ustawienie zacznie obowiązywać. Witryny nie mają możliwości zapewnienia użytkownikom łatwego skrótu do zmiany stanu istniejącego uprawnienia i muszą dokładnie wyjaśniać użytkownikom, jak zmienić ustawienia, co widać na dole zrzutu ekranu z Map Google poniżej.

Jeśli uprawnienie jest kluczowe dla działania aplikacji, np. dostęp do mikrofonu w przypadku aplikacji do rozmów wideo, takich jak Google Meet, wyświetlają one natrętne okna, które informują użytkownika, jak odblokować uprawnienie.

Deklaratywny element <permission>

Aby rozwiązać problemy opisane w tym poście, zespół ds. uprawnień w Chrome uruchomił test pochodzenia nowego elementu HTML – <permission>. Ten element umożliwia deweloperom deklaratywne proszenie o zezwolenie na korzystanie z podzbioru zaawansowanych funkcji dostępnych w witrynach. W najprostszej postaci używasz go tak jak w tym przykładzie:

<permission type="camera" />

To, czy <permission> powinien być elementem pustym, jest nadal przedmiotem dyskusji. Element pusty to element samodzielnie zamykający się w HTML, który nie może mieć żadnych węzłów podrzędnych, co w HTML oznacza, że nie może mieć tagu zamykającego.

Atrybut type

Atrybut type zawiera listę uprawnień, o które prosisz, rozdzielonych spacjami. W momencie pisania tego artykułu dozwolone wartości to 'camera', 'microphone' i camera microphone (rozdzielone spacją). Ten element domyślnie renderuje się podobnie do przycisków z podstawowym stylem klienta użytkownika.

Atrybut type-ext

W przypadku niektórych uprawnień, które dopuszczają dodatkowe parametry, atrybut type-ext akceptuje pary klucz-wartość rozdzielone spacjami, np.precise:true w przypadku uprawnień do geolokalizacji.

Atrybut lang

Tekst przycisku jest dostarczany przez przeglądarkę i ma być spójny, więc nie można go bezpośrednio dostosować. Przeglądarka zmienia język tekstu na podstawie odziedziczonego języka dokumentu lub łańcucha elementów nadrzędnych albo opcjonalnego atrybutu lang. Oznacza to, że deweloperzy nie muszą sami lokalizować elementu <permission>. Jeśli element <permission> przejdzie etap testowania w ramach wersji próbnej, w przypadku każdego typu uprawnień może być obsługiwanych kilka ciągów tekstowych lub ikon, co zwiększy elastyczność. Jeśli chcesz używać elementu <permission> i potrzebujesz konkretnego ciągu znaków lub ikony, skontaktuj się z nami.

Zachowanie

Gdy użytkownik wejdzie w interakcję z elementem <permission>, może przechodzić przez różne etapy:

• Jeśli użytkownik wcześniej nie zezwolił na korzystanie z danej funkcji, może zezwolić na to przy każdej wizycie lub tylko podczas bieżącej wizyty.

  

• Jeśli wcześniej zezwolili na korzystanie z tej funkcji, mogą nadal to robić lub zrezygnować z niej.

  

• Jeśli wcześniej nie zezwolili na korzystanie z danej funkcji, mogą nadal nie zezwalać na nią lub tym razem zezwolić.

  

Tekst elementu <permission> jest automatycznie aktualizowany na podstawie stanu. Jeśli na przykład przyznano uprawnienia do korzystania z funkcji, tekst zmieni się na informację, że funkcja jest dozwolona. Jeśli najpierw trzeba przyznać uprawnienia, tekst zmieni się, aby zachęcić użytkownika do korzystania z funkcji. Porównaj wcześniejszy zrzut ekranu z poniższym, aby zobaczyć oba stany.

Projekt CSS

Aby użytkownicy mogli łatwo rozpoznać przycisk jako miejsce dostępu do zaawansowanych funkcji, styl elementu <permission> jest ograniczony. Jeśli ograniczenia dotyczące stylizacji nie działają w Twoim przypadku, daj nam znać, jak i dlaczego. Nie wszystkie potrzeby związane ze stylem mogą zostać zaspokojone, ale mamy nadzieję, że po zakończeniu okresu próbnego znajdziemy bezpieczne sposoby na umożliwienie większej liczby stylów elementu <permission>. W tabeli poniżej znajdziesz szczegółowe informacje o właściwościach, które podlegają ograniczeniom lub specjalnym regułom. Jeśli któreś z tych reguł zostaną naruszone, element <permission> zostanie wyłączony i nie będzie można z nim wchodzić w interakcję. Wszelkie próby interakcji z nim spowodują wyjątki, które można przechwycić za pomocą JavaScriptu. Komunikat o błędzie będzie zawierać więcej informacji o wykrytym naruszeniu.

Możesz używać tych właściwości CSS:

• font-kerning
• font-optical-sizing
• font-stretch
• font-synthesis-weight
• font-synthesis-style
• font-synthesis-small-caps
• font-feature-settings
• forced-color-adjust
• text-rendering
• align-self
• anchor-name aspect-ratio
• border (i wszystkie usługi border-*)
• clear
• color-scheme
• contain
• contain-intrinsic-width
• contain-intrinsic-height
• container-name
• container-type
• counter-*
• flex-*
• float
• height
• isolation
• justify-self
• left
• order
• orphans
• outline-* (z wyjątkiem outline-offset, o którym wspomnieliśmy wcześniej)
• overflow-anchor
• overscroll-behavior-*
• page
• position
• position-anchor
• content-visibility
• right
• scroll-margin-*
• scroll-padding-*
• text-spacing-trim
• top
• visibility
• x
• y
• ruby-position
• user-select
• width
• will-change
• z-index

Można też używać wszystkich właściwości logicznie równoważnych (np. inline-size jest równoważne z width), zgodnie z tymi samymi regułami co ich odpowiedniki.

Pseudo-classes

Istnieją 2 specjalne pseudoklasy, które umożliwiają stylowanie elementu <permission> na podstawie jego stanu:

• :granted: Pseudoklasa :granted umożliwia specjalne stylowanie, gdy przyznano uprawnienia.
• :invalid: pseudoklasa :invalid umożliwia specjalne stylowanie, gdy element jest w nieprawidłowym stanie, np. gdy jest wyświetlany w elemencie iframe z innej domeny.

permission {
  background-color: green;
}

permission:granted {
  background-color: light-green;
}

/* Not supported during the origin trial. */
permission:invalid {
  background-color: gray;
}

Zdarzenia JavaScript

Element <permission> jest przeznaczony do używania z interfejsem Permissions API. Możesz nasłuchiwać wielu zdarzeń:

• onpromptdismiss: to zdarzenie jest wywoływane, gdy użytkownik zamknie prośbę o uprawnienia wywołaną przez element (np. klikając przycisk zamykania lub poza prośbą).

• onpromptaction: to zdarzenie jest wywoływane, gdy użytkownik podejmie działanie w odpowiedzi na prośbę o uprawnienia wywołaną przez element. Nie musi to oznaczać, że stan uprawnień się zmienił. Użytkownik mógł wykonać działanie, które utrzymuje status quo (np. nadal zezwalać na uprawnienia).

• onvalidationstatuschange: to zdarzenie jest wywoływane, gdy element zmienia stan z "valid" na "invalid". Element jest uznawany za "valid", gdy przeglądarka ufa integralności sygnału, jeśli użytkownik go kliknie, a w przeciwnym razie za "invalid", np. gdy element jest częściowo zasłonięty przez inne treści HTML.

Rejestrować odbiorniki zdarzeń możesz bezpośrednio w kodzie HTML (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />) lub za pomocą atrybutu addEventListener() w elemencie <permission>, jak pokazano w tym przykładzie:

<permission type="camera" />
<script>
  const permission = document.querySelector('permission');
  permission.addEventListener('promptdismiss', showCameraWarning);

  function showCameraWarning() {
    // Show warning that the app isn't fully usable
    // unless the camera permission is granted.
  }

  const permissionStatus = await navigator.permissions.query({name: "camera"});
  
  permissionStatus.addEventListener('change', () => {
    // Run the check when the status changes.
    if (permissionStatus.state === "granted") {
      useCamera();
    }
  });

  // Run the initial check.
  if (permissionStatus.state === "granted") {
    useCamera();
  }
</script>

Wykrywanie cech

Jeśli przeglądarka nie obsługuje elementu HTML, nie będzie go wyświetlać. Oznacza to, że jeśli w kodzie HTML masz element <permission>, nic się nie stanie, jeśli przeglądarka go nie rozpozna. Możesz nadal wykrywać obsługę za pomocą JavaScriptu, np. aby utworzyć prośbę o uprawnienia wywoływaną kliknięciem zwykłego elementu <button>.

if ('HTMLPermissionElement' in window) {
  // The `<permission>` element is supported.
}

Wersja próbna origin

Aby wypróbować element <permission> w witrynie z udziałem prawdziwych użytkowników, zarejestruj się w programie testów źródła. Więcej informacji o przygotowaniu witryny do korzystania z testów pochodzenia znajdziesz w artykule Wprowadzenie do testów pochodzenia. Testowanie origin będzie prowadzone od Chrome 126 do Chrome 131 (od 19 lutego 2025 r.).

Prezentacja

Zapoznaj się z wersją demonstracyjną i sprawdź kod źródłowy na GitHubie. Oto zrzut ekranu przedstawiający działanie tej funkcji w obsługiwanej przeglądarce.

Prześlij opinię

Chętnie dowiemy się, jak <permission> sprawdza się w Twoim przypadku użycia. Możesz odpowiedzieć na jeden z problemów w repozytorium lub zgłosić nowy. Sygnały publiczne w repozytorium elementu <permission> poinformują nas i inne przeglądarki o Twoim zainteresowaniu tym elementem.

Najczęstsze pytania

• Dlaczego jest to lepsze rozwiązanie niż zwykły <button> w połączeniu z interfejsem Permissions API? Kliknięcie <button> to gest użytkownika, ale przeglądarki nie mają możliwości sprawdzenia, czy jest on powiązany z prośbą o uprawnienia. Jeśli użytkownik kliknie <permission>, przeglądarka może mieć pewność, że kliknięcie jest związane z prośbą o uprawnienia. Dzięki temu przeglądarka może ułatwiać przepływy, które w innych okolicznościach byłyby znacznie bardziej ryzykowne. Możesz na przykład umożliwić użytkownikowi łatwe cofnięcie blokady uprawnień.
• Co się stanie, jeśli inne przeglądarki nie obsługują elementu <permission>? Element <permission> może być używany jako ulepszenie progresywne. W przeglądarkach, które nie obsługują tej funkcji, można użyć klasycznego procesu przyznawania uprawnień. Na przykład na podstawie kliknięcia zwykłego przycisku <button>. Zespół ds. uprawnień pracuje też nad polyfillem. Oznacz repozytorium GitHub gwiazdką, aby otrzymywać powiadomienia, gdy będzie gotowe.
• Czy ten problem był omawiany z innymi dostawcami przeglądarek? Element <permission> był aktywnie omawiany podczas konferencji W3C TPAC w 2023 r. w ramach sesji tematycznej. Możesz przeczytać notatki z sesji publicznej. Zespół Chrome poprosił też obu dostawców o formalne stanowiska dotyczące standardów. Zobacz sekcję Powiązane linki. Element <permission> jest przedmiotem dyskusji z innymi przeglądarkami i mamy nadzieję, że uda nam się go ujednolicić.
• Czy to powinien być element pusty? Trwa aktywna dyskusja, czy <permission> powinien być elementem pustym. Jeśli masz jakieś uwagi, dodaj je do zgłoszenia.

Powiązane artykuły

• Wyjaśnienie
• Stanowisko WebKit w sprawie standardów
• Stanowisko Mozilli w sprawie standardów

Podziękowania

Ten dokument został sprawdzony przez Balázsa Engedyego, Thomasa Nguyena, Penelope McLachlan, Mariana Harbacha, Davida Warrena i Rachel Andrew.