Testowanie origin nowego elementu <uprawnień> HTML

Thomas Steiner

Istnieje kilka niezbędnych metod na proszenie o dostęp do zaawansowanych funkcji, takich jak dostęp do lokalizacji w aplikacjach internetowych. Te metody wiążą się z wielu wyzwaniami, dlatego zespół ds. uprawnień w Chrome eksperymentuje z nową deklaratywną metodą: dedykowanym elementem HTML <permission>. Ten element jest testowany w Chrome 126 i mamy nadzieję, że zostanie wkrótce zaimplementowany w innych wersjach.

Imperatywne metody żądania uprawnień

Gdy aplikacje internetowe potrzebują dostępu do zaawansowanych funkcji, muszą poprosić o dostęp. Gdy na przykład Mapy Google wymagają lokalizacji użytkownika za pomocą interfejsu Geolocation API, przeglądarki wyświetlają użytkownikowi odpowiedni komunikat, często z opcją zapisania tej decyzji. Jest to dobrze zdefiniowany termin w specyfikacji Uprawnienia.

Uzyskiwanie domyślnej zgody podczas pierwszego użycia lub wyraźne proszenie o zgodę z wyprzedzeniem

Interfejs Geolocation API jest potężnym interfejsem API, który korzysta z metody domyślnego pytania o pozwolenie przy pierwszym użyciu. Gdy na przykład aplikacja wywoła metodę navigator.geolocation.getCurrentPosition(), prośba o uprawnienia automatycznie pojawi się po pierwszym wywołaniu. Innym przykładem jest: navigator.mediaDevices.getUserMedia().

Inne interfejsy API, takie jak Notification API czy Device Orientation and Motion API, mają zwykle wyraźny sposób na prośbę o zgodę za pomocą metody statycznej, takiej jak Notification.requestPermission() lub DeviceMotionEvent.requestPermission().

Problemy z imperatywnymi metodami pytania o uprawnienia

Spam z uprawnieniami

W przeszłości witryny mogły wywoływać metody takie jak navigator.mediaDevices.getUserMedia() lub Notification.requestPermission(), ale także navigator.geolocation.getCurrentPosition() natychmiast po załadowaniu witryny. Zanim użytkownik wejdzie w interakcję z witryną, pojawi się prośba o udzielenie uprawnień. Czasami określa się to jako spam z prośbami o uprawnienia i dotyczy obu metod: pośredniego pytania o uprawnienia przy pierwszym użyciu oraz wyraźnego żądania udzielenia uprawnień z góry.

Środki zapobiegawcze w przeglądarce i wymagania dotyczące gestów użytkownika

Spam z prośbami o udzielenie uprawnień sprawił, że dostawcy przeglądarek wymagają od użytkownika wykonania jakiegoś działania, np. kliknięcia przycisku lub naciśnięcia klawisza, zanim wyświetlą prośbę o udzielenie uprawnień. Problem z tym podejściem polega na tym, że przeglądarka ma bardzo trudne zadanie, a często wręcz niemożliwe, aby ustalić, czy dane działanie użytkownika powinno skutkować wyświetleniem prośby o uprawnienia. Być może użytkownik po prostu klikał gdziekolwiek na stronie, ponieważ wczytywanie trwało zbyt długo, albo rzeczywiście kliknął przycisk Znajdź mnie. Niektóre witryny bardzo dobrze oszukują użytkowników, aby ci klikali treści, które uruchamiają prompt.

Innym sposobem jest dodanie działań ograniczających ryzyko związane z nadużyciami związanych z promptami, np. całkowite zablokowanie funkcji lub wyświetlanie prośby o uprawnienia w sposób mniej inwazyjny.

Udzielanie uprawnień w kontekście

Kolejnym problemem, zwłaszcza na dużych ekranach, jest sposób wyświetlania prośby o dostęp: powyżej linii śmierci, czyli poza obszarem okna przeglądarki, na którym aplikacja może rysować. Nie jest niczym niezwykłym, że użytkownicy nie zauważają prompta u góry okna przeglądarki, gdy klikną przycisk u dołu okna. Ten problem często nasila się, gdy w przeglądarce są aktywne środki zapobiegające spamowi.

Nie ma możliwości łatwego cofnięcia

W końcu użytkownicy zbyt łatwo mogą trafić na ślepy zaułek. Gdy użytkownik zablokuje dostęp do funkcji, musi wiedzieć, że w menu Informacje o witrynie może zresetować uprawnienia lub ponownie włączyć zablokowane uprawnienia. W najgorszym przypadku obie opcje wymagają pełnego ponownego załadowania strony, aby zaktualizowane ustawienie zaczęło obowiązywać. Witryny nie mogą udostępniać użytkownikom łatwego skrótu umożliwiającego zmianę stanu istniejących uprawnień. Trzeba im dokładnie wyjaśnić, jak zmienić ustawienia, jak pokazano na poniższym zrzucie ekranu z Google Maps.

