Testowanie origin nowego elementu <uprawnień> HTML

Thomas Steiner

Istnieje kilka ważnych metod, za pomocą których możesz prosić o zgodę na korzystanie z zaawansowanych funkcji, takich jak dostęp do lokalizacji w aplikacjach internetowych. Metody te wiążą się z wieloma wyzwaniami, dlatego zespół ds. uprawnień Chrome eksperymentuje z nową metodą deklaratywną: dedykowanym elementem HTML <permission>. Ten element jest w fazie testowania origin Chrome 126 i ostatecznie mamy nadzieję go ustandaryzować.

Imperatywne metody wysyłania próśb o uprawnienia

Gdy aplikacje internetowe potrzebują dostępu do zaawansowanych funkcji, muszą poprosić o zgodę. Jeśli na przykład Mapy Google wymagają podania lokalizacji użytkownika za pomocą interfejsu Geolocation API, przeglądarki poprosi o to użytkownika. Często mogą zapisać tę decyzję. Jest to dobrze zdefiniowane pojęcie w specyfikacji uprawnień.

Bezpośrednio pytać przy pierwszym użyciu a nie o to prosić z góry

Geolocation API to zaawansowany interfejs API oparty na niejawnym pytaniu przy pierwszym użyciu. Na przykład: gdy aplikacja wywołuje metodę navigator.geolocation.getCurrentPosition(), prośba o uprawnienia pojawia się automatycznie przy pierwszym wywołaniu. Inny przykład: navigator.mediaDevices.getUserMedia().

Inne interfejsy API, takie jak notification API lub Device Orientation i Motion API, zwykle pozwalają w sposób jednoznaczny poprosić o uprawnienia za pomocą metody statycznej, takiej jak Notification.requestPermission() lub DeviceMotionEvent.requestPermission().

Wyzwania związane z niezbędnymi metodami proszenia o zgodę

Spam związany z uprawnieniami

W przeszłości witryny mogły wywoływać metody takie jak navigator.mediaDevices.getUserMedia() lub Notification.requestPermission(), ale też navigator.geolocation.getCurrentPosition() natychmiast po ich wczytaniu. Prośba o uprawnienia pojawia się, zanim użytkownik wejdzie w interakcję z witryną. Czasami określa się to jako spam z prośbą o uprawnienia. Ma to wpływ na obie metody: prośba niejawnie o pierwsze użycie i wyraźna prośba z góry.

Łagodzenie działania przeglądarki i wymóg korzystania z gestów użytkownika

Spam związany z uprawnieniami sprawia, że dostawcy przeglądarek wymagali gestu użytkownika, takiego jak kliknięcie przycisku lub zdarzenie kliknięcia, zanim wyświetlili prośbę o uprawnienia. Problem z tym podejściem polega na tym, że bardzo trudno, jeśli nie jest, jest w stanie określić, czy dany gest użytkownika powinien powodować wyświetlenie prośby o zgodę. Być może użytkownik po prostu klikał z frustracją, bo ładował się zbyt długo albo kliknął przycisk Zlokalizuj mnie. Niektóre witryny bardzo dobrze nakłaniają użytkowników do klikania treści, aby aktywować prośbę.

Innym rozwiązaniem jest dodanie środków zaradczych związanych z nadużyciami, np. całkowite zablokowanie funkcji na początku lub wyświetlanie prośby o uprawnienia w niemodalny i mniej uciążliwy sposób.

Kontekst użycia uprawnień

Kolejnym problemem, zwłaszcza na dużych ekranach, jest to, jak często wyświetla się prośba o przyznanie uprawnień – nad linią śmierci, czyli poza obszarem okna przeglądarki, na który aplikacja może rysować. Nie wie, że użytkownicy pomijają prośbę u góry okna przeglądarki po kliknięciu przycisku u dołu. Ten problem nasila się często, gdy przeglądarki stosuje łagodzenie skutków spamu.

Nie można łatwo cofnąć tego działania

Co więcej, użytkownicy zbyt łatwo mogą wejść w ślepą uliczkę. Jeśli na przykład użytkownik zablokuje dostęp do funkcji, musi znać menu z informacjami o witrynie, w którym może zresetować uprawnienia lub ponownie włączyć zablokowane uprawnienia. Obie opcje w najgorszym przypadku wymagają pełnego ponownego załadowania strony, dopóki zaktualizowane ustawienie nie zacznie obowiązywać. Witryny nie dają użytkownikom możliwości łatwego skrótu do zmiany stanu uprawnień, dlatego muszą dokładnie wyjaśnić użytkownikom, jak zmienić ustawienia, jak pokazano u dołu poniższego zrzutu ekranu Map Google.