Jeśli uprawnienie jest kluczowe dla działania aplikacji, na przykład dostęp do mikrofonu w przypadku aplikacji do rozmów wideo, aplikacje takie jak Google Meet wyświetlają natrętne dialogi, które instruują użytkownika, jak odblokować uprawnienie.

Deklaracyjny element <permission>

Aby rozwiązać problemy opisane w tym poście, zespół ds. uprawnień w Chrome rozpoczął testowanie nowego elementu HTML <permission>. Ten element pozwala deweloperom deklaratywnie prosić o pozwolenie na korzystanie z pewnych funkcji, które są obecnie dostępne dla witryn. W najprostszej postaci używasz go w taki sposób:

<permission type="camera" />

Nadal trwają dyskusje na temat tego, czy element <permission> powinien być elementem pustym. Element pusty to element HTML, który zamyka się sam i nie może mieć żadnych węzłów podrzędnych, co w HTML oznacza, że nie może mieć znacznika końcowego.

Atrybut type

Atrybut type zawiera oddzieloną spacjami listę uprawnień, których żądasz. W momencie pisania tego tekstu dozwolone wartości to 'camera', 'microphone' i camera microphone (oddzielone spacjami). Ten element domyślnie renderuje się podobnie jak przyciski z podstawowym stylem klienta użytkownika.

Atrybut type-ext

W przypadku niektórych uprawnień, które umożliwiają użycie dodatkowych parametrów, atrybut type-ext akceptuje pary klucz-wartość rozdzielone spacjami, np. precise:true w przypadku uprawnienia do korzystania z lokalizacji.

Atrybut lang

Tekst przycisku jest dostarczany przez przeglądarkę i ma być spójny, dlatego nie można go dostosowywać bezpośrednio. Przeglądarka zmienia język tekstu na podstawie dziedziczonego języka dokumentu lub łańcucha elementów nadrzędnych albo opcjonalnego atrybutu lang. Oznacza to, że deweloperzy nie muszą samodzielnie lokalizować elementu <permission>. Jeśli element <permission> przejdzie poza etap próbny, w przypadku każdego typu uprawnień można obsługiwać kilka ciągów znaków lub ikon, aby zwiększyć elastyczność. Jeśli chcesz używać elementu <permission> i potrzebujesz określonego 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 funkcja nie została wcześniej włączona, użytkownik może zezwolić na jej używanie przy każdej wizycie lub tylko podczas bieżącej wizyty.

  

• Jeśli wcześniej zezwoliłeś na korzystanie z tej funkcji, możesz to zrobić ponownie lub zablokować ją.

  

• Jeśli wcześniej zablokowałeś funkcję, możesz ją nadal blokować lub zezwolić na jej używanie.

  

Tekst elementu <permission> jest automatycznie aktualizowany na podstawie stanu. Jeśli na przykład użytkownik otrzymał zgodę na korzystanie z funkcji, tekst zmieni się, aby poinformować, że funkcja jest dozwolona. Jeśli najpierw trzeba przyznać uprawnienia, tekst zmienia się, aby zaprosić użytkownika do korzystania z funkcji. Porównaj zrzut ekranu z poprzedniego obrazu z tym, aby zobaczyć oba stany.

Projektowanie w CSS

Aby użytkownicy mogli łatwo rozpoznać przycisk jako element umożliwiający dostęp 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 stylizacją mogą zostać zaspokojone, ale mamy nadzieję, że po zakończeniu testów wersji źródłowej znajdziemy bezpieczne sposoby na umożliwienie stylizacji elementu <permission>. W tabeli poniżej znajdziesz informacje o niektórych właściwościach, które mają ograniczenia lub do których mają zastosowanie specjalne reguły. W przypadku naruszenia któregokolwiek z tych reguł element <permission> zostanie wyłączony i nie będzie można z nim wchodzić w interakcję. Wszelkie próby interakcji z takimi danymi spowodują wyjątek, który można przechwycić za pomocą JavaScript. Komunikat o błędzie będzie zawierać więcej informacji o wykrytym naruszeniu.

Z tych właściwości CSS można normalnie korzystać:

• 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 wspominaliś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

Dodatkowo można używać wszystkich właściwości logicznie równoważnych (np. inline-size jest równoważne width), które podlegają tym samym regułom co ich odpowiedniki.

Pseudoklasy

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

• :granted: pseudoklasa :granted umożliwia specjalne stylizowanie po udzieleniu uprawnień.
• :invalid: pseudoklasa :invalid umożliwia zastosowanie specjalnego stylu, gdy element jest w nieprawidłowym stanie, np. gdy jest wyświetlany w elementach 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żytku z interfejsem Permissions API. Istnieje kilka zdarzeń, które można nasłuchiwać:

• onpromptdismiss: to zdarzenie jest wywoływane, gdy użytkownik zamknie prośbę o przyznanie uprawnień wywołaną przez element (np. przez kliknięcie przycisku Zamknij lub poza prośbą).

• onpromptaction: to zdarzenie jest wywoływane, gdy użytkownik zaakceptował prośbę o przyznanie uprawnień, która została wywołana przez element. Nie oznacza to koniecznie, że stan uprawnień się zmienił. Użytkownik mógł podjąć działanie, które utrzymuje stan obecny (np. nadal zezwala na uprawnienia).

• onvalidationstatuschange: to zdarzenie jest wywoływane, gdy element przechodzi z stanu "valid" do stanu "invalid". Element jest uważany za "valid", gdy przeglądarka ufa integralności sygnału, jeśli użytkownik kliknie go, i "invalid" w przeciwnym razie, na przykład gdy element jest częściowo zasłonięty przez inne treści HTML.

Możesz zarejestrować te odbiorniki zdarzeń bezpośrednio w kod HTML (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />) lub za pomocą elementu 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 funkcji

Jeśli przeglądarka nie obsługuje elementu HTML, nie wyświetli go. 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, na przykład aby utworzyć prośbę o uprawnienia, która jest wywoływana po kliknięciu zwykłego przycisku <button>.

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

Wersja próbna origin

Aby wypróbować element <permission> w swojej witrynie z udziałem prawdziwych użytkowników, zarejestruj się w programie Origin trial. Aby dowiedzieć się, jak przygotować witrynę do korzystania z testów pochodzenia, przeczytaj artykuł Pierwsze kroki z testami pochodzenia. Testowanie origin będzie prowadzone od wersji Chrome 126 do 131 (19 lutego 2025 r.).

Prezentacja

Zapoznaj się z demonstracją i zapoznaj się z kodem źródłowym na GitHubie. Oto zrzut ekranu z obsługiwanej przeglądarki.

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 przesłać nowy. Sygnały publiczne w repo elementu <permission> poinformują nas i inne przeglądarki o Twoim zainteresowaniu tym elementem.

Najczęstsze pytania

• Dlaczego to rozwiązanie jest lepsze niż zwykłe <button> w połączeniu z interfejsem API dotyczącym uprawnień? Kliknięcie przycisku <button> to działanie użytkownika, ale przeglądarki nie mają możliwości sprawdzenia, czy jest ono związane z prośbą o udzielenie uprawnień. Jeśli użytkownik kliknie <permission>, przeglądarka może mieć pewność, że kliknięcie jest związane z prośbą o uprawnienia. Umożliwia to przeglądarce ułatwienie procesów, które w przeciwnym razie byłyby dużo bardziej ryzykowne. Możesz na przykład umożliwić użytkownikowi łatwe cofnięcie blokady uprawnień.
• Co zrobić, jeśli inne przeglądarki nie obsługują elementu <permission>? Element <permission> może być używany jako stopniowe ulepszanie. W przypadku przeglądarek, które nie obsługują tej funkcji, można użyć klasycznego procesu uzyskiwania uprawnień. Na przykład na podstawie kliknięcia zwykłego przycisku <button>. Zespół ds. uprawnień pracuje też nad polyfillem. Oznacz gwiazdką repozytorium GitHub, aby otrzymywać powiadomienia o jego aktualizacjach.
• Czy ta kwestia była omawiana z innymi dostawcami przeglądarek? Element <permission> był aktywnie omawiany w 2023 roku podczas sesji dodatkowej w ramach W3C TPAC. Możesz przeczytać notatki z sesji publicznej. Zespół Chrome poprosił też o formalne stanowisko w sprawie standardów obu dostawców. Więcej informacji znajdziesz w sekcji Powiązane linki. Element <permission> jest obecnie tematem dyskusji z innymi przeglądarkami i mamy nadzieję na jego ujednolicenie.
• Czy ten element powinien być pusty? Nadal trwają dyskusje na temat tego, czy element <permission> powinien być elementem pustym. Jeśli chcesz podzielić się opinią, odnieś się do problemu.

Powiązane artykuły

• Wyjaśnienie
• Położenie na podstawie standardów WebKit
• Mozilla Standards Position

Podziękowania

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