Jeśli uprawnienie jest kluczowe dla działania, na przykład dostęp aplikacji do rozmów wideo do mikrofonu, aplikacje takie jak Google Meet wyświetlają uciążliwe okna z instrukcjami, jak odblokować uprawnienie.

Element <permission> deklaratywny

Aby rozwiązać problemy opisane w tym poście, zespół ds. uprawnień Chrome rozpoczął testowanie origin nowego elementu HTML – <permission>. Na razie umożliwia on deweloperom deklaratywną prośbę o pozwolenie na korzystanie z podzbioru zaawansowanych funkcji dostępnych dla witryn. W najprostszej postaci użyjesz go w następujący sposób:

<permission type="camera" />

Wciąż toczy się trwałe negocjacje, czy pole <permission> powinno być elementem nieważnym. Pusty element to samozamykający się element w kodzie HTML, który nie może mieć żadnych węzłów podrzędnych. Oznacza to, że w języku HTML może nie mieć tagu końcowego.

Atrybut type

Atrybut type zawiera rozdzieloną spacjami listę uprawnień, których dotyczy prośba. W tym momencie dozwolone wartości to 'camera', 'microphone' i camera microphone (rozdzielone spacją). Ten element domyślnie renderuje się podobnie do przycisków ze stylem klienta użytkownika bez głębi.

Atrybut type-ext

W przypadku niektórych uprawnień, które umożliwiają stosowanie dodatkowych parametrów, atrybut type-ext akceptuje rozdzielone spacjami pary klucz-wartość, 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 na podstawie opcjonalnego atrybutu lang. Oznacza to, że deweloperzy nie muszą samodzielnie lokalizować elementu <permission>. Jeśli element <permission> wykracza poza etap testowania origin, dla każdego typu uprawnień może być obsługiwanych kilka ciągów lub ikon, aby zwiększyć elastyczność. Jeśli chcesz użyć elementu <permission> i potrzebujesz konkretnego ciągu lub ikony, skontaktuj się z nami.

Sposób działania

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

• Jeśli użytkownik nie wyraził wcześniej zgody na daną funkcję, może zezwolić na nią przy każdej wizycie lub tylko podczas bieżącej wizyty.

  

• Jeśli użytkownik wyraził zgodę na daną funkcję wcześniej, może ją nadal zezwalać lub przestać na to zezwalać.

  

• Jeśli użytkownik wcześniej nie zezwalał na daną funkcję, nadal nie może na to zezwalać lub tym razem może ją zezwolić.

  

Tekst elementu <permission> jest automatycznie aktualizowany na podstawie stanu. Jeśli na przykład przyznano uprawnienia do korzystania z danej funkcji, tekst zmieni się na „Dozwolona”. Jeśli użytkownik ma zacząć korzystać z tej funkcji, tekst zmieni się, żeby użytkownik mógł zacząć korzystać z funkcji. Aby zobaczyć 2 stany, porównaj wcześniejszy zrzut z podanym niżej.

Projektowanie w usłudze porównywania cen

Styl elementu <permission> jest ograniczony, aby użytkownicy mogli łatwo rozpoznać przycisk jako platformę zapewniającą dostęp do zaawansowanych funkcji. Jeśli ograniczenia stylu nie sprawdzają się w Twoim przypadku, chętnie dowiemy się, jak i dlaczego. Chociaż nie możemy spełnić wszystkich wymagań dotyczących stylu, chcemy odkryć bezpieczne sposoby na umożliwienie większej liczby stylizacji elementu <permission> po zakończeniu testowania origin. W tabeli poniżej znajdziesz szczegółowe informacje o niektórych właściwościach, do których mają zastosowanie ograniczenia lub specjalne reguły. W przypadku naruszenia którejś z reguł element <permission> zostanie wyłączony i nie będzie można go użyć. Wszelkie próby interakcji z nim spowodują wyjątki, które zostaną przechwycone przez JavaScript. Zawiera on więcej informacji o wykrytym naruszeniu zasad.

Możesz używać tych właściwości CSS w zwykły sposób:

• 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 opisanym wcześniej dla: outline-offset)
• 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

Poza tym można używać wszystkich logicznie równoważnych właściwości (np. inline-size jest odpowiednikiem funkcji width) zgodnie z tymi samymi regułami co ich odpowiedniki.

Pseudoklasy

Istnieją 2 specjalne pseudoklasy, które umożliwiają określanie stylu elementu <permission> w zależności od stanu:

• :granted: pseudoklasa :granted umożliwia stosowanie specjalnego stylu w przypadku przyznania uprawnień.
• :invalid: pseudoklasa :invalid umożliwia stosowanie specjalnego stylu, gdy element jest w nieprawidłowym stanie, np. gdy jest wyświetlany w elemencie iframe z innych domen.

permission {
  background-color: green;
}

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

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

Zdarzenia JavaScript

Elementu <permission> należy używać razem z interfejsem Permissions API. Istnieje kilka zdarzeń, które można nasłuchiwać:

• onpromptdismiss: to zdarzenie jest wywoływane, gdy użytkownik odrzuci prośbę o uprawnienia wywołaną przez element (np. po kliknięciu przycisku zamykania lub kliknięciu poza polem).

• onpromptaction: to zdarzenie jest wywoływane, gdy prośba o przyznanie uprawnień wywołana przez element nie została już zaakceptowana przez użytkownika, który wykonał w związku z promptem jakieś działanie. Nie musi to oznaczać, że stan uprawnień uległ zmianie. Użytkownik mógł wykonać działanie pozwalające utrzymać obecny stan (np. kontynuować przyznawanie uprawnienia).

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

Możesz zarejestrować detektory tych zdarzeń bezpośrednio w kodzie HTML (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />) lub użyć addEventListener() w elemencie <permission>, jak pokazano w poniższym 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 wyświetli go. Oznacza to, że jeśli w kodzie HTML występuje element <permission>, nic się nie dzieje, gdy przeglądarka go nie rozpozna. Nadal możesz chcieć wykrywać obsługę JavaScriptu, na przykład aby utworzyć prośbę o przyznanie uprawnień aktywowaną po kliknięciu zwykłego kliknięcia <button>.

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

Wersja próbna origin

Aby wypróbować element <permission> w swojej witrynie wśród rzeczywistych użytkowników, zarejestruj się w celu skorzystania z testowania origin. Instrukcje dotyczące przygotowania witryny do testowania origin znajdziesz w artykule Pierwsze kroki z testowaniem origin. Testowanie origin będzie się odbywać od wersji 126 do wersji 131 Chrome (19 lutego 2025 r.).

Pokaz

Zapoznaj się z prezentacją i zapoznaj się z kodem źródłowym w GitHubie. Oto zrzut ekranu z obsługą przeglądarki w przeglądarce.

Prześlij opinię

Chętnie dowiemy się, jak <permission> działa w Twoim przypadku użycia. Odpowiedz na jeden z problemów w repozytorium lub zgłoś nowy. Sygnały publiczne w repozytorium dla elementu <permission> będą informować nas i inne przeglądarki, że interesuje Cię ten temat.

Najczęstsze pytania

• Co jest lepsze niż zwykłe <button> sparowane z interfejsem Permissions API? Kliknięcie przycisku <button> to gest użytkownika, ale przeglądarki nie mogą sprawdzić, czy są powiązane z żądaniem prośby o pozwolenie. Jeśli użytkownik kliknął <permission>, przeglądarka może mieć pewność, że jest ono powiązane z prośbą o uprawnienia. Dzięki temu przeglądarka może obsługiwać procesy, które w innym przypadku byłyby znacznie bardziej ryzykowne. Dotyczy to na przykład łatwego cofania blokady uprawnień.
• Co zrobić, jeśli inne przeglądarki nie obsługują elementu <permission>? Elementu <permission> można używać jako ulepszenia progresywnego. W nieobsługiwanych przeglądarkach możesz stosować klasyczny przepływ uprawnień. Na przykład na podstawie kliknięcia zwykłego elementu <button>. Zespół ds. uprawnień pracuje też nad kodem polyfill. Oznacz repozytorium GitHub gwiazdką, aby otrzymać powiadomienie, gdy będzie gotowe.
• Czy ta kwestia była omawiana z innymi dostawcami przeglądarek? Element <permission> był aktywnie omówiony podczas sesji w podgrupach na konferencji W3C TPAC w 2023 r. Możesz przeczytać notatki z sesji publicznej. Zespół Chrome poprosił też o formalne stanowiska standardowe od obu dostawców – patrz sekcja Powiązane linki. Element <permission> jest tematem wielu dyskusji z innymi przeglądarkami i chcemy go ujednolicić.
• Czy ten element powinien być pusty? Wciąż toczy się trwałe negocjacje, czy pole <permission> powinno być elementem nieważnym. Jeśli chcesz podzielić się z nami opinią, daj nam znać o problemie.

Powiązane artykuły

• Wyjaśnienie
• Pozycja w zakresie standardów WebKit
• Stanowisko w standardzie Mozilla

Podziękowania

Ten dokument zweryfikowali Balázs Engedy, Thomas Nguyen, Penelope McLachlan, Marian Harbach, David Warren i Rachel Andrew.